Rygel update

For the past few weeks I have been cleaning-up and lately re-designing the source code. I am mostly finished with that and I can hopefully focus mostly on functional features piled in my todo now. The biggest change has been that plugins are now loaded into separate Media Servers and allowed to implement all kinds of resources (currently only service implementation is possible) instead of just providing a Media Provider interface. I decided to make it so when I realized that some plugins will need to implement additional services. For example a DVB plugin will want to implement a UPnP ScheduledRecording service rather than just exporting the channels.

On a side-note, our brave user (and now a contributor) Florian Steinel has got Rygel working with his PS3 already. According to him all his audio and image files are discovered and played/rendered without any problems but not all of his video files. Yes, there is still room for improvements but I was expecting quite a lot of work on making it work against a PS3 but glad to see that we are already very much compatible with it. Here are some screenshots of him playing with Rygel and PS3.









WARNING: If you want to try out Rygel with your PS3, you need to get tracker and vala from the SVN trunk.

UPDATE:Those weird looking titles in the screenshots turn out to be some Tracker-related issue:

<fsteinel> hhm, those name are already in the xml file lets see tracker...
<fsteinel> a tracker metadata bug nice, gstreamer gets it :-)
<fsteinel> gstreamer title: "El Reloj" -> tracker title: ÿþE a tracker reindex later and the error is gone :-)

Secure UPnP not a dream anymore

On last friday evening, while thinking about security and UPnP, I realized adding security might not be as hard as one might think. If HTTPS is used instead of HTTP together with authentication, Your neighbor should no longer be able to play his p0rn on your Media Renderer once he/she breaks into your wireless network. Giving it more thought, I then realized it might not be so hard to add this support into GUPnP and I was correct.

After a few hours of reading libsoup docs and hacking around this weekend, I managed to add support for HTTPS in GUPnP. Adding authorization doesn't need any changes in GUPnP since we expose both SoupSession and SoupServer so applications can very easily add that there. Also no changes were required in GUPnP for the control points to be able to deal with devices/services using HTTPS instead of HTTP, thanks to libsoup. Here is a bug that you can follow if you are interested in this topic.

WARNING: Use of HTTPS and/or authentication is not described in any existing UPnP specification that I know of so if you decide to use this in your device/service implementations, don't expect interoperability with other devices/services.