Bugzilla – Bug 4709
Hash characters (#) in music library directory names make contents unplayable
Last modified: 2007-09-05 14:36:59 UTC
If you have a '#' in a directory name within your library (like Big Star "#1 Record" or "Reggae Compilation #3") slimserver >= 6.5.0 pukes when attempting to play a song from that directory. Filenames are ok with the '#' - "Funk #49", for example, plays fine. I run slimserver on a linux system. Here's the log: 2007-01-23 14:35:04.9320 ERROR: openSong: [file:///u1/Audio/flac/B-Stock/Rock,%2 0Pop/Cure,%20The/Live%20Recordings/9999-99-99,%20B-Stock/1995-06-25,%20Somerset, %20England/Westwood%20One%20%2396-21/Disc%201/01%20-%20Want,%20Fascination%20Str eet.flac] Unrecognized type flc! 2007-01-23 14:35:04.9325 Backtrace: frame 0: Slim::Player::Source::errorOpening (/opt/SlimServer_v6.5.1/Slim/Play er/Source.pm line 1718) frame 1: Slim::Player::Source::openSong (/opt/SlimServer_v6.5.1/Slim/Player/S ource.pm line 380) frame 2: Slim::Player::Source::playmode (/opt/SlimServer_v6.5.1/Slim/Player/S ource.pm line 972) frame 3: Slim::Player::Source::jumpto (/opt/SlimServer_v6.5.1/Slim/Control/Co mmands.pm line 1103) frame 4: Slim::Control::Commands::playlistXtracksCommand (/opt/SlimServer_v6. 5.1/Slim/Control/Request.pm line 1483) frame 5: (eval) (/opt/SlimServer_v6.5.1/Slim/Control/Request.pm line 1483) frame 6: Slim::Control::Request::execute (/opt/SlimServer_v6.5.1/Slim/Control /Request.pm line 772) frame 7: Slim::Control::Request::executeRequest (/opt/SlimServer_v6.5.1/Slim/ Web/HTTP.pm line 686) frame 8: Slim::Web::HTTP::processURL (/opt/SlimServer_v6.5.1/Slim/Web/HTTP.pm line 536) frame 9: Slim::Web::HTTP::processHTTP (/opt/SlimServer_v6.5.1/Slim/Networking /Select.pm line 238) frame 10: (eval) (/opt/SlimServer_v6.5.1/Slim/Networking/Select.pm line 238) frame 11: Slim::Networking::Select::select (/opt/SlimServer/slimserver.pl lin e 492) frame 12: main::idle (/opt/SlimServer/slimserver.pl line 445) frame 13: main::main (/opt/SlimServer/slimserver.pl line 1071) Searching the forums, this fellow found the problem a while back and worked around it by renaming his directories. He's on windows, so it's apparantly a problem there too: http://forums.slimdevices.com/showthread.php?t=28988 I've verified that 6.3.1 does not have the problem, but 6.5.0 and 6.5.1 both do. Surprisingly, it doesn't look like anyone's filed a bug against it yet, so I am. John
It would seem that this bug does not affect people using mp3 files, per discussion in the forums here: http://forums.slimdevices.com/showthread.php?t=32043 I use flac on linux. I can't comment on other filetypes or OS's.
I have done some more research on this problem and have isolated the bug. Some assumptions were incorrect in the initial bug. The problem is not specific to flac or any other format. It is not platform specific in any way. I is also irrelevant if the offending characters are in the filename or directory part of the path. What is important is the specific sequence of characters, which in my library only appeared in the directory parts of the path, not the filenames. If I removed the #, the problem went away, hence the assumption. However, the true cause of the problem is the specific sequence of characters identified by the regular expression #[\d\.]+- occurring anywhere in the path to a music file. Example: /path/to/music#1234-file.mp3 -or- /path/to/album #12-34/track1.mp3 I've also done some hunting through the code and have isolated the offending code to Utils::Misc::stripAnchorFromURL(), which strips everything from that regular expression to the end of the file from the path. Oops. I'm not an expert on url anchors or what a better regexp would be. Perhaps only changing "#[\d\.]+-" to "html#[\d\.]+-". Getting closer... John
This is a duplicate of bug 4652. See the possible patch posted there.
(In reply to comment #3) > This is a duplicate of bug 4652. See the possible patch posted there. > Hmmm, I think 4652 is slightly different, though the patch you posted there is correct for this bug. Bug 4652 mentions: "On the 'Got' line, the path is truncated at the # character, after URI->path() function is called." The log entry given shows a filename that would not match the regexp in stripAnchorFromURL. It would appear that URI->path() might strip things from any # on in bug 4652, though I'd have to look at it closer to be sure. I think these are two seperate bugs, with similar symptoms.
Created attachment 1816 [details] Patch John, you're correct. They are different issues. Here's the patch again for this bug. I should handle nearly all cases.
Assigning to Dan to have a look at Jim's fix.
Fixed in trunk r12897, 6.5 r12898
change 12897 and change 12898 (for the links)