Bug 303088

This is an issue with Amarok, so I'm reassigning it there.

I can't reproduce this.

What version of Amarok are you using?

Are the covers downloaded from the internet or provided locally (either embedded within the music files or as a separate image, like folder.jpg)?

I am using version 2.5.90 of Amarok.  The covers are not present as separate image files within the album folders, but I'm not sure if they are embedded within the music files.  If I had to guess, I would say that they're not, if only because the albums go back as far as 1992.  However, I'd be happy to check this out with some direction.

On the other hand, I have discovered that it is an intermittent bug; some albums do seem to work straight away.  A few popular(ish?) titles that don't:
Smashing Pumpkins -- Siamese Dream, ripped from CD
The Beatles -- Abbey Road, ripped from CD
Modest Mouse -- Good News for People Who Love Bad News, ripped from CD
Barenaked Ladies -- Stunt, ripped from CD
There are others; just a short list.

I still can't reproduce it, even using exactly that version of Amarok and Maroon 5's Stunt (also ripped from a CD).  So, a few more questions:

The way I'm trying to reproduce this is, having renamed ~/.kde/share/apps/amarok and ~/.kde/share/config/amarok*, I open Amarok and turn on the "automatically fetch album covers option".  I then quit Amarok again, add Stunt to my the (empty) folder I chose as Amarok's music library.  Then I start Amarok again, and go to Tools->Update Collection.  This adds Stunt, and fetches the album cover for it.  Then, I start playing one of the tracks (which, at this point, already has an album cover).  I then look at the Now Playing applet I have on my desktop.

Does this sound like it should re-create the problem you've been seeing?

Also, when you go to Fetch Album Cover and click the Configure button, which provider is selected?  I think the default is Last.fm.

Yes, this sounds exactly correct.  Also, the album cover provider is Last.fm, as you suggested.

As a thought, under Settings --> Configure Amarok --> Local Collection, I ticked on "Write Covers to File", with no effect.

Of course, if you are unable to reproduce the bug, then there may just be something wonky with my system.  Thanks for the help; let me know if you have any other ideas, or if I can do anything else to help.  I'm unsure what to make of it =].

I have the same issue in Amarok 2.6. My covers are all local files in the album's folders, all named cover.jpg. If I rescan the collection they are correctly picked up by amarok and they show in the collection, but they don't show up in the Now Playing applet until I manually assign them.

Had another go at reproducing this with a new user, but couldn't.

Can you try running amarok as
amarok --debug
then reproduce the issue, and paste the output here (or attach it to the bug), please?

