Umlaut problem in "browse" view

Pi MusicBox
1

I noticed that umlaut letters are not displayed correctly in the “Browse” section of the musicbox webclient. The “Now Playing” sceen as well as the bottom bar shows the letters correctly.

The same problem might still occur in the “Playlists”. At least in MusicBox 0.53 those names are also displayed incorrectly (In MusicBox 0.53, these songs are even skipped when trying to play them. This apparently has been fixed in 0.6. ).

I checked in the SQLite database of mopidy-local and there the names are still correct.

2

It’s not clear to me from this what version you are actually reporting this
problem against. Musicbox 0.5.3 or 0.6?

3

Both versions have the problem.

The screenshot is from 0.6.

In 0.5, the files would not even play so I don’t know whether they would be displayedin “now playing” correctly.

4

Is it so that this only happens when you browse to folders (when using SQLite), and not when you go to e.g browse/albums?

What system local do you have?

Because, what I think I have noticed is that the library pulls the names from the metadata, in which case they might be displayed correctly even when the filenames are not. So for example, I have some playlits (local m3u lists of songs in /var/lib/playlists that do not work because they contain umlauts and the way the OS displays them is distinct from what the file has. However, those same files are displayed correctly when viewed from “browse/albums” or similar.

5

Yes, you’re right.

When drilling in via “Albums”, the umlauts are displayed correctly,
when going in via “Folders” they are broken.

I have not changed anything regarding system locale. It is a one day old “clean install” of the 0.6 image.

Not sure if I look in the right place, but the locale command gives the following result:

root@MusicBox:~# locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
root@MusicBox:~# locale -a
C
C.UTF-8
POSIX
root@MusicBox:~#
6

Browsing “Folders” lists files and directories according to the system locale, while browsing “Albums”, " Artists" etc. uses information extracted from metadata tags included in the files. This is so people with untagged files still get access. Now, the POSIX locale only handles ASCII characters, so setting the system locale to something that handles UTF-8 should fix this. IFyour file and directory names are UTF-8, of course.

7

What benefit is there from the fact that the default locale is POSIX, which it seems to me that no one would want to use under any circumstances?

8

It’s a bug, it has been discussed on the issue tracker but sadly didn’t
make it in for the recent releases. My fault.

9

OK, but don’t worry about it. If people go and change the locale, then will a reboot suffice, or does it require a rescan? Which one of the already installed locales would be best, or should one add more with say the locales package?

10

If I understand @tkem correctly then Browsing doesn’t use the scanned data so you should be good to go after a reboot. I think C.UTF-8 should be sufficient and should already be installed.

For reference: https://github.com/woutervanwijk/Pi-MusicBox/issues/242

11

IIRC changing the system locale should only affect

  • browsing “Folders”
  • tracks without proper title tags, since the “track name” is generated from the file name in this case

So trying a reboot without a rescan should be fine for most people (and you’ll notice quickly otheriwse :wink:

12

Can someone confirm that?

I changed the locale to C.UTF-8 and rebooted:

But the web interface still shows the file names wrong:

When going in the chrome developer tools it shows that the actual id of the element is correct (html encoded file name) and only the label shows the wrong representation:

Is that an indication that it is not a system locale problem?

13

Is this only in the MusicBox-WebClient or does this also occur with MPD clients?

14

I can confirm that this also happens on Gnome Music Player Client.

15

Hi,
I dug around in the web client a bit using the chrome dev console and found out the following:

The GET request of the folder content returns the content correctly:

…or at least chrome displays it like that. In the raw data it looks like this:

According to Character Encoding info of ü this is a unicode encoding in source code.

Those encodings should probably be converted to HTML encoding before returning it or maybe not encoded at all if everything is utf-8.

Anyway, the end result is that the tracks array as used by the web client is broken:

Hope this helps isolating the issue.

16

Hi,
Seems I see a similar thing in the Playlist. The files do show up with the name in the playlist (I already changed the view name to not have Umlauts).
This is the playlist entry:
#EXTINF:3039,008 - Und Der Gruene Geist
/music/Network/DDF/008 - Die Drei Fragezeichen - Und Der Grüne Geist.mp3

I changed the locale to de.DE_UTF8 and mounted the windows share with iocharset=utf8.

The file is part of a playlist and also is moved to the queue.
https://docs.google.com/file/d/0B9xVNo0HVP81Yl9lMV9HbUN6VjQ
https://docs.google.com/file/d/0B9xVNo0HVP81VFpuYjVUbFlVcUU
But it doesn’t play afterwards. The other files in the same list without the Umlauts do play though.