Coder's Log

Rygel 0.2 is out. Here is the release announcement: The major change after last release (as gupnp-media-server) is the introduction of a simple yet powerful plugin-based architecture/api: Everyone plugin: - is loaded into a separate MediaServer instance. - can implement any kind and number of resources (currently only services). - can export an icon file. - inherit it's ContentDirectory implementation from a base class that does most of the UPnP-related work. More improvements on this planned for next release. - use an intuitive API to easily export media from URIs and live GStreamer source elements over HTTP. Other changes: - Relicense under LGPL to allow proprietary plugins and ease of moving code from/to gupnp libraries. - DVB Daemon integration though a plugin. Now you can watch live channels from your PC on your PS3 for example. - Test plugin that exports one audio and video item, streaming contents from GStreamer's audiotestsrc and videotestsrc elements respect

Thanks to Ross and Richard Purdie, GUPnP moved to Git today. I already updated the jhbuild modulesets to reflect the new repos.

I had been working on adding a DVB plugin to Rygel lately so that people can easily watch TV on all their UPnP-capable Renderers without having to swap DVB cards around (people typically have one). Although I had finished the basic version of the plugin 1-2 weeks ago, the live streams never worked for me. Yesterday, I realized my mistake (wasn't handling the dynamic pads from the gst source element) and when i corrected that, here is what happend: There are still some issues to fix, especially the artifacts that happen because RTP headers are not getting stripped off when Rygel proxies the RTSP stream over HTTP but I am hopeful I'll be able to fix them soon. UPDATE: The artifects issue i mentioned above has already been fixed in the trunk so now you can enjoy a smooth live tv experience. :) Also! before you ask, no this doesn't work with PS3 yet (most probably because of some missing metadata in the DIDL-Lite fragments).

So it is no secret anymore that Rygel will be part of maemo platform . If you are interested in contributing to maemo, here is yet another chance. I have a big pile of TODO for Rygel so if you are interested, do contact me. In case you prefer IRC like I do, I am always on #gupnp on irc.gimp.org.

One of the excuses I had to not implement DVB-Daemon integration in Rygel was that I didn't have the needed hardware to do so. Some days ago, I decided to get rid of this excuse by buying myself a Hauppauge Nova-T DVB-T stick. After a few days of trying different things, fiddling around and filing ivalid bugs , I finally manged to get it working with both DVB Daemon and Totem . Here is some advice based on my experience so far: If you happen to have the same DVB card as I do, make sure you have the recent enough (>= 2.6.25) Linux kernel that provides the needed driver (dib0700) out of the box. Get yourself the latest firmware from here and place it under /lib/firmware. The driver still looks for it by it's old filename so make a symlink in the same directory to this file by the name "dvb-usb-dib0700-1.10.fw". Unless you know exactly what kind of channels file needs to be created, DO NOT use w_scan for creating a channels file. Use gnome-dvb-setup.py (part of DVB

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 mak

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 an

I am pleased to announce that gupnp-media-server project has been moved to GNOME SVN under the new name, Rygel . Currently it's a basic implementation on top of GUPnP and Tracker but I'll be putting a lot of time and love staring from next week to turn it into a very great project. Special emphases will be put into making it fit the UPnP needs of GNOME. This would be a very good time to convince me to implement all the features you would want to see in a UPnP Media Server so I can add them to my TODO file. :) UPDATE : While updating the jhbuild moduleset, I found out that rygel isn't buildable with latest vala/bindings. I'll try to correct the issue(s) tommorrow so don't panic if it doesn't build for you. It's just the demo effect. :)

Jussi recently commited some major changes to Ross ' gupnp-binding-tool and one of the new features is support for server-side bindings. This makes writing UPnP implementations in C even more easier. So laziness is becoming less and less of an excuse to not write UPnP stuff. :) Here is a nice document with a nice explanation of how to use it.

Claudio has bad memory so here is my feelings about both of these places in my own words: Meritähti : I really like that place, nice food in a very affordable price. Also it is very near to our office, which makes it the first choice to go to for a meal before we hit another bar for good beers. However, it is most definitely not the best restaurants or bar in Helsinki. Not even one of the best ones. There are lots of very excellent restaurants in the city but of course they charge a lot more. Molly Malone's : That is one of the best bars in Helsinki, lots of nice beers, nice friendly atmosphere and live concert every evening. BTW, Bastien just committed my patch to nautilus-sendto trunk that adds support for sending files to UPnP Media Servers. I've only tested in against Nokia N81 and Media Server provided by Intel tools for UPnP but it should work for most of the Media Servers that support uploading.

As most of you probably know already, GUPnP is now officially part of Maemo and therefore future internet tablets. This is a major milestone and gives a big boost to my motivation to continue my UPnP adventure. Although I try to put as much of the bits and peaces of spare time i get from my job into UPnP work and I am pretty sure the Intel (former OH ) will continue their work as well, we could certainly use more hands to accelerate the development. If you want to help, here is a short list of TODOs that you might want to have a look at and decide if you could help on any of these: Bindings : Although the more bindings we have the more worlds we can conquer but what we definitely need is bindings for most popular languages in GNOME/Maemo world, namely C#/mono, Java and Python. If you are interested in helping with this, I strongly suggest you take the g-i-r route . Also if you are only interested in C# bindings, I suggest you talk to Jerome Halton who already have a half-baked solu

