FS#6435 - Queueing and accented characters

Attached to Project: Rockbox
Opened by Norbert Preining (norbusan) - Wednesday, 13 December 2006, 20:47 GMT
Last edited by Dominik Riebeling (bluebrother) - Sunday, 16 March 2008, 14:43 GMT
Task Type Bugs
Category Playlists
Status Closed
Assigned To No-one
Operating System All players
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


HI all!
This is related to FS #5089, but a bit different:
If I add a file to the current playlist which contains accented characters in the path/filename part, it is not recognized but shown with (ERR) at the beginning.
This task depends upon

Closed by  Dominik Riebeling (bluebrother)
Sunday, 16 March 2008, 14:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed according to the comments, plus no response for several months.
Comment by Peter D'Hoye (petur) - Wednesday, 13 December 2006, 21:36 GMT
sorry, unable to reproduce. This is what I tried on my h340
- browse to a dir and start a cd without accents
- short-press navi to go to the browser
- long-press navi on an accented file and select playlist->insert
- back to wps
- long-press navi and view playlist (everything ok)

the file and path had accented and other weird letters - it was a Sigur Rós song ;)
Comment by Norbert Preining (norbusan) - Wednesday, 13 December 2006, 22:06 GMT
Hi Peter!
You are right, it is non-trivial to repeat it.
When I create a dynamic playlist by entering a directory and selecting one song, ie creating a playlist of all songs in this directory, and THEN selecting a song with accents in it, then it works.
But when I load a playlist .m3u, ie in latin1 encoding, and then select a song with accented chars in it, it does not work.
Can you reproduce this?
Of course, it could also be that my own builds have some bug, but the patches do not touch this stuff.
Bye Norbert
Comment by Nils Wallménius (nls) - Wednesday, 13 December 2006, 22:10 GMT
Please try using an official cvs or daily build to reproduce the problem.
Comment by Norbert Preining (norbusan) - Wednesday, 13 December 2006, 22:34 GMT
Confirmed with the latest H340 build. But to be honest, it seems to be a problem with playlists in latin1 encoding which I have created long before the m3u8/m3u distinction. If I load a m3u8 then there are no problems at all.
Comment by Nils Wallménius (nls) - Wednesday, 13 December 2006, 22:40 GMT
HAve you tried setting your "Default Codepage" to latin1? .m3u is supposed to be loaded with the set encoding.
Comment by Norbert Preining (norbusan) - Wednesday, 13 December 2006, 22:45 GMT
Yes, Default Codepage is set to latin1. I think the problem is NOT the loading of a m3u playlist, BUT the queueing/dynamic additon of a file to a playlist which was loaded in latin1 mode.

I.e., load a m3u playlist, ie in latin1. Then go to the browser and select a file with accents and select queue next. Then I got an error.

Comment by Peter D'Hoye (petur) - Thursday, 14 December 2006, 09:11 GMT
I'm sorry, unicode and codepages are not my field of knowledge.
Comment by Jeremy (FlyingSaucrDude) - Thursday, 11 January 2007, 19:39 GMT
It might not matter, but I just wanted to add that I'm experiencing the same problem on my H120. My default codepage is set to latin1. I can then load any playlist (with or without songs with accents) -- all the songs in the playlist will play fine. But as Norbert said, anytime I use the file browser to enqueue a new song with accents into the playlist, that song is not played (skipped over) and it has (ERR) next to it in the playlist.
Comment by Dave Early (dfe) - Monday, 12 March 2007, 21:34 GMT
I too can confirm this bug on my H140 (Build 12732-070312). Regular directory playlists with accented characters play fine but songs inserted/queued into playlists loaded from (in my case) the /Playlists directory don't play and show (ERR) when viewing the playlist. I wondered why my Icelandic songs weren't playing!
Note that it seems to be where there is an accented char *anywhere* in the path/filename.
Comment by Jeremy (FlyingSaucrDude) - Friday, 21 December 2007, 02:25 GMT
As of r15860M-071130, this bug seems to have been resolved (at least for me on my H120).