Bugzilla – Bug 9559
CLI Charset command not working
Last modified: 2009-09-08 09:25:43 UTC
SqueezeCenter Version: 7.3 - 23234 @ Mon Sep 22 03:12:53 PDT 2008 - Windows XP - EN - cp1252 Server IP address: 192.168.35.12 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Platform Architecture: 586 After updating from SC 7.0 to 7.1, 7.2, 7.2.1 and 7.3 the CLI ignors the tag "charset:iso-8859-1". Haven't tried other charsets. Everything was OK in SC 7.0. example: send - "albums 0 10 search:cafe charset:iso-8859-1\x0A" recieve - "albums 0 10 search%3Acafe charset%3Aiso-8859-1 id%3A67 album%3ACaf%C3%A9%20del%20Mar%20-%20Volumen%20Cuatro id%3A65 album%3ACafe%20Del%20Mar%20Volumen%20Dos id%3A66 album%3ACaf%C3%A9%20Del%20Mar%20-%20Volumen%20Siete count%3A3\x0A" Looking at the 1st album result "album%3ACaf%C3%A9%20del%20Mar%20-%20Volumen%20Cuatro" the result is, I believe, still in utf8 encoding as the first word should be Café so the result should be "Caf%E9" if it is encoded using charset:iso-8859-1.
Dean, is Fred still available for CLI bugs? Or are we fixing them ourselves these days? Note to self: slim devices @ thomas corner.com
Hey Fred, Would you be interested in looking at this bug? :)
The CLI code has not changed. What has changed is the format of the strings returned by Schema calls: they used to be in Perl internal format (because encode(string, 'utf8') returned the right thing) - they are now in utf8 on my Mac (and encode(string, 'utf8') gets confused - encode(string, 'iso-xxx') as well). The question is in which format are those strings supposed to be in - and is this true on all platforms (or will the strings be cp1252 or something on Windows) ? Once this is known then it's only a matter of changing lines 2274, 2299 and 2321 in Request.pm with the code to translate the string in $encoding. It currently uses encode as internal strings used to be in Perl's format. If utf8 is now used internally (side question why ?), using encode::from_to may be the solution (assuming $encoding is not utf8). Hope this helps Fred (sorry Chris, yes it's slimdevices at thomascorner dot com)
Thanks Fred. We can't rely on the encoding always being utf8. Windows uses cp1252 - as you assumed. Change 23806 uses the system's locale to determine how the encoding has to be done. Please give it a try.
I'm sorry, that didn't fix the issue :-(
Created attachment 4201 [details] fix charset parameter in CLI Try harder, add error handling in case Encode croaks.
change 23819 - fix CLI's charset parameter - we have to wrap the conversion in eval() to protect from failure on wide characters when doing something like utf8 -> iso-8859-1
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html 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.
Reduce number of active targets for SC