Many thanks to Olivier Crête , we now have a nice small library for firing holes through firewalls using a part of UPnP IGD API. This library also provides a convenient way to do all that without having to use a gmainloop. While Olivier will most probably use it in his farsight2 , I am sure this will be useful for other projects (I did not say Ekiga :)) as well.

My last blog post managed to attract the attention of some of our beloved GNOME developers, especially the ones working on/with embedded systems. That made me realize that I am not (at least completely) on crack and decided to file a nice big bug for addition of something similar to GstMiniObject to core gobject library. Lets see what happens next. :)

I had always been hearing that GObjects are slow and it's not always a good idea to use/write them but I never saw any evidence to support that. I had this desire to write a test application to get this evidence but felt too lazy to do it in C. I realized a few days ago that I can write such an app very easily in Vala without giving up much on my laziness. :) So here is an app that I wrote last evening after returning from vacation. Here are the results on my laptop: $ ./test-perf 0.000182 seconds taken in creating 10000 structs. 0.001598 seconds taken in creating 10000 instances (compact). 0.003522 seconds taken in creating 10000 instances. 0.090455 seconds taken in creating 10000 instances (GObject). The ranking is exactly how I expected it to be but didn't expect such a big difference between them all.

What a beautiful country. The people were very nice and the food was just amazing.

After reading/watching Stuart's nice slides on Closures in the context of JavaScript, I have started to like JavaScript. Personally, I don't accept any language as a high-level scripting language if it doesn't support closures. Python is therefore straight out of my window. Although Vala isn't a scripting language, it would be nice to have such support in there as well. It already supports lambda functions with no restrictions and Jürg has concrete plans to support closures, it's more a matter of when rather than why or how. When that support is there, just try and stop me from loving Vala. :) UPDATE : Thanks to Anonymous, I now stand corrected that Python does fully support closures. Although I still don't like the fact that it restricts lambda functions to be one-liner but at least it's not straight out of the window anymore. :) UPDATE#2 : Andy Wingo informs me that python doesn't really fully support closures. He even put up a small code fragment to

Since I totally agree with last two blog entries of Havoc, I originally started to write this entry to get them to the planets I am on and he is not (yes, there are some) but then I couldn't resist adding my own thoughts. :) Regarding "embeddable" scripting languages, I came-up with the exact same conclusion 4-5 year ago. When I looked around at that time, I realized that GNU had realized that long time ago and had a nice embeddable implementation of the easiest yet powerful language, Scheme. Guile was the name of that implementation. I soon became a firm believer of "Most of the implementation in C, while the highest-level (only) logic written in Scheme/Guile". While I was acting on my belief, I couldn't help but notice that the only other person in the whole GNOME community that had similar vision was Andy Wingo. Many (if not most) had been going for Python. Some of them even took this scripting language as far as coding complete frameworks in it. As

When I wrote GUPnP Network Light, I thought of it as just a simple example application that demonstrates how easy it is to implement UPnP devices and services using GUPnP. However there is one man, Mr. Hugo Baldasano Calleja who being an electrical engineer is very much interested in light bulbs and has recently been writing control point for Network Light. While discussing about his code with him on IRC , I started to wonder how would a simple control point GUI for Network Light look like. I realized that it would look exactly the same as the Network Light itself. Since Hugo had already made it possible for multiple instances of Network Light to co-exist happily on the same network/machine, I decided to turn Network Light GUI to be a Control Point that controls all the Lights on the network, not just itself. The change is already in the trunk and will be released soon. Here is a screenshot:

Jorn made minor releases of GSSDP and GUPnP today. The main purpose of which is to fix the build on Rawhide. Here is the release announcement: GSSDP 0.6.2 =========== - Reannounce resources after max_age / 2 - 1 instead of after max_age. [Peter Christensen, Jorn Baayen] - Remove unnecessary call to g_thread_init(). [Zeeshan Ali] GUPnP 0.12.2 ============ - Support returning actions outside of the 'action-invoked' signal handler in service implementations. [Zeeshan Ali, Jorn Baayen] - Add explicit dependency on gthread. [Zeeshan Ali, Jorn Baayen]

Ever since I started to IRC from my Linux machine, not only I had been a happy (almost) user of XChat for years but also I wrote an XChat plugin for Guile. All that changed when I moved to Finland three years ago and was educated about the benefits of the combination of irssi + screen +ssh, the biggest (perhaps the only one) of them being the persistence connection to IRC. Since then I had been using that combination. After three years, I am having doubts about the choice I made at that time. XChat might not be able to provide me with a persistent connection to the IRC world but it still provides lots of small features that irssi does not (and in some cases can not) provide that really does matter in the end and one would expect in a modern IRC client, e.g hard-to-miss notifications when I get new messages, saving of logs and DCC-sent-files directly on my local-machine etc. I switched to back to XChat a few days ago. I mostly feel good about coming back to it but still miss the persi