Bug 303088 - Album artwork with UTF-8 characters in paths do not display in Now Playing
Summary: Album artwork with UTF-8 characters in paths do not display in Now Playing
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-nowplaying (show other bugs)
Version: 4.9.97 RC2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 4.10
Assignee: Alex Merry
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-06 05:27 UTC by Julia
Modified: 2013-01-14 23:03 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10


Attachments
Debug log (422.22 KB, text/plain)
2013-01-14 19:02 UTC, Antonio Rojas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julia 2012-07-06 05:27:07 UTC
When music is added to the local collection in Amarok, the album artwork is, of course, automatically detected.  However, the artwork fails to show in the now playing widget until one manually enters the "Fetch Cover" window in Amarok.

Reproducible: Always

Steps to Reproduce:
1.  Add new music to a folder scanned by Amarok --- e.g. in my case, music transferred from an mp3 device to /home/user/Music
2.  Launch the Now Playing widget
3.  Open Amarok, update your local music collection, and begin playing any of the new tracks from an album whose artwork is automatically detected.  Do NOT select the artwork manually.
Actual Results:  
The album artwork does not appear in the Now Playing widget.  To correct this, go back into Amork, right-click the album artwork, and select "Fetch Cover."  Selecting even the same artwork and applying will fix the issue.

Expected Results:  
The automatically detected artwork should also show up in the Now Playing window, without the extra step described above.

Obviously, this can cause a bit of a headache with a large music library.
Comment 1 Alex Merry 2012-07-06 09:10:40 UTC
This is an issue with Amarok, so I'm reassigning it there.
Comment 2 Alex Merry 2012-07-07 14:42:12 UTC
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)?
Comment 3 Julia 2012-07-07 19:37:58 UTC
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.
Comment 4 Alex Merry 2012-07-08 12:03:36 UTC
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.
Comment 5 Julia 2012-07-08 22:30:20 UTC
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 =].
Comment 6 Antonio Rojas 2012-10-07 18:01:59 UTC
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.
Comment 7 Alex Merry 2013-01-13 15:31:11 UTC
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
Comment 8 Julia 2013-01-13 17:25:04 UTC
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.
Comment 9 Antonio Rojas 2013-01-13 22:07:22 UTC
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
Comment 10 Myriam Schweingruber 2013-01-14 09:45:38 UTC
(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
Comment 11 Antonio Rojas 2013-01-14 10:06:36 UTC
Yes, my system is fully UTF8
Comment 12 Myriam Schweingruber 2013-01-14 10:43:56 UTC
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.
Comment 13 Alex Merry 2013-01-14 11:23:16 UTC
Also, can you paste the output of running "locale" in konsole, please?
Comment 14 Myriam Schweingruber 2013-01-14 11:29:40 UTC
(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.
Comment 15 Antonio Rojas 2013-01-14 19:01:29 UTC
(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.
Comment 16 Antonio Rojas 2013-01-14 19:02:25 UTC
Created attachment 76470 [details]
Debug log

Amarok log while reproducing the bug for a few tracks
Comment 17 Alex Merry 2013-01-14 22:00:30 UTC
Excellent, thanks for that, I've managed to reproduce it now.
Comment 18 Alex Merry 2013-01-14 22:11:08 UTC
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.
Comment 19 Alex Merry 2013-01-14 23:03:19 UTC
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
Comment 20 Alex Merry 2013-01-14 23:03:20 UTC
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