Bugzilla – Bug 4139
CLI - Non-ASCII chars (e.g. '�') in filename broken?
Last modified: 2009-09-08 09:18:39 UTC
If this bug is real then any non-latin1 character (common in opera, classical, bjork!) in a filename might result in that file not being playable via CLI. In this case, a filename containing the character � is reported as "not found" by the squeezebox. I also tried changing the � for a regular e temporarily, the file then plays fine via CLI. Playing the same file from web interface works fine with the �. I've tried the latest nightly for 6.5b3 and the one in /downloads/SlimServer_v6.5.0b3 Interestingly - this problem seems worse in the latest nightly. Both are detailed below. ---------------------------------------------------------------------- Character quick reference - � 0xe9 233d from charset "Latin-1 supplement" http://www.unicode.org/charts/PDF/U0080.pdf In UTF-8 this would be 0xC3A9, I verified this here... http://www.stanford.edu/~hc10/misc/binhexuni.html ---------------------------------------------------------------------- DETAILS AND LOGS The % escaped � character is correctly translated into "%C3%A9" for sending to the CLI. Interesting parts are marked with the ^ character. It's a bit tricky to parse with the eyeball otherwise. [original string] "D:\mp3\Classical\Bizet\Carmen-Callas\208 - R�cit- Reposons-Nous Une Heure Ici, Mes Camarades.mp3" ^ [string sent via CLI to slimserver] "D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici,%20Mes%20Camarades.mp3" [full cmd sent via CLI to slimserver] "playlist add D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici,%20Mes%20Camarades.mp3" ^ ^ --RESULT A--------------------- * Server Details 13-Sep-2006 19:28, from /downloads/SlimServer_v6.5.0b3 SlimServer Version: 6.5b3 - 9790 - Windows XP - EN - cp1252 Perl Version: 5.8.7 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Here the translation of � to %C3%A9 seems correct, but the file is still reported as not found. [from telnet window after "listen 1"] playlist add D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici%2C%20Mes%20Camarades.mp3 playlist cant_open D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici%2C%20Mes%20Camarades.mp3 PLAYLIST_EMPTY --RESULT B --------------------- * Server Details Nightly build from 17sept SlimServer Version: 6.5b3 - 9790 - Windows XP - EN - cp1252 Perl Version: 5.8.7 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Where did "%C3%83%C2%A9" come from? [from telnet window after "listen 1"] playlist add D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%83%C2%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici%2C%20Mes%20Camarades.mp3 ^ ^ playlist cant_open D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%C3%83%C2%A9cit-%20Reposons-Nous%20Une%20Heure%20Ici%2C%20Mes%20Camarades.mp3 PLAYLIST_EMPTY
Not entirely clear with version you are using each time, the version strings are identical. Anyway, for some reason the CLI/SlimServer expects path in the locale. Escaping spaces and leaving the CP1252 chars as it should work. It works for others <http://forums.slimdevices.com/showthread.php?t=26492>. Yes, there is maybe a little documentation problem.
Fred: is this something for 6.5.1 or 7.0?
The code fix is in 6.5 already (expecting poster to confirm). What's missing may be a doc update. The uber fix for 7.0 or 6.5.1 is bug 4136.
Ok, using cp1252, percent escape only the spaces. It still fails on latest nightly (18 sept) but it works on 6.3.1. See RESULTS below for details. In case of ambiguity (I noticed the change to the summary) the character that is causing problems is lower case e with an acute accent, in the word "Recit" in the song title. Also, you mention a documentation problem, I guess you mean that the CLI docs say that UTF-8 must be used with percent escaping. Anyway... The command issued is: "playlist add D:\mp3\Classical\Bizet\Carmen-Callas\208%20%20-%20R�cit-%20Reposons-Nous%20Une%20Heure%20Ici,%20Mes%20Camarades.mp3" RESULTS ---- SlimServer Version: 7.0a1 - 9811 - Windows XP - EN - cp1252 * Note the insertion of %EF%BF%BD in place of the 0xe9 character (CP1252). From "listen 1" on CLI port.... playlist add D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%EF%BF%BDcit-%20Reposons-Nou s%20Une%20Heure%20Ici%2C%20Mes%20Camarades.mp3 ---- SlimServer Version: 6.3.1 - 8468 - Windows XP - EN - cp1252 * Note the correct insertion of %E9 in place of the 0xe9 character (CP1252) playlist add D%3A%5Cmp3%5CClassical%5CBizet%5CCarmen-Callas%5C208%20%20-%20R%E9cit-%20Reposons-Nous%20Un e%20Heure%20Ici%2C%20Mes%20Camarades.mp3
Please test using telnet and copy paste the results. Use a smarter client than Win XP telnet and simply keep the session. The CLI echoes back UTF8 encoded stuff, so listen is not a good indicator of what is going on.
Asked for some logs by private email on 29.9. Any news?
Fred: any news on this?
Reporter sent me private email about re-checking the bug and providing requested logs.
Created attachment 1629 [details] Log of d_cli showing that bug is fixed in server v7.0a1 Retested version below for this bug. Bug appears to be fixed, see line 366 of attached file slimserver.log Log generated using --d_cli SlimServer Version - SlimServer Version: 7.0a1 - 9925 - Windows XP - EN - cp1252 Server IP address: 192.168.0.2 Perl Version: 5.8.7 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt
Ok, closed then.
Created attachment 1631 [details] Log of d_cli showing that bug is fixed in server v6.5.1 Retested using v6.5.1. Log created with --d_cli Bug appears to be fixed here also, see line 263 of log file attachment.