Bugzilla – Bug 2196
Slimserver incorrectly interprets UTF8 encoded 0xA0 Non-breaking space character
Last modified: 2008-09-15 14:36:01 UTC
Slimserver 6.2 incorrectly interprets 0xA0 Non-breaking space characters in cuesheet files, both external and flac embedded when they are UTF8 encoded. All flac embedded metafile cuesheets are UTF8 encoded by default and (I think) according to the vorbis tag spec. Character 0xA0 (in ansi) or 0xC2,0xA0 (UTF8) represents a non-breaking space and should be interpreted as a valid character in metadata by slimserver. The posted zip file includes testfiles which demonstrate the bug. Steps to reproduce the bug: 1). Download the posted zip file and extract the test files to a folder. 2). Set Slimserver's music folder to the folder containing the test files. 3). Perform a "Clear library and rescan everything." 3). Browse the library to the album "Test cuesheet with 0xA0 non-breaking spaces, UTF8 encoded" What you will observe: Slimserver 6.2 correctly parses metadata and and indexes the ansi encoded cuesheet that contain 0xA0 characters. With the UTF8 encoded cuesheet, however, Slimserver does not extract TITLE information for the tracks that include 0xA0 characters in their title metadata. These tracks get no title information associated with them. Slimserver can't deal with the unicode encoded cuesheet files at all, but that should probably be thought of as a separate bug.
Created attachment 857 [details] Zip file containing test files which demonstrate the bug
Hi, it seems Im hitting this same bug. Gordon, can you try adding a 0xA0 Non-breaking space character in the TITLE of the album? If after that the album does not show up in the album list, then I guess we are in the same situation. BTW, I think this is the cause of another issue I wash having, with genres that include space characters not showing up in the Genres list. I will try to confirm it. thanks! Néstor
This works fine on OSX - again, appears to be a Windows specific problem.
Fixed in subversion change 4441