Here’s the problem. Any returned GdkPixbuf objects from libgpod when called from within Amarok are invalid — they’re either garbled junk, null, glib asserts, or libgpod throws an assertion claiming something or other:

(process:26875): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `src != NULL' failed
(process:26875): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(process:16782): CRITICAL **: unpack_UYVY: assertion `width * height * 2 == bytes_len' failed

The most bizarre part of it is that the exact same code works perfectly when called from within one of libgpod’s unit tests, and artwork retrieval works fine in gtkpod.

A few things I know for sure:

1. There is only one version of libgpod installed (0.7.0), self compiled with gdkpixbuf support
2. Gtkpod was also self compiled against libgpod 0.7.0
3. The libgpod guys have been very involved but can’t provide any answers
4. Both gtkpod and Amarok link to the same versions of libgpod and gdk:
   $> ldd /usr/lib/kde4/libamarok_collection-ipodcollection.so
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4
$> ldd `which gtkpod`
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4

5. Could it be a race condition somewhere? Perhaps, but as I see it, the code is only ever called from the Qt GUI thread.

Here’s the snippet of code: http://pastie.org/415144

Can anyone provide any insight to this problem? I’m going bananas trying to solve it.

Update: Problem solved folks! Turned out to be a misuse of the libgpod api – calling itdb_device_read_sysinfo() kills the artwork structs which have been already initialised. The blame game lies equally on Amarok (for incorrect usage) and libgpod (for poor documentation and unexpected results). Good news is that the grand folks upstream at libgpod have been notified and they’ll be improving their API and docs.

I do believe that my recommendations very much match the mainstream of the opinions of the key people in Linux multimedia and desktop audio. Of course I don’t nearly know everyone of the key hackers in Linux multimedia. But I do know most of those who are actively interested in collaboration, whose projects have a lot mindshare and who attend the conferences that matter for Linux desktop audio.

Lennart forgets that Amarok is definitely a contender for the most popular music player on desktop Linux today. It possibly has the most mindshare of any Linux music player project. Remember that a long time ago, Amarok supported aRts, xine, GStreamer and helix. Now we can take advantage of not needing to care about a specific implementation for an audio output device by using Phonon.

Lennart again:

“Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)”

This implies that a developer should only use Phonon if and only if the developer is targeting a KDE application. Frankly, this reasoning is not very well formed and is shameful. Perhaps what Lennart meant to say belongs along the lines of “Developers using the KDE development libraries might want to use Phonon”.

Amarok is a perfect example of an application which uses the KDE development libraries, but is not tied into the KDE plasma workspace. A grand portion of GNOME users pro actively install Amarok on their system because it is their preferred application for listening to music. Time to pick up the slack and get with the times.