There is a task, roughly covered by bug 16683, to get to grips with all the problems in SbS associated with use of file names and directory names which contain non-ascii characters.
This is focussed on the audio library. It is intended to cover scanning and browse-music-folder (BMF) functionality, and the subsequent playing of those files. It should cover the SqueezePlay, ip3k-Player and Web UIs and the CLI. It should cover: a - audio files which contain a non-ascii character in their name; - directories (folders) within the library, and which may contain audio files, where the directory name contains a non-ascii character; - playlists which contain a non-ascii character in their file name (not the names of files listed in the playlist); - "non-ascii" should include characters outside the range of ISO 8859-1 (Latin-1); - a library root directory (*audiodir* preference) or playlists root directory (*playlistsdir*) which, at any point in the pathname, contains a non-ascii character; - an artwork directory specified by the *artfolder* which contains a non-ascii character in its pathname; - artwork files identified by the pattern specified by the *coverArt* preference where the resulting filename contains a non-ascii character. All of these should work in cases where the locale character-set encoding in use is fully consistent; that is where the pathnames (or components thereof) in the filesystem are presented and accepted at the system-call APIs used by Perl encoded in the same character-set encoding as used by the system (or, at least, under which SbS is run). Complications arise because: i - a filesytem may contain pathnames with characters encoded in a different character-set to that of the system locale (for example, the system locale may use UTF-8 but the filesystem may contain pathnames encoded using 8859-1); - a filesystem may be mounted with flags indicating that its pathnames are in a particular character-set encoding (which, if different from the character-set encoding of the system locale, the system is supposed to handle re-encoding as necessary) but may actually contain pathnames in a different character-set encoding; - the system may not be able to translate reversibly between the file-system character-set encoding and that of the system locale (for example, if the system uses 8859-1 and the filesystem uses UTF-8); - the remote filesystem-access protocol (SMB, NFS) is incapable of (or incorrectly configured) passing the pathnames without mangling the character-set encoding. A guiding principle of these changes is that SbS should avoid, whenever possible, making any assumptions about the character-set encoding used for pathnames. It deals with all pathname components as native (encoded) byte-strings. This should cover scanning, BMF and playing of files (a, b & c above) even if there is some inconsistency in the character-set encoding used (i). This breaks down for items (e) and (f) above, where a UI is involved in entering the data, item (g) where the data is acquired from tags (and also for pathnames in playlists, but they have other problems too), and (ii), (iii) & (iv) where all access to the affected files will be broken. I have tested the changes pretty extensively on Linux (both UTF-8 and 8859-1) with local filesystems and NFS, and minimally so far on Mac OSX and Windows with local and SMB filesystems. If anyone is interested in testing any or all this, especially on Windows systems, I should be pleased to hear the results. I'd be particular interested in results of Windows systems where the system code page does not include ASCII as a subset. -- awy ------------------------------------------------------------------------ awy's Profile: http://forums.slimdevices.com/member.php?userid=7480 View this thread: http://forums.slimdevices.com/showthread.php?t=83641 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
