It's a php remote, which uses ssh to control Totem and fetch playlist data. For instance, when I click on a file in my media library, this gets issued:
system("ssh ike@chii 'DISPLAY=:0.0 totem --replace \"/path/to/media/file\" 2>&1'");
or for sending the computer to sleep,
system("ssh ike@chii sudo /usr/sbin/pm-suspend");
Apart from that, I doesn't do much, but it's kind-of all I need to enjoy tv from my bed.
The dependencies on this baby are, however, quite big:
- http server (nginx);system("ssh ike@chii 'DISPLAY=:0.0 totem --replace \"/path/to/media/file\" 2>&1'");
- php5 fastcgi processes;
- ssh public key setup, whereupon the server process (www-data) can access my user account without use of the password.
I wanted to boil this down to a standalone python webserver, which I would simply run as a non-root user and let that be that. Also, instead using the totem command to control another totem instance, I wanted to use the d-bus protocol. IPC would be what the big boys use, anyway.
As it turns out, d-bus is very poorly supported. Totem does use it to receive media keys from the Gnome Settings Daemon (GSD) on the session bus, but won't want to receive from anything else. I've went to great lengths to replicate the d-bus signal GSD sends to Totem, using both the dbus-send shell utility and my own C code (http://pastie.org/526510), but it would not nudge. As far as I can tell, this isn't possible without modification of totem source code itself.
What is did essentially boils down to:
- used dbus-monitor to inspect the communication between GSD and Totem
- tried replicating it with dbus-send
- when that failed, wrote a C program which called the "SendMediaKeys" operation on the same interface CSD does. Sent it to the totem proxy iself, and to all (null destination = bus-wide broadcast); neither did stick
I'll write up on that as soon as I know more.
