Spotify won't work after they reset my password

[Trantion897]

I've been trying to get Spotify working on my Raspberry Pi for a while now. This morning I was able to compile the forked GStreamer plugin on the Pi (never managed to get it to cross-compile), and updated mopidy-spotify to the a3 version from a2, and at last it worked.

Couple of hours later, I get an email from Spotify saying they've reset my password due to suspicious activity, which also happened last time I was trying to get this working. I reset my password, and reissued API keys, but it won't work, and the GST debug logs have the Bad credentials error.

Any ideas? I'm stumped. As far as I can tell it still has the correct versions of mopidy-spotify and the GStreamer plugin, it can play local files, the access tokens are all there. And does the client authentication need to be done on the mopidy machine, or can I get a token on any computer and set it via SSH? This is one of the things I tried earlier when I had no idea why it wasn't working (before updating to the latest mopidy-spotify), but if I can do it over SSH then that's a little easier.

[kingosticks]

Can you provide mopidy deps and mopidy config? Can you remove any username and password config settings you've got?

[Trantion897]

Sure, here you go.

Mopidy deps 20241010.txt
Mopidy config 20241010.txt

I removed the username & password after updating to mopidy-spotify 5.0.0a3, where it stops requiring them on startup - IIRC I got it working with them commented out, but I only actually removed them after Spotify reset my password and it stopped working.

FWIW I'm using Iris and Mopidy-Mobile as frontends, both of them can see Spotify tracks but not play them.

[kingosticks]

And does the client authentication need to be done on the mopidy machine, or can I get a token on any computer and set it via SSH?

If you are referring to the authentication at https://mopidy.com/ext/spotify/, that can be done through your web browser on any machine.

Can you provide the GST_DEBUG logs?

[Trantion897]

Here's a log generated with $ sudo -u mopidy GST_DEBUG=3 mopidy --config /etc/mopidy/mopidy.conf -v >> mopidy.log 2>&1. The error starts at line 1528. I waited a minute or so for it to finish startup before playing, and closed it a few seconds after it started animating as though it was playing

mopidy.log

[kingosticks]

Did you build the fork at https://gitlab.freedesktop.org/kingosticks/gst-plugins-rs/-/tree/spotify-access-token-logging

? If so,.please use GST_DEBUG=*spot*:6.

[Trantion897]

Yes, I'm using that fork (and pretty sure it's still running based on the file modification data). Here's a log file
mopidy2.log
Error is at line 661 now (I missed that the last one was using >> and included some older data, sorry).

I noticed the line
DEBUG 2024-10-10 19:11:02,254 [2427:Audio-2 (_actor_loop)] mopidy.audio.gst Changing state to GST_STATE_PLAYING: result=GST_STATE_CHANGE_ASYNC0:01:06.377622436 �[34m 2427�[00m 0x7f68005d80 �[37mDEBUG �[00m �[00m spotifyaudiosrc audio/spotify/src/common.rs:131:gstspotify::common::Settings::connect_session::{{closure}}:<source>�[00m reuse cached credentials for user dphin1 before the error.

I found the file /var/lib/mopidy/spotify/credentials-cache/credentials.json and moved it to credentials.json~, but got the same result (including a reference to using cached credentials in the log). I don't know if there's another cached credentials file, but it's not in ~/.local/share/mopidy.

[kingosticks]

That exact branch from that fork? Your log is missing all the librespot debugging that should be shown with that GST_DEBUG command.

$ gst-inspect-1.0 spotifyaudiosrc | grep Version
  Version                  0.14.0-alpha.1-335dbdd

EDIT: also, don't bother with Mopidy's --verbose logging here, it's not useful.

[Trantion897]

Sorry, I misread the previous post - I had compiled the spotify-access-token branch. I've rebuilt work spotify-access-token-logging, command is $ sudo -u mopidy GST_DEBUG=*spot*:6 mopidy --config /etc/mopidy/mopidy.conf >> mopidy3.log 2>&1 :
mopidy3.log

It looks like there are two attempts to play: I'm using Iris for testing, the first is probably when I click the play button on the playlist, the second is clicking play at the bottom of the screen.

[Trantion897]

I've got spotify playback working again. Deleted everything I could find called credentials-cache, removed all app authorisations from Spotify, logged out Iris, then started everything up again.

/var/lib/mopidy/spotify/credentials-cache
/var/lib/mopidy/.local/share/mopidy/spotify/credentials-cache

I'm half-expecting Spotify to reset my account again this afternoon, but at least I'll know what to do :-)

[kingosticks]

Excellent, keep us posted. I'd like to better understand and resolve this. For what it's worth, the separate iris auth is entirely separate so you could leave that one.

[Trantion897]

I thought Iris was separate, but thought I'd check it just in case.

I haven't looked at the code or Spotify API to see if there's any reason it couldn't be done, and I'm very new to Rust, but could you have it clear cached credentials if authentication fails, and then fall back to mopidy.conf? Maybe some kind of check to see if credentials have changed from the cache in case Spotify sees the multiple login attempts as suspicious

[kingosticks]

I'm not sure I follow what you're suggesting but please feel free to experiment and improve things if you have an idea.

If you find they do reset your credentials again, after you restore things (again), it might be useful to always turn on the full GST_DEBUG logging afterwards and see if you can capture the run where they decide what we're doing is "suspicious". In case there's any clue there.