Bugzilla – Bug 1563
Perl Interpreter fails when a playlist with relative paths is selected
Last modified: 2008-09-15 14:37:04 UTC
I created a .m3u playlist via Windows Media Player, and stored this within the my SlimServer playlists folder. When I attempt to do anything with the playlist, SlimServer crashes. It takes about 2.5 minutes to finally crash, reporting "Perl Interpreter Failed" in the windows event log. I can think of two possible problems that might be causing this: 1. Relative paths have been used to reference the tracks. 2. The folder that the tracks were in is not within my SlimServer music folder. I think the reason for (1) was that the playlist was originally created using Windows Media Player. I did (2) this because the tracks are podcasts automatically downloaded via a separate application called GetRight (an auto download manager), which can append downloaded music podcasts to a playlist created in WMP. The .mp3 podcasts don't have good tags, so I didn't want to add a shortcut to this download folder into my slimserver music folder. If the above is not a valid way to expect slimserver to operate, I would at least expect slimserver to fail graciously! When a playlist entry points at a file that doesn't exist anymore, I usually see an error, and slimserver will skip to the next track. I can't even select the playlist to delete without slimserver/perl crashing!
if this is relative paths (WMP 10) that is the problem, it is a dupe of BOTH bug 1506 and bug 1282. see patch attached to those bugs.
also...it is more useful to report the full bug, then to detail how slimserver fails to meet how you expect it to perform. clearly...ANY crash needs to be fixed.
sorry...not full bug, full error msg
Firstly, sorry about not completely identifying the problem initially. I was late getting up for work, because the SqueezeBox alarm didn't wake me up - this was due to this problem - the playlist crashed the server. I was actually awoken by the Squeezebox reporting an error in bright text ;) I wanted to log a bug report quickly before going to work, else I'd forget about it. I did a little bit of prelim investigation whilst writing the bug report, rather than just "perl interpreter failed - don't know why!". I should have checked for dups before raising the PR, but didn't have a clear idea what the problem was initially - I thought it was a fault with the alarm code to start with, as I discovered that it crashed exactly 2.5 minutes after the alarm should have started. Secondly, I don't think I have detailed how I expect slimserver to work. I was merely trying to say that if slimserver cannot play files that are not indexed by the scanning process (ie. a playlist entry referencing a file outside of the slimserver music folder), then it should prevent an error, rather than trying to suggest that slimserver should be changed to allow the files to be played. I have now investigated the problem further tonight, and can confirm that my crash does appear to be solely due to the use of relative paths in my playlist. I tried creating a playlist that has an absolute path to a file on another partition outside of my slimserver music folder. This displays the file tags and plays fine from the playlist. So if the playlist relative path problem is being fixed on another bug, this bug can be marked as a duplicate.
I needs some testing from willing victims, since it is a bit of an ugly hack from my perspective. If you are running the slimserver.pl version on your system, it may be worth a try to be sure it does work. I only had a couple test cases to work with.
I manually applied your change, and ran slimserver.pl. Seems to work fine.
Fix from kdf commited in subversion change 3280.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.