Ever since the announcement of the N9’s DLNA support people were looking for a feature called DLNA +PU+ which allows you to send media files to e.g. DLNA-capable TVs without enabling content sharing on your device, giving you a really fine-grained control about what and where to share to.

PushUp is a small utility that hooks into the N9’s sharing framework and allows to you push an image or a video to your TV just like you would with Bluetooth or NFC. Get it on this site (or later through the Nokia Store).

It is an offspring of my Korva project, a D-Bus specification and its implementation for media pushing. While still work-in-progress, it’s already fully functional.

Edit: I had to update the package because the icon was missing and cancelling the device selector was broken.
Edit2: Updated again since it was broken on PR < 1.2.

This version is not submitted to the store (yet) since I felt it needs a bit more testing, especially on the interaction with media renderers. I’ve only two renderers that are not Rygel-based and one of them is severely broken when it comes to UPnP.

As I mentioned on several places already, due to the aim of getting the N9 DLNA-certified we had to introduce some restrictions. One of the most annoying limitation from an end user point of view is that you can’t share arbitrary videos or music which you may have put on your device. Another, though minor, issue is that it’s not possible to change the name shown in UPnP or DLNA clients on the network.

While it is possible to change all this by editing the configuration file, it is somewhat inconvenient to do this on the device. That’s why I’ve written a small application called TweakUp which allows all these settings (and a few more, see the screenshot) to be changed more comfortably. It is available in the Nokia Store and on this website. It has been signed with my public key 6BA1DF74.

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.

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.