A Recap of Fixing Bug ID 680484

Recently I have fixed the bug 680484 and learned a lot from the process. Therefore I think it deserves a blog post to share my story. The bug 680484 is about a crash when running the program gupnp-dlna-info to dump the input media file’s metadata with -v option. This crash only happens to gupnp-dlna-info linked against gstreamer-1.0. Gstreamer is a comprehensive multimedia processing library. gupnp-dlna, and many other GNOME multimedia packages, depends on it to deal with media files. Nowadays Gstreamer is under the flux from 0.10 to 1.0 (or 0.11) and many GNOME programs are busy with migrating to the Gstreamer-1.0 APIs.

A good introduction to gstreamer-1.0 can be found here. The link also provides the PPA links to install 1.0 on Precise. However I found that the APIs in this PPA slightly fall behind the head of the git. (Update: as of today, Aug 11, 2012, the PPA version is good) So I would recommend to use JhBuild to install the master version of Gstreamer by running jhbuild build gstreamer-master. You probably also need to build gst-plugins-good-master, gst-plugins-bad-master and gst-plugins-poor-master to install the necessary plugins.

To fix the bug 680484 I first verified gupnp-dlna-info had linked to the correct version of gstreamer.

[riko@localhost] tools $ ./gupnp-dlna-info --gst-version
GStreamer Core Library version

Now I reproduced the crash by issuing the command like this

[riko@localhost] tools $ ./gupnp-dlna-info ../../../gupnp-dlna-media/strict/audio/NiN_Ghosts_IV_34.mp3 -v

Profile Name: (null)
Profile MIME: (null)

  audio: audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, rate=(int)44100,
  channels=(int)2, parsed=(boolean)true
  Segmentation fault

To make the debugging easier I compiled the gupnp-dlna-info with shared build disabled and ‘-g’ flags to CFLAGS

[riko@localhost] gupnp-dlna $ ../../gupnp-dlna/configure --enable-shared=no CFLAGS='-g'

Next I used cgdb to load the program

cgdb --args ./gupnp-dlna-info ../../../gupnp-dlna-media/strict/audio/NiN_Ghosts_II_12_lo.mp3 -v 

In cgdb debugging window I ran the program to make it crash

Now use the command backtrace or bt to retrospect the flow of function calls.

By analyzing the function call history I decided to move the history backwards 4 steps and found a suspicious call.

After referring to the gstreamer-0.10 to 1.0 migration guide, I figured out that the line gst_structure_to_string ((GstStructure *) taglist) was deprecated and I should use gst_tag_list_to_string (taglist) instead. So I verified that in gdb and it seemed to work.

It turned out that was the reason for the crash. Fixed it and the crash was gone.


How to use Rygel to share video and play it back in Totem

In my first OPW progress report I mentioned that I used XBMC player to play back the multimedia files by Rygel. Zeeshan asked if I could use a GNOME DLNA player. Actually I had tried Totem player with Coherence plugin but failed. In the age of GNOME 3, the Coherence plugin is probably obsolete and doesn’t work anymore (no wonder that Totem plugin package in Ubuntu 12.04 didn’t include the Coherence plugin). That was the reason I switched to use non-GNOME apps like XBMC and eezUPnP. But recently I found out there is a GNOME project Grilo that can make Totem work. And I had a feeling that Grilo is gonna replace Coherence as the primary UPnP plugin for Totem. By checking out the git source of Totem, under the plugins directory, there is no more coherence_upnp. Grilo plugin first appeared in Totem 3.2.0 which means that you probably can’t install Grilo plugin for Totem by running ‘apt install’ in Ubuntu 12.04. Therefore I downloaded the latest source release of Totem (3.4.3), compiled and installed it. It ran great on my machine. The following screenshot shows how it looks like:

Use Grilo plugin for Totem to browse the media files shared through Rygel

GNOME OPW GUPnP Progress Report

Hi everyone,

I would like to write my first progress report on my Gnome OPW project, GUPnP. In the past two weeks, I spent time on getting familiar with the GUPnP project and its sister project Rygel. And I want to share my understanding here.

Different from many other Gnome desktop applications which usually have pretty graphical user interfaces, GUPnP provides the underlying supports behind the stage. It servers as the communication infrastructure for the upper-level applications. It is invisible for the end users but it is a hidden hero.

GUPnP actually consists of several small library projects, e.g. gssdp, gupnp, gupnp-av, gupnp-dlna and gupnp-igd. gssdp (together with libsoup) wraps the network details providing the HTTP-based communication capability such as resource announcement and discovery. gupnp with other gupnp-xxx stuff built upon gssdp implement the UPnP specification. More details can be found on the official website of GUPnP.

Rygel is a media-sever and media-renderer over the home-based network. It is the primary user of GUPnP and heavily based on Gnome/GLib/D-Bus components. To understand what the media-server/renderer/control are and how these things change our digital life, I would recommend to look at the demos at the front page of www.dlna.org. The best way to get the first-hand feel of these concepts is to actually use Rygel or run the test programs in GUPnP source folder.

First, prepare a folder with your favorite songs in it, then run Rygel in the same folder, and then use XBMC player (I recommend) to search the shared songs and play them. So what is the big deal, you may ask. The main idea here is that you can run Rygel in one computer to share your songs, and use XBMC at other computer to play. Imagine that you can also play your songs over the network in your Android/iPhone device too. All right. Do it. You will understand what I’m talking about. Meanwhile I noticed that a good documentation is missing on Rygel website. So I think I can contribute on that even though I’m still a beginner too.

Another thing that really sparked my interest is the use of D-Bus in Rygel. I have known for long that D-Bus techniques have been widely used in GNOME but I have never had a chance to go deep to understand its ins and outs. A nice feature in Rygel is that it exposes its service on a ‘bus’ so that other external programs can connect to this ‘bus’ and use Rygel’s media-sharing capability. At present, I can only scratch the surface without understanding the real story underneath. Hopefully by working the code of GUPnP and Rygel I will do that soon.

All right, summarize my progress. I have to admit the barrier to entry of networking programming is a little high. I finally made some progress on this bug. As what Jens suggested to me, a specific and non-trivial contribution would be to replace the multi-cast socket code in gssdp with the newly available function in GLib-2.32. I’m working on it now. So again, stay tuned. Welcome back to my blog to see what I will have.