Bugzilla – Bug 1506
WPL playlists with relative paths cause the server to crash
Last modified: 2008-09-15 14:37:04 UTC
will attach a log with d_source d_playlist and d_files, as well as a sample playlist. reproduced with may 6 nightly of 6.0.3.
Created attachment 491 [details] sample WPL playlist with a relative path i did not change the path to a relative path, Windows Media Player put the relative path in there all by itself...
Created attachment 492 [details] log of the crash with d_source d_playlist d_files
this is probably related to bug781 of course, what no one has asked yet... if slimserver is to support relative paths in playlists - relative to what?? WMP would make it relative to its own choice of roots
also related to bug 1282 (not specifically dupes, though)
In answer to KDF's question in comment 3, slimserver 5.4 supported relative paths just fine; they were relative to the location of the playlist file itself. This interpretation is common among all the windows players I've tried (wmp, foobar2000, qcd). This bug doesn't really block 781, because 781 talks about the playlists created by the slimserver itself, which are m3u files, not wpl.
correct. I meant to just meantion it in a comment, but accidentally left the block entry in. I wonder if this crash still happens with 6.1 builds? line 578 seems to have no requirement for an array ref, and isn't even involved in wpl.
line 647 in 6.1 is the same crash. out of curiosity, I changed it to an absolute path and it still crashes, so I guess this isn't related at all with the others :) I wonder if the real problem is that its a playlist of one file.
Created attachment 495 [details] fix to handle single item playlist becuase this sample playlist has only one item, the assumption of an array to parse caused a crash. This patch fixes it. with this patch, this becomes a dupe of bug 1282 where we have deep recursion if the path is relative. changing the path to absolute in the sample playlist now works.
reassigning to vidur for consideration in tandem to bug 1282. parsing the relative item gives this: Deep recursion on subroutine "Slim::DataStores::DBI::DBIStore::objectForUrl" at D:/slim/server/Slim/Music/Info.pm line 295. Deep recursion on subroutine "Slim::DataStores::DBI::DBIStore::_checkValidity" at D:/slim/server/Slim/DataStores/DBI/DBIStore.pm line 151. Deep recursion on subroutine "Slim::DataStores::DBI::DBIStore::_hasChanged" at D:/slim/server/Slim/DataStores/DBI/DBIStore.pm line 1038. Deep recursion on subroutine "Slim::Utils::Misc::pathFromFileURL" at D:/slim/server/Slim/DataStores/DBI/DBIStore.pm line 1073. Deep recursion on subroutine "Slim::Music::Info::isCached" at D:/slim/server/Slim/Utils/Misc.pm line 222. Terminating on signal SIGINT(2)
well, the customer i was speaking with was experiencing problems with playlists that were far more than one file... this is just one i whipped up to test with...
relative paths are still a problem. The sample uncovered a different bug :) I know where the problem is (Utils::Misc::fixPath). ..\Documents gets fixed to c:\playlists\..\Documents somehow.
attachment 495 [details] commited to 6.1 at change 3144
Created attachment 499 [details] fix relative paths it may not be the prettiest method, but it works. tested on winxp with a wpl created by wmp10. same patch as attached to bug 1286
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.