GNOME Bugzilla – Bug 732236
use embedded album art if available
Last modified: 2015-07-06 20:30:44 UTC
currently, it doesn't seem possible for gnome-music to use the embedded album art in .m4a (AAC) and .mp3 files instead of searching for them (which results in wrong / missing album art in quite some cases). (nautilus thumbnailer / totem / rhythmbox / audacious all read the embedded album art correctly, so that is not the issue here.)
Gnome Music uses tracker + grilo combination to retreive album art
I pushed commits f8591e438aadd7 and c541a8c5229 that most definitely help here. Before these fixes, the MP3 extractor would occasionally skip the whole last frame, which is rather commonly the APIC one, containing the embedded albumart data. I'm closing this bug as fixed, please try with tracker master and reopen if that's not the case.
I just compiled and installed tracker from git.gnome.org/tracker master (with, I think, all needed plugins enabled) and still don't get album art in gnome-music - both in 3.16.1 and 3.17.3 (fedora 22 and rawhide). gnome-music - when started from terminal - only spews stdout/stderr with hundreds of error messages, including many, many of those: (gnome-music:1961): Grilo-CRITICAL **: grl_data_has_key: assertion 'GRL_IS_DATA (data)' failed and then, for every album containing .m4a files that does not get album art: 17:25:22 WARNING albumArtCache.py:259 can't find artwork for album 'Babel (Deluxe Version)' by Mumford & Sons although every one of those albums has album art embedded in the .m4a files. even totem and some other music players display the album art without issues.
Oh, this change definitely didn't cater for m4a. These fallback to the gstreamer-based extractor which should also be able to extract the albumart with no trouble. Would be great if you could paste the output of $jhbuild_prefix/libexec/tracker-extract -v 3 -f /path/to/song.m4a If you could send me a (link to a) sample file privately to the email address of my bz account, it'd be really appreciated too, and will surely speed up the process. The file will be kept on my private stash of testing files, or deleted after fixing if you have any concerns.
Created attachment 306941 [details] tracker-extract of mp3 case mp3: finds embedded album art Processing media art: artist:'Mumford & Sons', title:'Sigh No More', type:'album', uri:'file:///home/deca/01%20Sigh%20No%20More.mp3', flags:0x00000000. Buffer is 94524 bytes, mime:'image/jpeg'
Created attachment 306942 [details] tracker-extract of m4a this does not seem to do anything ... Processing media art: artist:'Mumford & Sons', title:'Babel (Deluxe Version)', type:'album', uri:'file:///home/deca/01%20Babel.m4a', flags:0x00000000 does not find album art what I find odd is: GStreamer backend in use: Discoverer/GUPnP-DLNA
Received a sample file privately, gstreamer doesn't seem to find any "image" tag, but there's a "preview-image" tag instead, which indeed seems to be the image used by nautilus/totem/etc. I'm attaching/pushing a patch that falls back to that image. that makes gnome-music show album art for it. (In reply to Fabio Valentini from comment #6) > GStreamer backend in use: > Discoverer/GUPnP-DLNA Oh, nevermind about that :). That's a facility on top of gstreamer's discoverer that gets the UPnP tags that apply to the file, we fetch that in case they ever get UPnP-shared.
The following fix has been pushed: adffa68 tracker-extract-gstreamer: Fallback to preview image for album art
Created attachment 306953 [details] [review] tracker-extract-gstreamer: Fallback to preview image for album art Some files don't provide a cover image, but just a preview image, we can use that as albumart. This commit reuses code from a fallback which looks bogus nowadays, since it just does the same than the while loop above. If we reached there, it would fail again for sure.
tracker from master now works like a charm, thanks!