This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#5089 - Accented Characters in Playlists Don't Work?
Attached to Project:
Rockbox
Opened by Jeremy (FlyingSaucrDude) - Tuesday, 11 April 2006, 02:32 GMT+1
Opened by Jeremy (FlyingSaucrDude) - Tuesday, 11 April 2006, 02:32 GMT+1
|
DetailsI recently got Rockbox and put it on my H120. I copied a bunch of files over, including some playlists I have for an artist whose name has an accented "e" in it (google "Bela Fleck" and you'll see the proper spelling with the accent). Anyway, when I tried to load up a playlist that included a file with an accented "e" in it, it looked as if Rockbox couldn't find the files with the accents. (All other files were fine.) For example, Rockbox won't play any of the files in the attached "WorksOnPC_NotOnPlayer.m3u" playlist.
However, if I generate the playlist using Rockbox on the H120 itself, everything works fine -- and the playlist looks like the attached file "WorksOnPlayer_NotOnPC.m3u". However, that playlist doesn't work on my PC. If you open them both up in notepad, they look identical. However, opening them up in XEmacs (or any other more sophisticated text editor, I suppose) showed the difference -- in the playlist that works on the PC, XEmacs shows the accented "e" properly. However, in the playlist that works on the player, the accented "e" shows up as some weird character (an A with a tilde on top, followed by a copyright symbol). Since I just got Rockbox and have no idea how it works, I have no idea what's causing this...all I know is, it would be nice if Rockbox treated accented characters the same way as my PC, so I wouldn't have to hand-tune my playlists that have accented characters. P.S. Thanks for an awesome piece of software! I'm gonna stick with Rockbox anyway...and if somebody can point me in the right direction, I'd be happy to lend a hand trying to fix this. |
WorksOnPC_NotOnPlayer.m3u
This task depends upon
Closed by Magnus Holmgren (learman)
Thursday, 30 November 2006, 20:24 GMT+1
Reason for closing: Fixed
Additional comments about closing: This should now be fixed. .m3u playlists are read using the default code page. However, if the file does begin with a BOM, it will be read as UTF-8, regardless of extension.
Thursday, 30 November 2006, 20:24 GMT+1
Reason for closing: Fixed
Additional comments about closing: This should now be fixed. .m3u playlists are read using the default code page. However, if the file does begin with a BOM, it will be read as UTF-8, regardless of extension.
So the simple solution would be to avoid extended characters (like your accented e) for filenames. This doesn't affect your files' metadata (Vorbis comments / ID3 tags), so the wps will show it correctly (assuming your files have proper metadata).
I haven't tried this myself but IMO the "default codepage" setting should be applied when generating playlists as well. I don't know if it already works like this but maybe changing this setting helps.
I'm not sure whether getting playlist reading/writing to use the "Default Codepage" setting constitutes a bug or a feature request, but either way I agree -- it should be used. Plus, I've never been one for simple solutions...
I'm pretty busy at the moment, but perhaps when I get some free time I'll look into this...of course, if somebody who actually knows the code could find a quick fix, that would be great too.
I've discovered Rockbox a week ago, now that it runs on my iPod mini 2g (20060416), and find it such a great project that I took some time testing this feature. I hope you developers can find it of interest and come up with something 'cause I can't wait to convince my friends here in ShangHai to use it, and international support is a priority for them.
The file includes all playlists tested and a text file with results and conclusions of all the tests made (almost 60). But for simpler reading, I've copied my suggestions for improvement below:
S1) Support for non-utf playlist usinf Default Codepage
S2) Choice of utf use [utf / codepage] when saving playlist and for all file operations
S3) Support for .m3u8 extension utf playlist (simple, for foobar2000 compatibility)
S4) Support for non-UNIX files by handling properly the first character / control code ??
S5) Choice of [Relative / Full path] when saving playlist
S6) Choice of text file format [DOS / UNIX] when saving playlist and for all file operations
"UTF-8 files can sometimes start with what is called a byte-order mark (BOM for short), which is three bytes that are used to indicate that the file is indeed an UTF-8 file. Rockbox currently doesn't check for or remove any BOM, so if one is present, the first track would likely be skipped."
Thanks to Lear
http://forums.rockbox.org/index.php?topic=3444.15
what exactly is .m3u8? m3u playlists in utf8 with or without BOM? If it's always without BOM and without a specified line end coding it really should be fairly simple.
To S4:
The BOM isn't specific for *nix, you can find it on "Windows uft8-files" as well. But as Windows usually uses an 8 bit encoding (like latin9 in europe) you'll hardly find a) utf8 files, b) files with BOM.
To S6:
Why do we need DOS text file type for playlists? Can't Windows players (like foobar and winamp) handle with Unix text file type? The only program I know that doesn't handle unix text files is notepad.
UltraEdit was messing up the BOM (my mistake). After using a decent hex editor, I can say that UNIX and DOS playlists are handled similarely by all media players tested including Rockbox. However, without a BOM, most windows players fail to recognize UTF and playlists are often garbage. Only VLC reads BOM-less fine. So S6 could be forgotten, but BOM not.
Actually, most windows players also fail to recognize UTF with BOM. Only foobar2000 and Media Player Classic don't complain. So even more important than Rockbox writing BOM or not, is to be able to write in ANSI (cf S2). As far as reading is concerned, support for playlists with BOM would still be very much appreciated.
FS#5770.FS#5770is in CVS?