Bug 4330 - Playlist names charset mix-up
: Playlist names charset mix-up
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 6.5.0
: All All
: P2 normal (vote)
: 7.x
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-09 08:19 UTC by Fred
Modified: 2009-07-31 10:14 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred 2006-10-09 08:19:53 UTC
Playlist names are accepted from the CLI or the Web GUI and used to build the playlist file path. No charset translation occurs however so if the playlist name includes a special character, the result may not be the expected one depending on the various charset used on the particular OS combination.

OS X and other fully utf8 systems are fine, but Windows causes problems: A cp12xx name will work fine for the path but display strangely (assumed utf8 when it isn't). If utf8 is used as input (f.e. through CLI), the file creation fails. Code in playlistSaveCommand and playlistsRenameCommand in Slim::Control::Commands.pm.

See posts 30 and following from this thread <http://forums.slimdevices.com/showthread.php?t=26492>.

Not sure how to best handle this? Can we assume the name is received in the file system charset (and what of the case of the playlist saved using Safari on OS X for a Windows based server?)
Comment 1 Chris Owens 2006-10-10 15:02:26 UTC
I don't know if it's sane for you to look at this for 6.5.1, Dan.
Comment 2 Dan Sully 2006-10-10 15:26:22 UTC
It should be an easy-ish fix, but I'd want to do testing.

I'm going to push it to 7.0 - since the caller can do the charset conversion themselves.
Comment 3 Fred 2006-10-10 15:34:26 UTC
How do they do that when using the web interface? Same code is used...
Comment 4 Dan Sully 2006-10-10 15:35:45 UTC
Ah.. they don't. I thought this was a CLI issue.

So how does a UTF-8 string get created on a Windows system in the browser then?
Comment 5 Fred 2006-10-10 15:49:11 UTC
Actually, I am not sure what charset is used by the web browser. If you connect your Windows slimserver using Safari, what is the charset used? utf8 I guess...

In any case, even for a windows only setup, the same cp1252 string is used as playlist NAME (in the web GUI) and ends up being wrong (since the server thinks it is UTF8...)

Comment 6 Dan Sully 2006-10-10 15:51:58 UTC
Ah, I see now.

We'll need to try and identify the encoding of the string, and convert as appropriate.
Comment 7 Chris Owens 2007-10-22 09:48:25 UTC
Are you still seeing this, Fred?  Thanks.
Comment 8 Fred 2007-10-22 17:55:25 UTC
No, but I am no longer using SC on Windows, where the problem was. An all mac setup always worked. The problem is with systems using charsets different than utf8 either as display or filesystem.
It's pretty easy to test: create a playlist with an accented char from Safari on a Mac to a SC running on a Windows box (like élèment) - it used to fail badly, either when storing the playing or when subsequently displaying its name.
Comment 9 Michael Herger 2007-12-10 06:41:07 UTC
I successfully created a playlist öäéà in Safari/Mac, on SC7/Win. No problem. Feel free to re-open if needed.
Comment 10 Michael Herger 2007-12-10 07:15:05 UTC
Spoke too soon. While the interface does display it correctly, the filename stored on the disk is broken.
Comment 11 Michael Herger 2008-01-16 05:50:45 UTC
won't be able to fix this for 7.0
Comment 12 Michael Herger 2008-03-19 11:08:23 UTC
change 17935
Comment 13 Chris Owens 2008-07-30 15:29:55 UTC
This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Comment 14 Chris Owens 2009-07-31 10:14:02 UTC
Reduce number of active targets for SC