The issue seems solved now, I just had to restart a bunch of Mopidy instances that had dead Spotify sessions and everything worked again.
I’ve seen this problem in the past, it was usually related to short-lived Spotify outages. The things that spooked me this time have been both the duration (libspotify failed to connect for at least 6 hours) and the fact that in the previous occurrences the Spotify apps also had login/session issues, while this time everything worked fine on the app side.
The issue is back today, and according to my Mopidy logs it’s already been going on for almost 3 hours.
Is anybody else also experiencing these issues? These connection errors seem to be more common lately and they last for longer. I’m not sure if it’s due to some changes on the Spotify infra side. @kingosticks@jodal is there anything that can be done on the Mopidy side (e.g. have a way to manage fallback streaming servers) or everything that happens inside of libspotify is a black box?
I am encountering the same issue right now. It started about 4 weeks ago. Every now and then it’s not possible to stream from spotify while all native spotify players seem to work.
Things are working again now - the outage lasted approximately 6 hours according to my application logs.
I have also reached out to the Spotify support for explanations, and they again replied with “libspotify has been unsupported since 2012, we won’t investigate issues on that end”.
Do we have a way to control which servers are used for streaming, and in case configure a fallback? If not, may it be worth to investigate a possible migration from libspotify to LibreSpot? Every time I see one of these errors lasting more than a couple of hours I come to believe that it’s the ultimate nail in the coffin for libspotify…
I have been having the same issues since this morning. But strace seems to think that the plugin has been disabled due to missing keys in my mopidy.conf but this exact config worked yesterday.
Following the advice of Spotify’s support, I have opened an idea on their board to get an official alternative to libspotify (although today I have experimented for the first time with LibreSpot while mopidy-spotify was down and I’ve also found it a good alternative).
I have not been able to use spotify since yesterday (around the time of this post). https://ap.spotify.com is also unrecheable to me (from Switzerland).
Also reporting this issue - I’m getting the same error for almost 24 hours now, and still can’t connect. Is Spotify actually working for anyone? Just wondering if there is some variance, or if it’s now broken for everyone?
Broken for me too. Oddly enough, I’m no longer getting the login error (login seems successful), but Session must be logged in and online to load objects appears when trying to load a playlist.
EDIT: I’ve found a solution for now, albeit a hacky one. ap.spotify.com is where pyspotify tries to connect to the API. Often, this will return an IP address that can’t be reached. What I did was use dig ap.spotify.com to get various IP addresses for that A record and ping each one until I got packets back. Once I did that, I modified /etc/hosts and manually set ap.spotify.com to that working IP address. Example entry:
104.154.126.229 ap.spotify.com
This has resolved my problem for now until Spotify fixes this on their end.
Excellent work. It looks like Spotify don’t maintain ap.spotify.com reliably (deprecated? Incompetence?) and have moved to using apresolve.spotify.com but libspotify of course never got this update.
There might be a way we can patch libspotify or perhaps have it connect through a proxy that handles this.
My understanding is that libspotify is deprecated, and that is why it has not been updated. Spotify had promised to come out with a replacement for the library but never delivered on that promise.
It seems that ap.spotify.com is a hardcoded string in the library.
If apresolve.spotify.com provides the same interface then fixing the library should be as simple as patching the value of that string in the binary (and adjusting any ELF offsets that may change in the process).
However, if they have also changed the request/response format then that may be a bit too much for a weekend reversing task…