Bugzilla – Bug 16188
scanner effectively removes custom protocol URLs from scanned playlists
Last modified: 2011-01-24 11:51:12 UTC
I created a plugin that provides two new protocols. The protocols work fine with the Tune In URL feature in the web interface, and can be saved to playlists from within the SBS Web interface. But if you request a full rescan, the scanner process does not recognize the custom protocols and ignores the lines in the M3U playlist that refer to those URLs. The end result is that after the playlist is rescanned, the custom URLs are effectively dropped from the playlist. This is better than what's described in bug 6721 but still a huge problem for anyone trying to implement a new protocol that a user might wish to embed in a playlist. I think the key problem here is that the scanner runs in a separate process, so it has no access to the list of protocol handlers registered with the main server. There needs to be some sort of interprocess communications to let the scanner know what the valid protocols are rather than hard-coding 6 specific protocols in scanner.pl Probably scanner.pl should make JSON/Comet requests of the main process to populate the @handlers array that's currently hard-coded, though other approaches could work (the main process could maintain information in the database or a file in the cache directory).
To make this more clear, with the SBS web UI I can build a playlist like /music/someartist/somealbum/track1.mp3 /music/someartist/somealbum/track2.mp3 squeezecli:p0=mixer&p1=volume&p2=%2B20&title=Turn%20the%20volume%20up /music/anotherartist/anotheralbum/track0.mp3 and it plays & saves fine. I can even use the songinfo.html pane to view metadata about the squeezecli: URL. But after a full rescan, all I see in the web UI is /music/someartist/somealbum/track1.mp3 /music/someartist/somealbum/track2.mp3 /music/anotherartist/anotheralbum/track0.mp3 because the scanner didn't recognize the squeezecli: URL. And if I play the playlist after a rescan, the squeezecli: URL is not played, even though the line *is* present inthe M3U and *is* a protocol recoognized by SBS.
I'm pretty sure this must be the same issue as 16141 ( Napster playlists empty after library rescan )
Created attachment 6824 [details] simple fix -- main app writes CSV file with all registered handlers that scanner references This fixes bug 16188 for me, and I expect it will also fix bug 16141. With this patch: - the main SBS maintains a file called "handlers.txt" in the cache dir listing all registered protocols except http, file, playlist, and db. This file is updated every time a protocol is registered. Typically it looks like source,napster,classical,lfm,sirius,icy,mediafly,loop,randomplay,live 365,deezer,queen,spdr,rhapd,pandora,slacker,rtsp,linein,mms - the scanner process loads the list of protocols from handlers.txt instead of using a hard-coded list As a result, all registered protocols -- including newer protocols from core SBS code like napster and 3rd-party protocols -- are recognized by the scanner and their lines left intact when scanning playlists.
*** Bug 16218 has been marked as a duplicate of this bug. ***
Andy, if you would like me to take a different approach in fixing this bug, please let me know. I know this patch is pretty simplistic, but fewer lines of code means lower probability of regressions, right? :-)
I think there could be a two-phase fix on this one. A very low-risk fix would be to simply add a few of the "known" protocols to the code (especially Napster for me!). Then somewhere down the line Peter's more elegant fix could be incorporated?
I think this is a duplicate of a bug report I made over 2 years ago: https://bugs-archive.lyrion.org/show_bug.cgi?id=8874
== Auto-comment from SVN commit #31287 to the slim repo by adrian == == http://svn.slimdevices.com/slim?view=revision&revision=31287 == Bug: 16188 Description: ensure the scanner knows about all remote protocols which are handled by protocol handlers in the main server, but not loaded in the scanner process, check urls when scanning M3u playlists so that remote tracks in stored playlists are retained
Adrian, my initial testing looks good. I'm getting some weird little scan errors (and some database is locked errors) in the log file, but I'm pretty sure they're due to problems with my ProtocolHandler implementation and unrelated code issues. Still, I'm leaving status as NEW for now, since I'm not certain. The important thing is that SBS 7.6 with your patch *is* retaining my custom protocol URLs and the napster: URLs mentioned in bug 16141. Thanks, Adrian, for the commit, and Andy for blessing it.
Andy, this is fixed now, right?
Yep, thanks everyone.