Bugzilla – Bug 2773
SlimServer crashes while scanning library - needs validation for paths greater than 255 characters in length on Windows
Last modified: 2009-09-08 09:31:40 UTC
The above-referenced thread gives the background on this issue. Using debugging via the command line, I figured out what is happening. SlimServer is parsing my cue sheets, and then looking for the referenced .wav files. I used EAC to create cue sheets when ripping to flac. EAC put the cue sheets in the root folder, instead of in the album folder (not sure why). So the file names in the .cue file have paths relative to the folder in which EAC placed the .cue file. SlimServer is combining that path with the path to the folder it is currently scanning, resulting in a huge and invalid path, for example: E:\My Music\Library\Licensed\Beethoven\Favourite Piano Sonatas (1971) - A. Brendel\CD 2\Ludwig van Beethoven\Favourite Piano Sonatas (1971) - Alfred Brendel (1971)\06 - Sonata No 21 in C major op 53 'Waldstein'; 3. Rondo (Allegretto moderato - Prestissimo).wav This path is 261 characters long. I think this is what is causing the crash. SlimServer should either know not to treat .cue as playlists, or let me tell it to ignore .cue files completely. Regardless, it should always validate the path length before looking for the file.
There are users who use their CUE sheets for track splitting and metadata. The server uses CUE sheets for this purpose, and not for playlists. One thing you can do in the near term is to remove the "cue" line from types.conf. After restarting the server, this will make the server ignore cue files as a valid file type for scanning.
According to the thread, the issue is really that long paths cause "Perl Interpreter Failed" on windows (paths greater than 255 characters. Dan, any idea how to prevent the crash?
Dean: If I remember this bug, and it's been a while, the problem is that perl dies when handed an illegal file name. Perl should not fail when handed an illegal file name, but should return some sensible error message. It is hard, in general, to know what constitutes an illegal file name, since perl may be running on a windows XP system, the file may exist on a linux system and the transport between them might be a network file system like samba. Or it might be another windows system and using netbios as a transport. Each of the systems may have their own rules and presumably the most restrictive rule applies. I don't know how an application running under perl could find this stuff out. I'm not even sure if perl can find it out. The only way is for perl error trapping to work, but that's what didn't work. I think the problem has to be reflected back to the activestate people. You could work around it for now with an artificial limit like 255 characters, but then some people running on systems that allow 511 character file names might complain that they can't play their song "Montovani as played by the Bethovenhalle Millenial Symphonie with George Burns conducting and Frank Sinatra, Freddie Mercury and Elvis Presley added electronically after death.mp3" well you get the point.
Change 8171 allows one to add file extensions to ignore. This will be in the 06-29-2006 nightly build. Long paths should also be handled ok by the 6.5 tree. Please reopen if you are able to reproduce on 6.5 - it's working fine for me on WinXP