GNOME Bugzilla – Bug 690286
totem-video-thumbnailer fails to extract coverart from mp3 files
Last modified: 2012-12-18 10:06:52 UTC
Since I switched to a gst1.0 version of totem, totem-video-thumbnailer silently fails to extract coverart from my id3v2 tagged mp3 files (other audio files not tested yet), so it is impossible for nautilus to show thumbnails. When opening the file with totem directly, coverart is shown in the main window as expected.
The more I think about it, I'm not sure if this is rather a gstreamer bug (using 1.0.3 on x86). I tracked it down to src/gst/totem-gst-pixbuf-helpers.c: It seems like in totem_gst_tag_list_get_cover_real() the call to gst_structure_get_enum which is to modify the variable type is not working correctly (when reading type for debugging purposes, insted of values like -1, 0 or 1 I get something like -1216816106), so the comparsions type == GST_TAG_IMAGE_TYPE_UNDEFINED and type == GST_TAG_IMAGE_TYPE_FRONT_COVER will never be TRUE. The image is getting extracted correctly (from a file where the frontcover tag is set correctly), when changing the "else if" part to "else", that means ommitting the check "type == GST_TAG_IMAGE_TYPE_FRONT_COVER" or initializing type with 1.
Can you please provide a test file?
Created attachment 231788 [details] Testfile I'm adding a file from the GNOME system sounds using id3v2.3 tags. The frontcover image is the 256x256 one for the help browser from gnome-icon-theme. As far as I understand it, gst_structure_get_enum always is returning false using this type of files, not initializing the type variable. I'm not sure if this may be architecture-related - as said, I'm using x86, not amd64.
Created attachment 231790 [details] [review] thumbnailer: Fix fetching the cover art on some systems Initialise the type of image so that we can save the cover image even if the image-type isn't defined.
Attachment 231790 [details] pushed as c458067 - thumbnailer: Fix fetching the cover art on some systems