Tracker and me

While working with tracker I find myself rather often calling “tracker-info” on resources, looking for linked resources, running tracker-info on those, then needing to get back etc. A bit ugly and time-consuming.

Wouldn’t it be cool to just browse through all that info, being able to go back and forth through the links? Yes, it would. That’s why I wrote tracker-zilla:

You can navigate through the resources just like on the interwebs, using the back and forward feature of the context menu. It shows you not only the resources and properties of the object but also resources that link to the one you’re currently browsing:

It’s not that feature-rich and probably never will be. You can either pass a urn to it via command-line or nothing, then it will show you all rdfs:Classes available in the current ontology where you can just click on e.g. nco:PersonContact. What I’m planning to add is a simple in-page search and a breadcrumb navigation.

That said. it’s a pleasure to work with libtracker-sparql (especially from Vala). You need Vala 0.11.6, gtk+-3 and webkitgtk-3.0 to build it. ?The code is available at github.

Update: Due to popular demand, there’s now a –with-gtk=2 option to enable Gtk+-2 UI.

Debunking Rygel myths

Somehow Rygel seems to have gained some interest by users lately, a number of new users show up on mailing list, IRC and Bugzilla. But it seems there are some misinformations flowing around:

Rygel is a UPnP server
Well yes, that’s how it started out. But since then, we’ve evolved to be a UPnP/DLNA framework or even SDK providing easy means of implementing servers and renderer.

Speaking of renderer, we not only have one renderer to offer but actually a multitude. Rygel is a consumer of the MPRIS2 D-Bus specification which means it can turn any player, like Banshee or Rhythmbox, which implements this specification into a UPnP/DLNA media renderer.

Rygel is Gnome-only
While being part of Gnome, using its infrastructure, there’s no reason not to use Rygel as a system service. You might, however, experience some minor drawbacks since some of the plug-ins heavily make use of D-Bus. People already have contributed init scripts to ease this part.

Rygel is badly documented
Hm, yes. That one is actually true. Its documentation is a bit scattered in our wiki at http://live.gnome.org/Rygel and the man-pages. On the other hand we hope that Rygel working out of the box for most people out there.

Hope that sheds some light.

Ps: Hello Planet Gnome! Great to be here finally.

UPnP & C++

I’m currently trying to provide Qt4 bindings for the GUPnP stack. I’m a bit impeded by the issues that I already encountered with the “mm” C++ bindings and other people also experienced. Some classes are not that binding friendly. Additionally GUPnP is – as the name implies – closely tied to GObject and the GType system, imposing some more problems for the Qt 4 port.

I already got a test-browser like example running in Qt 4 running, stay tuned for more updates.

Resolving DBus uniqe names

Often you stumble across DBus logs (e.g. originating from bustle or dbus-monitor) which only feature DBus unique names (those :1.xyz numbers) and you can only guess which process it originates from.

Helper script to resolve those addresses to processes (if the system is still running):

#!/bin/bash
 
name=$1
while [ -n "$name" ]
do
    result=`LANG=C dbus-send \
                  --session \
                  --print-reply \
                  --dest=org.freedesktop.DBus \
                  / \
                  org.freedesktop.DBus.GetConnectionUnixProcessID \
                  string:"$name" 2>/dev/null`
    if [ $? -eq 0 ]
    then
        process=`ps ax | grep ^${result##* }`
        echo "$name -> $process"
    fi
    shift; name=$1
done

The QThread anti-pattern

Sometimes with QThread you see something like this:

void run()
{
    while (true) {
        {
            QMutexLocker lock(&mMutexData);
            if (mQuit)
                break;
        }
 
        msleep (200);
    }
 
    mWaitExit.wakeAll();
}
 
void stop()
{
    mMutexData.lock();
    mQuit = true;
    mMutexData.unlock();
    mWaitExit.wait(&mMutexExit);
}

This is potentially problematic. Why? Consider the extreme case of a function shutdown() which does something like this:

void shutdown()
{
    thread->stop();
    delete thread;
}

