* Gordon Harris shaped the electrons to say...
That's definitely it then - your windows box is likely in cp1252 aka iso-8859-1.
Dan: is there a bug # for this? I'd like to follow the progress for a fix for
this problem. I expect my squeezebox2 to arrive tomorrow, but, as it is, about
1/2 of my flac music collection won't be scanned by slimserver 6 because of this bug.
Gordon - it's not really a bug. If you are doing some type of file sharing -
the character sets / code pages on the machines need to be the same, or some
translation needs to be done on one of the sides.
The issue here is that your Linux charset (LC_CTYPE) is set to UTF-8 in
/etc/sysconfig/i18n (or similar), which is fine in and of itself. But when
mounting the remote Windows share, that charset is cp1252 in windows speak,
iso-8859-1 / latin1 to the rest of us. There's no way for SlimServer to know
that however, so the names get munged, thinking they are UTF-8 when they aren't.
The fix here should be adding the iocharset and codepage options to the smb
mount.
From the smbmount(1) man page:
iocharset=<arg>
sets the charset used by the Linux side for codepage to charset
translations
(NLS). Argument should be the name of a charset, like iso8859-1.
(Note: only kernel 2.4.0 or later)
codepage=<arg>
sets the codepage the server uses. See the iocharset option. Example
value
cp850. (Note: only kernel 2.4.0 or later)
So the command would look something like:
mount -t smbfs -o iocharset=utf8,codepage=cp1252 remote\\path /mnt
-D
--
It is dark. You are likely to be eaten by a grue.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
