mopidy-spotify: Playlists stopped working

@kamek-pf the spotify-deezer repo has been shut down after a DMCA complaint started by Deezer itself. I have the repo still cloned locally but many API requests to Deezer are no longer working (and I don’t feel like investigating or fixing it until Deezer changes its approach towards developers building stuff on top of their services).

mopidy-gmusic has issues as well as of today since the self-generated device_id is no longer working https://github.com/mopidy/mopidy-gmusic/pull/195 - and it will probably break more in the next days/weeks as Google will move most of the GMusic services to the new YouTube Music service or however they want to call it.

Anyway, I have prepared a fix for the Spotify playlists issue on top of @kingosticks old fix/incompatible_playlists branch https://github.com/BlackLight/mopidy-spotify/commit/e245c2d37cb013645fa8ba1a2b59bfb4e16df919. It’s probably not the ideal fix and it will slow down Mopidy startup a bit, especially on Raspberry (I’m sure that more caching can be done on the tracks retrieval through the web API), but at least it should make things work again:

git clone git@github.com:BlackLight/mopidy-spotify.git
cd mopidy-spotify
git checkout fix/incompatible_playlists
[sudo] python2 setup.py build install

I picked it up again last night, as it happens. Then got sidetracked as pytest had gone rusty. I’m going to focus on finally getting the fix into a state it can be merged.

Any progress with merging this into master? It’s been on hold for more than a year.

Should we wait until mopidy 3 and Python 3 integration before seeing this merged, or is it possible to provide a timeline for the merge? The situation with the forks is becoming quite chaotic, maybe the time to merge has come?

Fixed by the merge of PR #235.

@kingosticks what’s the status with the new branch? The last commit was almost 2 months ago.

i have excatly the same issue. i did not change anything.

client_id & client_secret are set in mopidy config. But no playlist are available.

mopidy log:

May 24 17:48:59 Ipse mopidy[24797]: INFO Logged in to Spotify in online mode …

DEBUG 2018-05-24 17:44:25,959 [22798:MpdSession-17] mopidy.mpd.session Request from [::ffff:127.0.0.1]:34480: command_list_begin DEBUG 2018-05-24 17:44:25,960 [22798:MpdSession-17] mopidy.mpd.session Request from [::ffff:127.0.0.1]:34480: load “spotify:<USER>:playlist:6x5yNjb1UlnsNgPgLQJzFA” DEBUG 2018-05-24 17:44:25,961 [22798:MpdSession-17] mopidy.mpd.session Request from [::ffff:127.0.0.1]:34480: command_list_end DEBUG 2018-05-24 17:44:25,968 [22798:MpdSession-17] mopidy.mpd.session Response to [::ffff:127.0.0.1]:34480: ACK [50@0] {load} No such playlist

Hi @BlackLight yours, following this steps:

sudo apt-get remove mopidy-spotify git clone https://github.com/BlackLight/mopidy-spotify.git cd mopidy-spotify [sudo] git checkout fix/incompatible_playlists [sudo] python2 setup.py build install

Thanks so much.

So Spotify migrated few months ago from the spotify:playlist:playlist_id to the spotify:user:user_id:playlist:playlist_id format (a change that broke a lot of clients already), and they’ve just decided to migrate back with nearly no earlier notice to the former format. And they expect all the clients to migrate back accordingly within the blink of an eye without even thinking of holding back-compatibility with the previous format. Wonderful, the hysterical madness of the corporate world will never cease to surprise me.

@stekern I have imported your fix into my fork and also into the feature/playlist_modify branch. I’d leave it like this for now (without removing the logic on line 352) just in case a new project manager should step in the next couple of months and change Spotify’s mind about the URI format again.

p.s. @kingosticks btw how’s the progress with the refactored fix? I’ve noticed that you’ve recently committed some new WIP, do you need any support for coding/tests/testing to get it through?

Ok, I have updated the pull request https://github.com/kingosticks/mopidy-spotify/pull/1/commits with a new commit that fixes the playlists lookup error by properly passing the web_client object to the lookup logic. Now adding a playlist through add(spotify_uri) should work as well. Please let me know if I can provide any support with pushing these fixes upstream.

