In 6.0.2, small changes to playlists were immediately recognized. For example, I could add a new radio station to an existing .m3u file and SlimServer would re-read the file and the change would be effective immediately. Not so on 6.1.1. It appears that a rescan is now necessary. However, when I use rescan with the 'rescan playlists only' option, SlimServer crashes.
Suffice to say, because of these (and numerous other issues) I've had to revert back to 6.0.2. I recall reading that in 6.1 playlists are now stored in the database, which is fine, but there should at least be some sort of trigger mechanism to immediately auto-rescan playlist files that have changed. The best solution would combine both file and database capabilities. For example, always 'reference' the playlist from the file, but load and manage the playlist's entries from the database. When the playlist is referenced from the file, SlimServer can detect if anything has changed (e.g. last modified date/time or file size, etc.). If nothing has changed, load the playlist entries from the database as usual; otherwise rescan that particlar playlist into the database. Likewise, if the referenced playlist no longer exists in the file system, purge it from the database. A database is great for speeding things up, but it should be compliment the file system, not attempt to replace it. A more intelligent 'dynamic rescan' capability needs to be implemented. A full rescan should rarely be necessary, and certainly not when a single playlist entry is added. -- rds _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
