Bugzilla – Bug 4126
Manual changes to playlist files are ignored or discarded
Last modified: 2011-11-06 23:23:59 UTC
Playlist directory contains multiple playlist files (all .m3u), many containing invalid track paths After correcting invalid paths in a playlist file, I attempt to play the list - and get the same behaviour as before the correction. After creating a new (valid, I believe) playlist file with a text editor and putting it in the playlist directory, slimserver fails to display that playlist in the list of playlists - even after a server restart. Saving a playlist from the web interface works, slimserver sees the result and I can then play that playlist. But if I load the playlist into a text editor and modify the list, then play it from the web interface, the slimserver updates the playlist file and retracts the changes. Sample playlists: Test1.m3u was created through the web interface. It plays fine - but if I remove a track via a text editor, slimserver puts it back. Test1.m3u --------- #CURTRACK 0 #EXTM3U #EXTINF:-1,My Lover's Gone F:\Music\_flac\Dido\No Angel\04 - My Lover's Gone.flac #EXTINF:-1,I'm No Angel F:\Music\_flac\Dido\No Angel\10 - I'm No Angel.flac Test2.m3u was created via a text editor. slimserver 6.5b3 does not display this playlist. Test2.m3u --------- #CURTRACK 0 #EXTM3U #EXTINF:-1,Ferryman F:\Music\_flac\Chris de Burgh\Spark to a Flame- The Very Best of Chris de Burgh\02 - Don't Pay the Ferryman.flac #EXTINF:-1,Died in Arms F:\Music\_flac\Various Artists\#1 Hits 1985-1989\08 - (I Just) Died in Your Arms.flac
Created attachment 1544 [details] Test1.m3u - seen by slimserver
Created attachment 1545 [details] Test2.m3u - not seen by slimserver
I've cleaned up my playlist directory, so it contains only a small number of short playlists, then requested a rescan of the music library "only rescan playlists". Took minutes to complete (surprising). Web UI now shows most but not all playlists actually in the directory - * and continues to show some old playlists which have been deleted *. Zip'd contents of playlist directory are in attachment #3 [details]. Web UI shows these playlists: A few fun tracks AllFlacJun05 (not actually present in playlist dir) AllFlacJun05-Shuffle1 (not actually present in playlist dir) AllMusic Sep03 rel (not actually present in playlist dir) Benetar Faves Eclectic Mix KPCC NPR Test1 Test1copy Test2
Created attachment 1546 [details] Entire playlists directory
please don't preset targets. leave undef for review.
Doing a rescan - "clear library and rescan everything" results in an accurate reflection of the playlist directory, but doing a rescan - "only rescan playlists" does not.
playlists are stored in the slimserver database. you should go into server settings and start of rescan, selecting "playlists only" this should update the playlist data in the server.
A regular rescan should catch these changes, right Dan?
Yes. The output of --d_scan would be useful.
1. Saved a new, short playlist based on valid tracks, "test3.m3u", from the web ui. 2. Renamed playlist from "test3.m3u" to "renamed test3.m3u" from Windows Explorer 3. Enabled d_scan via web ui 4. Ran a rescan - "only rescan playlists" 5. After completion of the rescan, Web ui now shows *both* "test3.m3u" (nonexistent file) and "renamed test3.m3u". 6. Rebooted windows, restarted slimserver, turned d_scan on again, ran another rescan - "only rescan playlists" 7. After completion of the rescan, Web ui still shows *both* "test3.m3u" (nonexistent file) and "renamed test3.m3u". Resulting log file contains only a single line: "Setup::rescan - initiating scan of type: [rescan]"
In 6.5 under Windows, to get a log of the scanner process, you'll need open a command line, and go to "c:\program files\slimserver\server" (or wherever you installed SlimServer) and run "scanner --d_scan > log.txt 2>&1" This saves the output of the scanner process into a file called log.txt. You can of course use a different filename if you wish. Then please attach the log to this bug.
The command syntax you requested below is incorrect: scanner --d_scan > log.txt 2>&1" so I ran this instead: C:\Program Files\SlimServer\server>scanner --d_scan --logfile log.txt --playlists F:\Music\playlists While there's an error processing one of the playlists, maybe the root of the reported problem is simply that when doing a scan of playlists only, scanner.pl doesn't ever call runScanPostProcessing? Resulting log and offending playlist attached.
Created attachment 1553 [details] scanner log
Created attachment 1554 [details] "May misc" playlist causing scanner error
Michael - are you running the latest SlimServer nightly? Running --playlists does call runScanPostProcessing() Thanks
Created attachment 1572 [details] scanner log from 09-19 nightly build I've moved up to the 09-19 nightly. Problem persists. Log file attached.
This is still an issue with 6.5.3 - 12152, easily reproduced with the steps in comment #10.
I'm not sure comment 10 is an example of this bug. It only highlights that a playlist is not removed from the db if the playlist file disappears. This is already known, and is something that is still to be decided because it affects how slimserver is to handle the persistence of data when dealing with removable media. Obviously in comment 10, a new playlist is being seen. the log in comment 14 is invalid because the scan does not complete (symptoms appear to be the everpresent virusscanner issue, set virus scanners to ignore *.MYI and *.MYD files) To my understanding, this bug was about an edited playlist not updating slimserver and instead being overwritten by slimserver. I think this is likely due to the periodic writing of playlists, which we should only do if the playlist timestamp is earlier than the db record (if we actually HAVE that timestamp stored). Playlist scan should be updating from files to db only. I havent' spent enough time with that part of the scanner to suggest what might be causing the updates to go the other way. Certainly a wipe and rescan should take from the playlists, clearing any defunct playlist data.
The workaround is to do a rescan. Dean states the server should notice if the playlist file has changed and update the database.
Unassigned bugs cannot have a priority.