Symptoms
Since the upgrade to libspotify 0.0.6, as required by Mopidy 0.3, Spotify playlists have not been available when connecting to a freshly started Mopidy instance.
Workaround
The current workaround is as follows:
- Execute a search for anything that yields some hits. "foo" will do. If you can choose search type, choose "any" or "query", not "filename".
- Disconnect your client from Mopidy, and then connect again.
- You should now see your Spotify playlists. If not, wait for say 10 seconds, and reconnect again.
If you use an MPD client with broken search capabilities, like Sonata or MPoD, use another client for executing the workaround, and then continue using your preferred client. You will not need to redo the workaround as long as Mopidy is not restarted.
Technical details
In libspotify 0.0.4, the metadata_updated callback was called for a bunch of events, including when the libspotify stored playlist container was done loading its contents. Mopidy reloads its internal copy of the stored playlists whenever the callback is called.
In libspotify 0.0.6, the metadata_updated callback is no longer called when the playlist container is done loading. Instead the playlist containers have gotten their own set of callbacks, including one named container_loaded. This is the callback we should now be listening for, and when called we should update our internal copy of the stored playlists. Currently, pyspotify, the Python bindings for libspotify, does not implement the new playlist container callbacks.
The workaround works because metadata_updated is called when search results are received, which will trigger the refreshing of Mopidy's internal copy of the Spotify playlists. If you are too quick executing the workaround, it may not work because the libspotify playlist container wasn't ready yet when your search hits returned.
Symptoms
Since the upgrade to libspotify 0.0.6, as required by Mopidy 0.3, Spotify playlists have not been available when connecting to a freshly started Mopidy instance.
Workaround
The current workaround is as follows:
If you use an MPD client with broken search capabilities, like Sonata or MPoD, use another client for executing the workaround, and then continue using your preferred client. You will not need to redo the workaround as long as Mopidy is not restarted.
Technical details
In libspotify 0.0.4, the
metadata_updatedcallback was called for a bunch of events, including when the libspotify stored playlist container was done loading its contents. Mopidy reloads its internal copy of the stored playlists whenever the callback is called.In libspotify 0.0.6, the
metadata_updatedcallback is no longer called when the playlist container is done loading. Instead the playlist containers have gotten their own set of callbacks, including one namedcontainer_loaded. This is the callback we should now be listening for, and when called we should update our internal copy of the stored playlists. Currently, pyspotify, the Python bindings for libspotify, does not implement the new playlist container callbacks.The workaround works because
metadata_updatedis called when search results are received, which will trigger the refreshing of Mopidy's internal copy of the Spotify playlists. If you are too quick executing the workaround, it may not work because the libspotify playlist container wasn't ready yet when your search hits returned.