Bug 301399

Summary: Amarok does not always export cover art via MPRIS2 D-Bus interface
Product: [Applications] amarok Reporter: bill p. (aka google01103) <dweeble01103>
Component: D-Bus interfacesAssignee: Alex Merry <alex.merry>
Status: RESOLVED FIXED    
Severity: normal CC: alex.merry
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 2.6
Sentry Crash Report:
Attachments: meta data with no cover shown
meta data when cover shows

Description bill p. (aka google01103) 2012-06-07 21:31:47 UTC
Sometimes cover not showing when Amarok playing a track, Amarok displays track and track is both embedded and in folder

tested 2 tracks from 2 diff albums - both covers are named folder.jpg and are embedded, one displays and the other doesn't - both covers are 200x200

Reproducible: Sometimes

Steps to Reproduce:
1.play tracks
2.
3.
Actual Results:  
cover does not always display

Expected Results:  
cover displays
Comment 1 Myriam Schweingruber 2012-06-08 15:04:51 UTC
I assume it does display in Amarok?
Comment 2 bill p. (aka google01103) 2012-06-08 15:10:15 UTC
yes Amarok displays the cover, original report should have said "Amarok displays cover and cover is both embedded and in folder" why I used "track" instead of "cover" I do not know
Comment 3 Myriam Schweingruber 2012-06-08 15:24:14 UTC
Thank you for the fast feedback.
Comment 4 bill p. (aka google01103) 2012-06-10 11:03:10 UTC
quick update - seems many more covers are not shown than shown and all are shown in Amarok. Initial report based on minimal (3 or so albums) usage but the more usage the more apparent the problem
Comment 5 Alex Merry 2012-06-11 10:25:17 UTC
The only time I don't get covers displayed by Amaork is when it has only just downloaded them, so I can't reproduce this.

Can you play a track where the cover does not display, and run
plasmaengineexplorer --engine mpris2
please?  Then expand the amarok source, and copy down the first bit of the mpris:artUrl part of the Metadata value (you will probably have to expand the "value" column considerably - double-click on the resize bar to the right of it).

This should start something like "file:///home/username/", but may start something like "sqldb://"

This will help me figure out whether the problem is in Amarok or the mpris2 dataengine.
Comment 6 bill p. (aka google01103) 2012-06-11 10:40:22 UTC
Created attachment 71730 [details]
meta data with no cover shown
Comment 7 bill p. (aka google01103) 2012-06-11 10:42:41 UTC
Alex I did as requested and did not see any mpris:artUrl in the meta section, see attached jpg of the meta section
Comment 8 bill p. (aka google01103) 2012-06-11 10:46:36 UTC
Alex - added jpg where cover does show
Comment 9 bill p. (aka google01103) 2012-06-11 10:57:47 UTC
Created attachment 71732 [details]
meta data when cover shows
Comment 10 Alex Merry 2012-06-11 11:14:44 UTC
So the issue is with Amarok.  Could you tell me what version of Amarok you are running?  If you have compiled it from git, the HEAD commit would be useful.
Comment 11 bill p. (aka google01103) 2012-06-11 11:32:58 UTC
2.5git self compiled 

would be happy to tell you what the "HEAD commit" if you can specify where I can find it (assume it's in the .git folder), can tell you it was compiled 6/6 after a git clone
Comment 12 bill p. (aka google01103) 2012-06-11 11:52:32 UTC
Alex - just did a git clone, recompiled and no difference - so what ever the current HEAD commit is is what I am using
Comment 13 Alex Merry 2012-06-11 12:31:40 UTC
Sorry, I wasn't sure how familiar you were with git terminology.  The HEAD commit is the top one when you do "git log".  It is also displayed by "git show".
Comment 14 bill p. (aka google01103) 2012-06-11 12:39:43 UTC
commit 4479b118033c1bbacf81d5d4261a518eab89e216
Author: Matěj Laitl <matej@laitl.cz>
Date:   Sun Jun 10 12:54:13 2012 +0200
Comment 15 Alex Merry 2012-06-11 15:04:18 UTC
OK, can you please update from git again ("git log" should include commit 58017cdb353282b9cfc8286477fed05334ebf331: Add more debugging info for mpris:artUrl in the MPRIS2 interface) and reinstall, then run
amarok --debug
from the terminal and search (Ctrl+Shift+F in Konsole) for "MPRIS2" in the output?  I'm particularly interested in lines that appear when you start playing a track with a cover that doesn't get exported over the MPRIS2 interface.

Thanks for being so responsive, by the way.  It's really helpful when tracking down a bug I can't reproduce.
Comment 16 bill p. (aka google01103) 2012-06-11 15:55:25 UTC
Alex - everything in the Konsole window from the first occurrence of "MPRIS2" on http://pastebin.com/1jCXGQq7

note - leaving, may/may not be back for hours

regards,
Comment 17 Alex Merry 2012-06-11 16:32:06 UTC
Git commit f6262ff64d9ca4341f86b3f2e569a151531af4b5 by Alex Merry.
Committed on 11/06/2012 at 18:28.
Pushed by alexmerry into branch 'master'.

MPRIS: Actually use the cached we created

When we create a cached image (because we can't use the full-size one -
eg: it is embedded), actually use it.

I _think_ this should fix bug 301399.

M  +3    -2    src/core/meta/support/MetaUtility.cpp

http://commits.kde.org/amarok/f6262ff64d9ca4341f86b3f2e569a151531af4b5
Comment 18 Alex Merry 2012-06-11 16:34:42 UTC
Can you try it again, making sure you update first?  I think it should be fixed now.
Comment 19 bill p. (aka google01103) 2012-06-11 20:10:14 UTC
did a quick test of two albums that had covers that did not display and they both do now!!!!!!!!!!!

will update if the test sample proves too small

thanks,
Comment 20 Alex Merry 2012-06-11 20:53:05 UTC
Git commit 2b36a6b8a99b616393e279ef2f8b5c4d02a9a80b by Alex Merry.
Committed on 11/06/2012 at 22:45.
Pushed by alexmerry into branch 'master'.

MPRIS: give out embedded images in their natural size

Rather than always resizing to 135 when the image is embedded in a file,
get the image at its original size.

M  +6    -14   src/core/meta/support/MetaUtility.cpp

http://commits.kde.org/amarok/2b36a6b8a99b616393e279ef2f8b5c4d02a9a80b
Comment 21 Alex Merry 2012-06-11 20:55:52 UTC
I've changed it not to always resize images to 135x135px, but to give them out at their original size.  If this breaks things again, can you re-open?  I did do some testing with this one, by embedding some art into one of my mp3s, though, so I'm not expecting any issues.