Also, which version of Plasma are you using? (Amarok has two different D-Bus interfaces, and old versions of Plasma's Now Playing applet might use MPRIS instead of MPRIS2).  Use:
plasma-desktop --version

For what it's worth, at the moment I'm running:
Amarok: 2.5.0
Plasma Desktop Shell: 0.4
openSUSE: 12.2
KDE: 4.8.5
Qt: 4.8.1

I am *not* currently having this issue.  It's proving to be a bit of a pain to upgrade to 2.6.0 through the easier openSUSE routes, so if I get some time I may do the slightly heavier lifting required to upgrade at a later date.  I realize that both the OS and the version of Amarok I'm talking about have changed in the last 6 months, but I just wanted you to know that I'm not totally ignoring you.  Thank you for your continued effort with this (possible) bug.

I did some more testing and it seems that the ultimate cause of this is having non-ascii characters in the music path. To test, I added an folder to the collection that contains an album with its cover as cover.jpg, with only ascii characters in the path, and it worked fine. Then I renamed the folder to contain a non-ascii character and re-added it to the collection and it stopped working. 
 Using KDE 4.9.97, amarok 2.6

(In reply to comment #9)
> I did some more testing and it seems that the ultimate cause of this is
> having non-ascii characters in the music path. To test, I added an folder to
> the collection that contains an album with its cover as cover.jpg, with only
> ascii characters in the path, and it worked fine. Then I renamed the folder
> to contain a non-ascii character and re-added it to the collection and it
> stopped working. 
>  Using KDE 4.9.97, amarok 2.6

I assume you mean 7-bit charcter sets, excluding accented letters, but If your system uses UTF this should not be a problem. For reserved characters see http://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations: any 8-bit set should do in UNIX-like systems, not just ASCII, only / and NULL are excluded.  Only strict POSIX compliant systems limit the character set to 7-bit A-Z a-z 0-9 ._- but that is rarely the case in modern distributions.

Of course non-UTF will still cause the problem, but the ISO encoding is obsolete since so long now this should not happen anymore.

In other words: please make sure all your file system uses UTF-8

Yes, my system is fully UTF8

I can reproduce this at all, currently using Amarok v2.6.90-89-g9a4a950 on KDE 4.9.97 on Kubuntu 12.10

A. Rojas: which exact "non-ASCII" character did you try? I tried with à, ä and ñ, works quite fine for me.

Also, can you paste the output of running "locale" in konsole, please?

(In reply to comment #12)
> I can reproduce this at all, currently using Amarok v2.6.90-89-g9a4a950 on
> KDE 4.9.97 on Kubuntu 12.10

Oops, looks like I didn't have enough coffee when I wrote that: I can't reproduce this at all.

(In reply to comment #12)

> A. Rojas: which exact "non-ASCII" character did you try? I tried with à, ä
> and ñ, works quite fine for me.

ú, accented vowels in general

(In reply to comment #13)
> Also, can you paste the output of running "locale" in konsole, please?

> locale
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=

(In reply to comment #4)
> The way I'm trying to reproduce this is, having renamed
> ~/.kde/share/apps/amarok and ~/.kde/share/config/amarok*, I open Amarok and
> turn on the "automatically fetch album covers option".  I then quit Amarok
> again, add Stunt to my the (empty) folder I chose as Amarok's music library.
> Then I start Amarok again, and go to Tools->Update Collection.  This adds
> Stunt, and fetches the album cover for it.  

In order to reproduce the bug, the "automatically fetch covers" option needs to be OFF, otherwise the cover will be saved to ~/.kde4/share/apps/amarok/albumcovers/ which doesn't contain non-ascii characters and it will work correctly. The cover needs to be stored in the same folder as the album songs as cover.jpg, so amarok will get it when scanning the folder.

Created attachment 76470 [details]
Debug log

Amarok log while reproducing the bug for a few tracks

Excellent, thanks for that, I've managed to reproduce it now.

Ah, so it turns out that the problem isn't with Amarok at all; it's just that Amarok manages to trigger it.

The basic problem seems to be that the QML Image element of the Now Playing plasmoid gets a URL like file:///home/testuser/Music/%C3%A1%C3%BC%C3%AA%C3%B2/folder.jpg and can't interpret the URL to find the file.

Git commit 10216c7f531810a63d54e567cb223e1e0d9da93a by Alex Merry.
Committed on 14/01/2013 at 23:58.
Pushed by alexmerry into branch 'KDE/4.10'.

Fix handling of encoded URIs in mpris2 engine

A couple of entries in the metadata property of the MPRIS2 interface are
sent as encoded URIs.  We decode these in the mpris2 engine, replacing
the QStrings with QUrls that can be used easily by the consumer of the
engine.

This fixes the display of album artwork in the Now Playing widget when
mpris:artUrl contains %-encoded non-ASCII characters.
FIXED-IN: 4.10

M  +31   -3    plasma/generic/dataengines/mpris2/playercontainer.cpp

http://commits.kde.org/kde-workspace/10216c7f531810a63d54e567cb223e1e0d9da93a

Git commit 758e603b93d7909aecbff4db36a8b7bb3f64e201 by Alex Merry.
Committed on 14/01/2013 at 23:58.
Pushed by alexmerry into branch 'master'.

Fix handling of encoded URIs in mpris2 engine

A couple of entries in the metadata property of the MPRIS2 interface are
sent as encoded URIs.  We decode these in the mpris2 engine, replacing
the QStrings with QUrls that can be used easily by the consumer of the
engine.

This fixes the display of album artwork in the Now Playing widget when
mpris:artUrl contains %-encoded non-ASCII characters.
FIXED-IN: 4.10

M  +31   -3    plasma/generic/dataengines/mpris2/playercontainer.cpp

http://commits.kde.org/kde-workspace/758e603b93d7909aecbff4db36a8b7bb3f64e201