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
Steps to Reproduce:
cover does not always display
I assume it does display in Amarok?
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
Thank you for the fast feedback.
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
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.
Created attachment 71730 [details]
meta data with no cover shown
Alex I did as requested and did not see any mpris:artUrl in the meta section, see attached jpg of the meta section
Alex - added jpg where cover does show
Created attachment 71732 [details]
meta data when cover shows
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.
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
Alex - just did a git clone, recompiled and no difference - so what ever the current HEAD commit is is what I am using
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".
Author: Matěj Laitl <email@example.com>
Date: Sun Jun 10 12:54:13 2012 +0200
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
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.
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
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
Can you try it again, making sure you update first? I think it should be fixed now.
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
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
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.