Bugzilla – Bug 2215
"ž" U+17E(0x9E): Latin Small Letter Z with Caron in flac filename prevents Slimsever from scanning tracks
Last modified: 2008-09-15 14:36:01 UTC
If a flac filename contains the character 0x93 (Central European "z with an inverted carrot) Slimserver can't scan the tracks of the embedded cuesheet. Tested version: Slimserver 6.2 svn 4452 on WindowsXP SP2 & Linux: Fedora FC4 1456 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." 4). Browse the music folder to /g_German_Baroque/Bach, J S/Arias1 - Magdalena Kožená.flac 5). Observe that 0 tracks were scanned. 6). Browse to other versions of the test file. 7). Observe that all tracks were successfully scanned in the other files, including the external CUE file which contains the offending character in its filename. Also observe that, as long as the flac filename does not contain the offending character, the fact that the album title contains 0x9E doesn't prevent the tracks from being scanned. On Fedora FC4, the "Arias5" album is also not scanned, whereas on Windows, it is. So, I suspect that this problem goes beyond just one character with an offending diacritic.
Created attachment 872 [details] Zipfile containing flacs that demonstrate the bug
To be more specific, that's unicode character U+017E or Windows: Central Europe U+017E (0x9E)
Actually I'm pretty sure it's that one character - and it's simply malformed in the filename. Can you rename that file? Reading & Parsing works fine here if I fix the character.
Sure, I can rename the file, but I don't think it's just that one character. If I use the very same flac file, but with all metadata stripped out, and use an external cuesheet (again, with the offending character in the file name) slimserver has no trouble scanning the tracks. So, I think this is a problem with the embedded cuesheet scanning code. Perhaps we could agree that this bug is actually a subset of bug #2219 (which I'm about to post more test files to.)
Gordon - are you doing any Samba/CIFS sharing of these files? Can you run this program (via ActivePerl) on the directory containing those files? I'm pretty sure that the filename is corrupted / doesn't map from cp1252 to UTF-8 properly, so the files aren't scanned. If I change my locale here to cp1252 (on OSX), I can scan those files just fine. I'll try this on my Windows box later in the day though.
Sure thing, I'd be glad to, but what program? Are you prepping an attachment?
Created attachment 880 [details] Directory Listing Tool
OK, this is what I get: Files names from Windows Explorer: Arias - Magdalena Kožená.flac Die Kunst der Fuge BWV 1080 - Leonhardt - Disk 1.flac Die Kunst der Fuge BWV 1080 - Leonhardt - Disk 2.flac Ouvertüren - Musica Antiqua Köln - D1.flac Ouvertüren - Musica Antiqua Köln - D2.flac Output of perl dir.pl encoding: [iso-8859-1] SV = PV(0x1933924) at 0x193fe34 REFCNT = 1 FLAGS = (PADBUSY,PADMY,POK,pPOK) PV = 0x182d6f4 "Arias - Magdalena Ko\236en\341.flac"\0 CUR = 29 LEN = 30 encoding: [iso-8859-1] SV = PV(0x1933924) at 0x193fe34 REFCNT = 1 FLAGS = (PADBUSY,PADMY,POK,pPOK) PV = 0x195434c "Ouvert\374ren - Musica Antiqua K\366ln - D1.flac"\0 CUR = 42 LEN = 43 encoding: [iso-8859-1] SV = PV(0x1933924) at 0x193fe34 REFCNT = 1 FLAGS = (PADBUSY,PADMY,POK,pPOK) PV = 0x195a454 "Ouvert\374ren - Musica Antiqua K\366ln - D2.flac"\0 CUR = 42 LEN = 43
Some recent change (perhaps the 4495 fix) now has slimserver successfully scanning the tracks to this album.