Bugzilla – Bug 3201
Playlist scan fails
Last modified: 2008-12-15 11:58:01 UTC
On the 3-25 build of 6.2.2 my playlist list (Browse Playlists) is empty. this is true from SB or from the web interface. On reverting to 3-22 build and rescanning, it is OK. I have a specified playlist directory, not the default, if this makes any difference. But unlike bug 3200, I don't crash - just see an empty playlist list. It appears that the playlist directory is being scanned, since I see errors in the log if my broken AlienStream directory is in the playlist directory. But the scan fails even without this condition.
do you have "look for artwork" disabled, by any chance?
Strange, the only changes between 22nd and 25th builds are the addition of a TTF font, and Dan's stuff to remove DRM files from the scan. It should not have affected playlists. However, the db version was updated, so that would have triggered a full rescan to clean out the drm files and the column used to track them. could it be that you tried the rescan while this automatic scan was in progress? a wipee and rescan might be all that is needed for latest build.
I just fixed this in change 6720
I do have look for artwork disabled.
This is not fixed in the 3/26 build. I had 3/22 installed, and my playlists were normal. I installed 3/36. Playlists still appeared. I did a clear library and rescan. My playlists were then empty. I reinstalled 3/22. Playlists still empty. Did a clear and rescan and my playlists are again seen.
See http://forums.slimdevices.com/showthread.php?t=22496 for another user seeing this. It is still broken 3-28 I tried removing the .db completely, it still fails the same way.
looks liek the playlists are in the db, but the browse playlist is finding only for ssp content types. the db shows the playlists as m3u types. I forget what 'ssp' was for, but it seems that either m3u, pls, etc should be in the list as well or they should be getting converted to ssp as we bring them into the db.
ah, I see what is going on here. the playlist is getting set to 'ssp', but the update isn't happening becuase the _hasChanged logic skips the update. This bit of code was added in change 6696 as part of the DRM skipping. This check should probably be shotcutted for playlist files, since they do require a forced update to change teh content type to 'ssp'. I can either a)change the logic to: if (Slim::Music::Info::isFileURL($url) && !Slim::Music::Info::isPlaylist($url) && !$self->_hasChanged($track, $url)) { or b) add a named arg to updateOrCreate for 'forceUpdate'. I'm not sure why this isn't a problem in 6.5, but there is another param in the test, $checkMTime. I guess, since this isn't set, then the playlist update works. Perhaps this addition of the hasChanged check was premature for 6.2? perhaps c) find and and merge the $checkMTime logic.? let me know, and I can take care of it.
this bug makes using new dalys a non starter - including trying the new firmware. Hope it gets fixed soon one way or another.
This should be fixed in change 6803 In the 2006-04-02 nightly.
This fixed the original problem. Thanks.
This bug has been fixed in the latest release of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.