You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I've just finished a rewriting of the playlist callbacks subsystem inside pyspotify ; I will use it as a basis to implement playlistcontainer callbacks. They should arrive soon!
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_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 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_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.The text was updated successfully, but these errors were encountered: