mopidy
Improve startup performance by deferring playlist loading
This change prevents loading of Spotify playlists from blocking other common Mopidy operations. These include startup and browsing, as well as refreshing of playlists in general. Loading Spotify playlists will always happen in a dedicated thread, and only one refresh thread will run at a time.
The playlists_loaded event is manually re-dispatched when Spotify is done loading playlists, as a signal that clients should refresh their list of playlists. This is necessary, as otherwise clients relying solely on websocket notifications may never discover the newly-loaded playlists.
Sorry, I seemed to have missed this. I went down this path myself and I scrapped it. I think my main issue was reasoning about how it fitted into the (long-overdue) playlist modification PR. And it appeared quite confusing for non-webclient clients (e.g. MPD) who would see zero playlists. I was leaning towards just keeping a peristent cache of the playlist data (like libspotify does/did) and make the refreshing really quick.
Isn't it reasonable to expect non-websocket clients to have some kind of refresh functionality? Otherwise, how are they ever notified of updates? Surely if you were expecting to see playlists and saw none, you'd just refresh.
Also I'd wager that most of the time Mopidy servers are running for days or weeks without being restarted. This just impacts startup performance, a one-time cost. This is actually mostly useful for Mopidy local development.
Thanks for the great original work on this. Sorry it took so long to get the improvement in. Closing in favour of https://github.com/mopidy/mopidy-spotify/pull/382 which is based, in part, on this.