Text based remote interface

[zoundz]

I didn't see anything, and maybe this has already been beat to death. I wonder about the possibility of a text based remote interface for SageTV. The idea would be to allow simple queries of the status, scheduled recordings, etc., and the ability to possibly schedule a recording. I am running a linux box as my only outside accessible interface to the world. No Apache, no nothing; just ssh access. The linux box has full access to the internal lan. If there were a tcp/ip port that SageTV listened on for text based interactions, it would be relatively easy to create a perl script or program to allow a logged on linux user to talk to SageTV from afar. Someone running a web server could also interface with SageTV through this port, with whatever security the web server wanted to provide. No fancy graphics, no hi-bandwidth data, just simple ansi formatted text. I realize that it's easy enough to use VNC to run the SageTV machine, but leaving a VNC port open to the outside world is a risky proposition. Securing it with ssh is possible, but tricky. Better to use the security of linux and provide a simple interface.

Feel free to flame the crap out of me if this is a pathetically stupid idea.

[salsbst]

If there were to be a text-based interface, I'd want it to be XML on top of HTTP. Sounds like you're more interested in a telnet-style thing, which is fine, but it wouldn't be my first choice. If telnet is of interest, I think i'd probably layer that on top of the HTTP/XML.

[nielm]

I use ssh for secure remote interface to my sage machine... It is easy to port-forward the vnc port 5900 through the ssh client...
using cygwin ssh/cygwin sshd:
ssh -L 5900:localhost:5900 sage_server

Also UltraVNC is better than standard VNC at compressing its connection...

[zoundz]

I understand that VNC can be forwarded and all that. (I also use UltraVNC, but use the term VNC generically) That can be done now with no changes to SageTV. What I would like to see would be a very low bandwidth "client" that could perform simple control and inquiry functions. They are two different thoughts entirely, even though the results are similar.

As far as using HTTP and XML, the problem that I see with that is that either the SageTV machine has to be opened to http or https or there needs to be a proxy in between to maintain security. It seems that a very useful text based interface could be created. Using XML for the interface seems like a bit of an overkill for something that is basically simple tables and menus. The current gui could probably be duplicated in text mode without a lot of fuss. There are a million text driven menu interfaces. They are simple and require vitually no bandwidth. We're talking up,down,left,right,enter as virtually the entire control system.

Just seems to me that it would be nice to hook up real quick from the office and tell SageTV to record something that you just found out about or whatever.

[nielm]

Originally posted by zoundz
What I would like to see would be a very low bandwidth "client" that could perform simple control and inquiry functions.

So would I...

As far as using HTTP and XML, the problem that I see with that is that either the SageTV machine has to be opened to http or https or there needs to be a proxy in between to maintain security.

... or use an SSH-forwarded port again After all, your telnet-style interface also needs a proxy machine...

[zoundz]

No need to get into an argument about the details. Personally, I think that a simple telnet approach makes more sense. No "proxy" is necessary, rather just some sort of telnet access. In my case, I have sshd telnet access trivially, so that is how I would like to operate. The real idea here, IMHO, is for SageTV to be able to stream the GUI out in some form of text mode. The nuts and bolts can be dealt with. The client end can be written to interpret any protocol that can be easily transmitted over a low bandwidth text path. Is the existing SageTV server/client protocol documentation available? Maybe it's already usable.

[salsbst]

I just woudn't jump straight from what we already to a telnet-style interface because I feel you'd be throwing away alot of leverageable work by skipping an XML layer. It's a whole heck of a lot easier to parse XML than it is to scrape the kind of screens you get from text terminals. The text terminal layer would be fairly trivial on top of a decent XML layer, wheres layering anything on top of a terminal layer would be really kludgy.

As far as using HTTP and XML, the problem that I see with that is that either the SageTV machine has to be opened to http or https or there needs to be a proxy in between to maintain security.

Agreed, one would probably want to put some security on the thing. I don't think that necessarily means that it's a bad thing to have, though.

JMHO.

No need to get into an argument about the details...

Well, it is a discussion forum, and you are discussing with people who are interested in opening up Sage to control from afar, so I think the details do start to matter. Or would you rather that people "flame the crap out of you"?

[salsbst]

Another thought... has anyone every tried using an HTTP tunnel to connect SageTVClient.exe to SageTV.exe? At one point I had something set up so that I could get to my home network from the office. It was three layers of tunneling and quite slow:

IMAP -> SSH -> HTTP -> Client Side Proxy Server -> internet -> HTTP listener -> SSH tunnel open to home LAN.

I wonder how "talky" SageTV's protocol is -- whether it would survive the latency and behave snappily enough to make this interesting.

[heffe2001]

I have used sage client sometimes to connect to my server at home (hardware VPN connection). Works pretty well on the guide and such, but of course won't play video (but will play audio/mp3's).

The bonus was being able to use the client on my lappy when I was wireless at home, and watch TV wherever I was at.

[turak]

Originally posted by zoundz
Is the existing SageTV server/client protocol documentation available? Maybe it's already usable.

You could sniff the packets between server and client with something like ethereal. Once you figured out what commands the client is sending it should be easy to write a perl script using something like IO::Socket::INET and IO::Select.

[zoundz]

You could sniff the packets between server and client with something like ethereal.

I'm fundamentally a lazy slut and I was hoping to not have to sus out the interface by hand. There probably a reverse engineering clause in the EULA, as well. The downside to doing it that way is that you have no real idea what the designers of the interface were thinking. When little things get changed, you find the whole thing turns to trash. I'd much rather work from the real interface spec if it can be made available. Maybe an appropriate NDA or something.

[krutaw]

Originally posted by zoundz
I'm fundamentally a lazy slut and I was hoping to not have to sus out the interface by hand. There probably a reverse engineering clause in the EULA, as well. The downside to doing it that way is that you have no real idea what the designers of the interface were thinking. When little things get changed, you find the whole thing turns to trash. I'd much rather work from the real interface spec if it can be made available. Maybe an appropriate NDA or something.

AMEN!

I wish there were a tool built in for this, or actually, more to the point...

I *REALLY* wish SageTV used a standard database for it's data storage. This would lend itself to *TONS* of mods not the least of which would be a custom web interface (or text if you prefer.)

This would also allow for better database manipulation and backup without having to wonder if the database was corrupt or not. I mean, mysql is free for goodness sake. ;-)

Okay, stepping off my soap-box.