@BlackLight @fooness I don’t spend much time in front of a computer at home during the Summer but it’s about blooming time to write some tests and get this merged I very much agree. I wish these things could confine themselves to the boring Winter months.

It’s been almost 3 weeks since the issue was reported and the plugin is broken.

Can you guys please let us know at least what’s the plan? My fix is ready and according to many users it’s working. Is there anything preventing the merge? Is it lack of time? Is it because you guys are still reviewing and testing the changes? Is it because the plan is to drop libspotify altogether and therefore changes on the current codebase don’t have any priority? Many users would like to get a response from the maintainers.

I’m also working on new features (like playlist modifications) that are blocked as they require this fix to be merged first. If I don’t get any news from the developers I’ll just proceed with working on my own fork with no further intention to merge the changes back to mopidy-spotify.

I currently see the same. The question is, is it a temporary issue or the next step in libspotify’s slow and painful death? I have asked but I’m not hopeful they’ll bother answering.

On Thu, 24 May 2018, 20:26 AidanOD, notifications@github.com wrote:

Same issue. I can playback songs/artist/album from the uri but not playlists.

Was working nothing change on my end.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mopidy/mopidy-spotify/issues/182#issuecomment-391831095, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5DqDlIiZLn3mokQMNZHgW4L4w_fZyKks5t1wl9gaJpZM4UMgcP .

@julverr the 100 tracks limit for the playlists is now fixed in https://github.com/BlackLight/mopidy-spotify/commit/748c019ae3b88d7e821ec471c8bf770de7d31cdb, I hadn’t noticed that load and add actually go through two different flows and pagination wasn’t implemented properly in _lookup_playlist. There’s quite some code duplication between lookup.py and playlists.py that I hope will be refactored before merging, but at least things should work now, let me know if they do for you as well.

@tatoosh can you define “large” playlist? My biggest Spotify playlist is around 1000 items and I can load it on a RPi3 within ~5 seconds. When it comes to the merge, I hope to hear something from @kingosticks, but in the meantime anyone who can help with writing/fixing the tests for the playlists is welcome. The feature/playlist_modify branch that supports adding/deleting items to playlists is also awaiting merge but that can’t happen before this fix is properly merged.

Can confirm that BlackLight fork fixes this! Can help if there’s anything to do before merging it, maybe I can write some tests…

@Maskmagog no worries, there’s no such thing as silly questions, only silly answers ^^

git and shell basics troubleshooting is a bit OT here though, but feel free to drop by the #mopidy freenode channel for more support.

It’s definitely the plan and it’s very usable, just nobody has done it yet. I don’t expect Spotify to provide any other option so I wouldn’t think of it as temporary workaround either.

I implemented a proof of concept some time ago but I didn’t get around to implementing it properly. Things do slow down a little when loading large playlists but once cached it’s fine (their API support etags too). There’s no reason we can’t store the cache and re-use it between runs too, just like libspotify does.

I’ve created a small commandline tool that just synchronizes your spotify playlists with MPD once. https://github.com/weskerfoot/Spotify-MPD-Sync

Can’t promise that it is a perfect solution but I’ve been using it without trouble for a while. It clears your spotify playlists on the MPD side every time it syncs up if it finds that there are any differences (spotify is the source of truth).

I’m not sure if this could be integrated into mopidy-spotify because it is fairly slow if you have a lot of playlists/tracks, and it doesn’t make sense to run it every time you start up mopidy (more like once a day or when you know you’ve changed things).

using web-api-playlistv2 branch works

It’s getting tricky to understand which fork, and which branch we should pull the project from 🤣

Currently, @Blacklight’s fix/incompatible_playlists branch does not work for me to load playlists. Even with @TCke83’s changes.

The repo I’m currently using that is working to pull playlists is @kingosticks’s fix/web-api-playlists-v2 branch.

@girst Spotify server sent a HTTP 503 and not a 4xx. It shouldn’t be converted to 4xx by the Mopidy server, it should be kept 503 as it is still a server side error no matter if it happens on the Spotify or Mopidy side. @adamcik

Checked logs and grafana, and looks like Spotify was giving use 503s for a bit over an hour. Nothing we can do about that, other than maybe change the error message to Upstream provider unavailable. to make it clearer?