Bugzilla – Bug 4574
file named "#41-.flac" not index by SlimServer, and doesn't play via music folder
Last modified: 2011-11-06 23:24:43 UTC
A customer reported this issue and I've reproduced it by naming any flac file #41-.flac then pointing SlimServer to a directory with this file. SlimServer doesn't index the file, and when you browse via music folder and try to play the file you get "Problem: Can't open file for". Apparently thats the name of a track on a Dave Matthews album.
--d_source log?
#41.flac = readable, 41-.flac = readable. #41-.flac = not readable curious.
The song title, however, appears to be "#41" (Dave Matthews - Crash). Not sure why the dash is there, but if it wasn't it would work AND match the song title. # and - are not really filename-friendly characters.
So Ross, the workaround is clear: remove the '-' character. And if you could get the customer to provide the --d_source info KDF mentioned, I would appreciate it.
actually, the d_source info ins't much use. It's just something about nothing to do with an unknown format. The problem appears to stem from the scanner itself or rather the CPAN file finding module used by the scanner, which doesn't find files with what it considers as bogus filenames. I can't really find anything in 6.5.1 that shows where this is happening, but using --debug=formats.playlist in 7.0 does attempt an errors message, but the content of the error comes back as undefined. Basically, it's as if the file doesn't exist.
Hmm the windows file system doesn't seem to have any innate problems with files named that way. I wonder if it's another perl/windows bug like bug 2475.
Unassigned bugs cannot have a priority.