Bugzilla – Bug 3256
Deletion of playlists on "clear library" rescan
Last modified: 2008-09-15 14:38:10 UTC
Using 6.2.2 - 6858 - Windows XP - EN - cp1252. When a "clear library and rescan everything" rescan is initiated, any .m3u playlists made through the Squeezebox or the UI get deleted. This includes the "Zapped Songs" playlist created through the SB. This behavior, consistent since 6.2.1, seems purposeful since SlimServer actively goes out and deletes local files. This feature does not make much sense - why would the user want to delete all SlimServer-created playlists just because the library has been recreated? Perhaps the thinking was that files in the playlists might no longer be valid, but shouldn't that be up to the user to determine? The playlist can then be deleted or edited.
The only calls in the code that delete a playlist from the disk are found in teh edit playlist handlers. Can you confirm that they actually exist on the drive before being wiped out? It could be that they are created in the DB, show up in Browse Playlists but don't get written out to the drive. If you then wiped and rescanned, they would be lost and unable to be recovered due to the lack of the files on HD.
Sorry, yes you're right KDF, they aren't actual .m3u files (I could've sworn that I once saw "Zapped.m3u" on that drive before!) Is there any way to make them persistent or do they only exist in the database? It would be nice to keep them after a rescan.
make sure you have a playlist folder in server settings, and that it is writeable. You should be able to see something in d_playlists, maybe also d_parse. The zapped playlist should write out. Playlists saved from current playlist 'save' link certainly should. This was an older bug and should be fixed by now.
Well it's definitely writing .m3u files now. I'll have to see if the file stays on rescan. The log is showing: "2006-04-11 10:20:15.4038 Slim::Formats::Parse::readM3U: WARNING: file:///K:/My%20Music/Beastie%20Boys/To%20the%205%20Boroughs/Crawlspace.flac found in playlist: [Comment: I just deleted this file, so no worries here] file:///K:/My%20Music/Zapped%20Songs2.m3u doesn't exist on disk - skipping! [Comment: I was playing around renaming playlists to see if they wrote files. I believe I had deleted Zapped Songs2 at this time.] 2006-04-11 10:20:20.3506 ERROR: Couldn't open playlist file file:///K:/My%20Music/Zapped%20Songs.m3u : No such file or directory [Comment: Now that wasn't true, I never deleted Zapped Songs.m3u.] 2006-04-11 10:23:11.0293 Not writing out untitled playlist. 2006-04-11 10:23:27.1858 currentPlaylistChangeTime : Mon Apr 10 20:16:16 2006 2006-04-11 10:23:27.1859 currentPlaylistRender : Tue Apr 11 10:20:25 2006 2006-04-11 10:23:27.1860 currentPlaylistRenderSkin : 2006-04-11 10:23:27.1860 currentPlaylistRenderStart: 0 2006-04-11 10:23:27.1861 skinOverride: 2006-04-11 10:23:27.1862 start: 0 2006-04-11 10:23:27.1863 Skipping playlist build - not modified." [Comment: Not sure what was going on there, but the UI seems to be behaving as expected with regards to playlists.] I will turn these debugging options on during my next rescan and report back.
OK, I just did a "Clear library" rescan. A playlist saved using the web interface (which created an .m3u file) stayed after the rescan. The Zapped Songs playlist didn't. I believe you indicated that this is correct behaviour if I'm interpreting the statement "write out" correctly. I thought for sure I saw a "Zapped Songs.m3u" file in that directory when I wrote my last comment, but it was gone just before the rescan and is completely gone now. It'd be nice to have Zapped Songs persist though, so I'll keep the bug open but change it to an enhancement if that's OK with you. Otherwise close the bug. Thanks for your help.
I worked on the save playlist issues a while back, so I was sure that the playlists saved via web were created on disk. What I was not sure of was if Zapped.m3u still gets written to disk. I haven't looked at that stuff for a long time. Try zapping a few songs, then check if the file is being created. d_playlist logging might show some output when it creates and tries to write the file. Then, if you get a file on disk, see if it really does disappear. I still can't see how an actual file gets deleted. If the file isn't being written out to disk, I'd call it a bug personally, but it may not have been SD's intent when the playlists moved to the db.
I'm seeing the zapped playlist not written problem on the 4/15 build. If I zap an item, a zapped playlist shows up in the playlist list, with the correct content. But its not written to disk. If I do a save of a new playlist it is written to disk. I have d_playlists enabled, but see no log information for either event. I use zapped to keep track of ripped programs I've heard so I can delete the files at my leasure. So this is a problem for me.
It looks like the playlist isn't being written out. The following line might help: Slim::Player::Playlist::scheduleWriteOfPlaylist($client, $playlistObj); 6.2.2) add to Control/Command.pm after line 1014 6.5b1) add to Control/Commands.pm after line 1060
6.5 fix committed at change 7034 holding off for 6.2.2 until this is verified
a real bug, not an enhancement
committed to 6.2.2 at change 7069, handles writing out the zapped playlist. I'm not suer what else is really remaining here, but I'll leave it open for clarification.
I have tried 6.2.2 as of 4/23. It includes 7069 - I checked command.pm for the inserted line. Zappped playlists, at least in my test, are NOT written out. My test - play a track located by browse music folder. In now playing, press and hold add. A zapped playlist appears - its in the data base and looks correct. But nothing is written to disk. Rescanning playlists of course looses the zapped playlist.
looks like it needs the full path for the url. corrected at change 7072, 7073 for both 6.2.2 and 6.5 respectively.
I pulled the command.pm from 7072 into my 4-23 build of 6.2.2. The behavior has not changed for me - zapped still not written out oven though its in the data base. I also tried 7073 on 6.5.1, with no luck. I have my playlist in a place other than the default directory, if that matters.
if you are using slim.exe, it will not change anything, as it is pre-packaged. I confirmed the function myself before the commit and it works for me, so there is little else I can suggest. The code is the same as that used for saving the current playlist. Try that out as well. If you are using slim.exe, please wait for the next build. for debugging purposes, try running command line ("failed to write" messages might appear there) or use d_playlist and that should show something when the playlists are written. thanks
I am running slim.exe on WXP so I'll try again tomorrow and report.
This is fixed for me in the 4-24 build of 6.2.2. (I also checked the changed commands.pm against 651 and it worked). I'll let someone else close this - it isn't my bug.
Just a thought: Changing the urls of playlists will have an impact on plugins that work with playlists. ie. it might break them. But I suppose that is up to the plugin authors to maintain them.