Congratulations, you’ve just introduced a race condition. Why, you will ask? You’re waiting for the thread to end before deleting it, right?

No. And this has to do with the way Qt implements QThread::wait() which you should have probably used in the first place, if you really need this sort of functionality.

Qt hooks a pthread cleanup handler in the native thread which will call wakeAll() on a QWaitCondition stored inside the pimpl of QThread. And this pimpl – you might have guessed – is gone when you call delete.

Pino as in twitter

Since Echofon cut off custom-built Firefoxes I was looking for a new twitter client. The only one matching my needs was Pino. Unfortunately since the mandatory activation of OAuth in twitter it stopped working. But: No fear! I hacked it to use librest which supports OAuth ootb. Currently it is a bit flaky (crashes at startup sometimes for no obvious reason) and there is no easy way to log in. It currently uses librest’s demo consumer keys which is probably not the most fortunate thing to do. I will request own credentials as soon as it runs more stable. Stay tuned for updates, I will push it to a public repository really soon.

Update: Seems upstream pino will contain librest with OAuth in version 0.3. So I’ll keep my ugly hack to myself ;-)

101 secret Rygel tips

With the release of Rygel 0.7.3 I thought I should bring up some sort of FAQ for Rygel and especially the MediaExport plugin, since it has some features and behavior changes that might lead to confusion for long-time (and new) users:

Plugin concurrency

With the release of 0.7.4 you cannot enable both tracker and MediaExport plugins at once. If you do so, the MediaExport plugin will be shut down in favor of the tracker plugin.

Meta-data extraction

Speed

Since 0.7.3 Rygel now uses the gunp-dlna package for meta-data extraction. This is based on the gst-discoverer work by Arun and Edward from Collabora Multimedia. It is significantly faster on video files than the old home-grown meta-data extraction stuff.

Filters

Rygel no longer blindly tries to extract meta-data from everything it sees in the directories. Instead it uses a positive list of file extensions to include. In the default configuration these are:

  • Audio formats
    .mp3, .oga, .ogg, .mp4, .flac, .wav, .wma
  • Video formats
    .ogv, .ogg, .mkv, .avi, .mp4, .mpeg, .mpg, .ts. .wmv, .asf
  • Image formats
    .jpeg, .jpg

If your favorite format is missing, don’t hesitate to file a bug

Folder hierarchy

Since Rygel 0.5.2 there has been support for user-defined virtual folders in the MediaExport plugin. It allowed the user to browse through his media by artist and album e.g. With Rygel 0.7.3 the possibility to define those folders yourself is gone. The configuration syntax wasn’t really intuitive and easy to get wrong. We defined a set of build-in folders which resemble the folders provided by the Tracker plugin.

And since the addition of this default folders made the view of the root folder even more cluttered, I decided to move all every non-virtual folder that directly corresponds to a file-system folder into its own subfolder. In an upcoming release a configuration option to disable the display of this folder will be added.

If we missed out a folder you really need, please file a bug for it.

Screenshot of new hierarchy

State of the GUPnP stack on Windows and other scary tales

I updated the windows ports of gssdp and gupnp today, did some further clean-up on the gupnp port and filed merge-requests for both on gitorious.

I also deleted the gupnp-win32 repository on github. New development will go to this repository on gitorious. There is still the gssdp-win32 repository on github since I have not yet taken care of the MSVC additions.

I also started wrapping gssdp et al into *mm (hey, I work for Openismus now ;) but this has proven to be somewhat difficult.

Trekstor Vibez and Jaunty^WLucid

So – A year has passed, two Ubuntu versions, what’s the state of MTP vs. mass storage? Apparently still broken. Same same but different.

Instead of making the player crash, gphoto2/libmtp and usb mass storage fight for the right to access the device which leads to very ugly errors in dmesg that look like the device or at least its file-system is severely broken :(

So, once again: Either make the device MTP only or remove the device’s entry from the libmtp udev rules which now reside in /lib/udev/rules.d/45-libmtp8.rules