Replace libspotify / Streaming does not work - "Spotify login error: <ErrorType.USER_NEEDS_PREMIUM: 15>" #110
Comments
|
This is new to me (from https://developer.spotify.com/technologies/libspotify/#libspotify-and-cocoalibspotify-downloads):
That sort of necessitates that we either distribute libspotify or rework mopidy to use the Web API's. |
|
Oh dear. How did they forget to email us about this through their developer list AGAIN?! There is no way to play music with the Web APIs (unless this has also changed without announcement). So distributing libspotify is probably the only option. |
|
I think it will be necessary to rewrite mopidy-spotify using one of their new APIs or that "embedded" thing they mentioned. Libspotify will be forcibly prevented from accessing Spotify by some time in 2017, per Spotify themselves, so we can't count on its continued functioning (unless some enterprising hacker hacks the binaries somehow to trick Spotify's servers into letting us continue to use it, but don't count on it). I am hopeful that it doesn't require some kind of protected audio path. It can't really, if it's on Linux, right? So hopefully there will be a way to get at the PCM data from the tracks. That's all we really need to be able to move forward. ... If the web API doesn't work and the embedded clients aren't accessible to us, can we run an Android emulator on the user's system and run the Android Spotify API through that? :P just a thought... |
|
"LibSpotify and CocoaLibSpotify are no longer under active development on any platform and are considered deprecated. If you are building applications for iOS or Android, please use the iOS SDK or Android SDK, and we will be providing a new library for other platforms later this year" from the original spotify developer Website. So I think we have to wait now. But its clear that mopidy-spotify has to be overwritten. |
|
@yannik-b, that particular note has been on their website for literally years, including the promise of a new library. mopidy-spotify uses libspotify through pyspotify which might protect us from some of the changes. Lord knows what Spotify will actually end up doing and when they will actually do it. They have a history of this and unfortunately it's as unclear as it's always been. |
|
@kingosticks Oh okay, I never looked for it. Actually mopidy-spotify is working. |
|
Is it possible to distribute libspotify in tar.gz format alongside mopidy without violating any licenses? |
|
i think the problem is that the library will not work anymore if spotify stops the development. |
|
I'm also keeping this alive. I guess we're in the hands of spotify at the moment, waiting for them to release a replacement library? Or is there work on the "embedded" track going on? |
|
I imagine you are already aware of the it, but just in case, |
|
Yes we know about it, but it won't help much if Spotify decides to turn down those endpoints. I looked at it bit when they started out trying to get Spotify Connect working, but I've not payed much attention since it didn't look like we could easily integrate it at the time. |
|
Hi, just a quick update from the librespot repo, I've had a look at libspotify in a disassembler, and there are a couple of flags in there such as is_depreciated that are set to false. My guess is that Spotify will at some point set these to true and libspotify will die. Librespot is written in rust, and hence isn't the easiest to integrate with mopidy. To this end, spotifyd has been rewritten to use librespot, and spotify-http is a WIP looking to provide a web server to interact with librespot. Librespot has also had alsa, portaudio and stdout audio backends added. Thus it should be viable in the near future to use it with mopidy without too much effort. Alternatively, spotify-connect-web uses the embedded library that spotify references, which includes connect functionality, though there is no documentation for it, hence you are on your own with that. |
|
Are you saying that librespot supports playback through an endpoint other than the one libspotify uses? i.e similar to however the Android/iOS SDKs work? Playback is the only part of the API that is not available through Spotify's Web API and the only thing we actually need going forward. |
|
librespot simply connects to one of the spotify endpoints from https://apresolve.spotify.com/ and interacts with spotify using the Spotify protocol, the same way libspotify does. And they are not going to kill the endpoints that libspotify uses, I can almost guarantee it, as all of the OEM Spotify Connect speakers use a variant of libspotify called libspotify_embedded that contains the connect functionality. The amount of work they have put into the Spotify Protocol in terms of design/implementation means they are not going to scrap it, especially given this is how the Desktop clients interact with Spotify servers. I can almost guarantee that the shiny new embedded library that Spotify is talking about will be a repackage of the library that they have shipped to speaker manufacturers for the past few years. |
|
If we assume they do not turn off the endpoints, then what advantage does something based on librespot have over just using the current version of libspotify that we already have? Considering Spotify's complete failure to deliver a new SDK I don't think we can assume anything about what it will be (or if it will ever turn up). Do you know if the Android/iOS SDKs use the same endpoints as libspotify? |
|
At the moment there is no advantage, though as I mentioned previously, libspotify has an is_depreciated flag which could be flipped by spotify whenever. Also, librespot doesn't require an appkey. Though I am doubtful as to whether Spotify will kill libspotify this year, their devs seem to be the laziest bunch I've ever come across. |
|
I get it Spotify, you don't want pirating being made too easy. But come on... There's so much potential for this. You doomed/broke hundreds of apps at the same time. :( |
|
I suspect it is actually more of a licensing issue. libspotify was a free library that didn't require any contract with Spotify, whilst libspotify_embedded (with the Connect functionality) requires you to become a Spotify Partner and sign a contract/NDA before use. I would imagine there are licensing fees involved as well... |
|
Also @kingosticks this is what I was talking about in February :/ |
|
There's a short discussion and nice example of how librespot can be used as a library here. Something like that would allow us to also drop the playback side of libspotify but keep our existing architecture. But for the time being, libspotify should still be available through Mopidy's APT archive. |
|
Does librespot access Spotify using a mechanism that won't break when they turn off libspotify? What mechanism is it exactly? That could be the savior of all FOSS Spotify clients needing direct audio access, if it works... and provided Spotify doesn't start suing people for using it :/ |
|
I think @sashahilton00 already covered that in #110 (comment) |
|
@allquixotic librespot accesses Spotify using the same method that their desktop/mobile clients do. There is little/no risk that librespot will fail due to endpoints being closed. Occasionally librespot breaks when Spotify introduce new protobuf specifications that break previous implementations, but these updates are few and far between, and are both easy and quick to fix. librespot is pretty stable at the moment, though I'd suggest testing before using it in production obviously... With regards to suing, pretty sure what librespot is doing falls within the DMCA Exceptions. We're pretty explicit on our policy of not supporting circumvention of Spotify's various protections, we're only after interoperability... |
|
That would be more than great. I simply don't want to use libspotify because if it takes three months to develop something which will be scrapped this year it's simply not worth the effort. |
Still works fine for me (on Debian 11). Problems with the installation are probably better to take to the forums. |
|
First of all thanks for fixing mopidy-spotify. It's working great for me on a Raspberry Pi Zero W. I managed to install it following the README instructions and a little trick: The compilation (rustc) got stuck on the Pi Zero running Raspberry OS legacy, so I put the SD card in a Pi 3 for compilation and back in the zero afterwards which works great. Maybe this is helpful to someone :) |
|
Tried to go through the manual. |
|
Hello dears, Here is the output that i have Gstreamer spotify plugin: spotifyaudiosrc: Spotify source 1 features: And here is the ouput of mopidy: I don't really get what's going wrong. Could you point me at what i should look to troubleshoot it ? Thanks |
...
Just to be sure: do you actually have Spotify Premium, and have you added the API key and password to your config? It won't work with a free account. |
|
|
Hello my bad i haven't given all detailed, i have a premium account and not a FB one. [spotify] |
Hi, i have installed mopidy yesterday and mopidy-spotify this morning on a fresh ubuntu install. The only different thing is that i've installed mopidy-spotify from apt and not from the python command. I've just tried your command, but it complains for the --break-system-packages parameter which is unknown. !!!UPDATE!!! Thanks for the help !! |
And that was the problem. If |
|
I've added pre-built Debian packages for a few platforms at https://github.com/kingosticks/gst-plugins-rs-build/releases/latest Open an issue at https://github.com/kingosticks/gst-plugins-rs-build if anyone also wants the .so files added. |
|
Installing this .deb package (this = amd64) over the previously built installation, which might be the wrong thing to do, produces the following errors: Playlists load, but won't play. |
|
That's an error in Mopidy-spotify, rather than gstspotifysrc (Spotify silently changed their API). Fixes (#375) went in last couple of days, upgrade your Mopidy-spotify with latest from this repo. |
|
Ah, OK , that fixed the problem. Thanks. Interesting though that it also worked with older verisons, namely Mopidy 3.4.2 and gspotify 0.11.0-alpha.1-3661b4f from 2023-07-18... clearly, some black magic is involved here! :-D Sorry for bothering... |
|
They've rolled their bug out to users gradually. Pointless when they don't listen to bug reports. I think all older versions of Mopidy-spotify will suffer from this bug in their API, it's unavoidable. Glad working for you know. |
|
I've updated to the newest version, but i get following error when selecting a playlist for playback: |
|
And what version is that? The latest development version or the latest (pre-)release? Unless you're also using very latest Mopidy from git then you should be using https://github.com/mopidy/mopidy-spotify/releases/tag/v5.0.0a2 |
|
@kingosticks thanks for the super fast response, installing that specific tag indeed fixed the issue. |
|
@TCke83 out of interest, did you have to force/hack the installation in some way to get your original issue? If you are using the latest Mopidy-Spotify from git it should be automatically also pulling in the latest Mopidy from git, and these two versions are compatible together. |
|
I always use following command to update: Until now without the specific tag version. But it could be mopidy was previously installed using apt-get, that might prevent the update of mopidy using the above command? |
Yes, that's probably it. Thanks |
|
noting that Spotify disabled username/password authentication, which affects playback in 2024 on the https://github.com/mopidy/mopidy-spotify/tree/v5.0.0alpha branch, users will see errors similiar to mopidy-1 | 0:00:07.438849644 12 0x7fd8fe9c75e0 ERROR spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:328:gstspotify::spotifyaudiosrc::imp:<source> failed to start: Login failed with reason: Bad credentials
mopidy-1 | 0:00:07.439024172 12 0x7fd8fe9c75e0 WARN basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: Internal data stream error.
mopidy-1 | 0:00:07.439057619 12 0x7fd8fe9c75e0 WARN basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: streaming stopped, reason error (-5)
mopidy-1 | 0:00:07.439107908 12 0x7fd8fe9c75e0 WARN oggdemux gstoggdemux.c:4775:gst_ogg_demux_send_event:<oggdemux0> error: EOS before finding a chain
mopidy-1 | 0:00:07.439157027 12 0x7fd8fe9c75e0 WARN oggdemux gstoggdemux.c:2550:gst_ogg_demux_sink_event:<oggdemux0> EOS while trying to retrieve chain, seeking disabledsince this is an upstream issue with librespot-org/librespot#1308 a solution will be multi-tiered, as always, ty @kingosticks, for your work on this |
|
Thanks for adding this here also. I would have thought things will continue to work for existing users because we support "cached credentials". Only the very first login actually uses your user and password. This does assume you are persisting the contents of Mopidy's Obtaining cached credentials (via a custom build of librespot, or similar) and moving them into this directory is a work-around. |
|
@kingosticks ah, I see, ty for that callout I was only persisting the mopidy cache dir in my alpine docker image ie: looks like i should have also persisted |
Nope, Spotify forces users to reset their passwords |
|
My cached credentials was still working as of yesterday evening. I'm going to move this new problem into its own issue to make it clearer that it's new and what the options are. I had only intended to keep this old issue open until we had a proper new (non-beta) release. Maybe that is just confusing. |
|
Fixed in Mopidy-Spotify v5.0.0a3 and gst-plugin-spotify_0.14.0~alpha.1-1. You should still properly configure your cache directory but things should still work now regardless. |
and others
According to the Spotify Developer website, libspotify is no longer available for download, so the mopidy-spotify plugin cannot be installed anymore. Is there an alternate source for this library?
The text was updated successfully, but these errors were encountered: