Bugzilla – Bug 1758
Deleted iTunes Playlists Persist in SlimServer Database
Last modified: 2008-08-18 10:54:16 UTC
iTunes playlists remain visible in the SlimServer's listing even after they've been deleted from within iTunes and the iTunes Library file has been updated. This problem can be resolved by stopping the SlimServer process, deleting the cache directory and restarting the daemon. This may be related to bug 1475: 'disabled itunes tracks require wipe cache to re-enable' Bug is easily reproducible on my system. Try this: - Run latest version of iTunes from Windows XP. - Create a new playlist called 'test'. - Export the iTunes Library to a directory visible by RedHat server. - Wait for SlimServer to update database via iTunes Library. (New 'test' playlist now visible to SliMP3.) - Run latest version of iTunes from Windows XP. - Delete the new 'test' playlist. - Export the iTunes Library to a directory visible by RedHat server. - Wait for SlimServer to update database via iTunes Library. (Deleted 'test' playlist still available -- BUG!) - Stop SlimServer process on RedHat machine. - rm -rf slimp3/Cache directory. - Restart SlimServer daemon. - Wait for SlimServer to rebuild iTunes playlists. (Viola, 'test' playlist is gone)
Have you tried 6.1b1 yet?
No, I haven't. Trying 6.1b1 right now... standby...
6.1b1 does not appear to solve the problem. I can, however, make the deleted playlist go away by performing a library rescan with the 'Clear library before rescan' option checked.
well, delete library is just a way to bypass the usual lazy deletes and wipe everything before starting fresh. performance goes down the toilet if it is all about instant updates from external sources. Try letting it just stay running.
committed a possible fix at change 3610. i've tested it and it appears to remove a playlist at the next itunes reload. Please download July 5 build and confirm.
A side effect of this change, I think, is that the itunes playlist will disappear during the time that the itunes xml file is being imported until we hit the portion of the file with the lists in it. I suggest that the clearing be deferred until we hit the first playlist in the xml file during the scan. Dan and I discussed this some time ago, and i thought it was resolved, but maybe not. pointing this to dan.
np, fix was left open since it was expected to be a bridge until the new parsing becomes available.
KDF: can you move that call to the point where we start parsing playlists? The new parsing isn't going to make it into 6.1, but the window of time between when we start scanning the xml file and we hit the playlists may be quite long.
I actually tried to do that last night. There isn't currently any way to detect. However, I'll work up a simple state machine like we have in MusicMagic (though we only need 2 states for this one). I'll clear out the other clearPlaylists case as well, since this new method should handle it all.
d'oh...dunno how I missed it last night. a quick glance today and I see just where it needs to go. will commit tonight before build time.
committed at change 3622
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!