Replace libspotify / Streaming does not work - "Spotify login error: <ErrorType.USER_NEEDS_PREMIUM: 15>"

[handle2001]

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?

[ZenithDK]

This is new to me (from https://developer.spotify.com/technologies/libspotify/#libspotify-and-cocoalibspotify-downloads):

Please note that we have removed the LibSpotify binaries from our website in an effort to phase out the usage of this deprecated library. LibSpotify has been considered deprecated since 2015 and will be shut down in 2017, so we want to ensure that all developers’ efforts and attention are focused on newer and better APIs that we actively support and maintain. These APIs include the Web API, iOS and Android SDKs, and upcoming embedded libraries for Windows, Mac OS X and Linux. More information regarding upcoming libraries will be provided in the coming months.

That sort of necessitates that we either distribute libspotify or rework mopidy to use the Web API's.

[kingosticks]

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.

[allquixotic]

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...

[yannik-b]

"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.

[kingosticks]

@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.

[yannik-b]

@kingosticks Oh okay, I never looked for it.

Actually mopidy-spotify is working.

[handle2001]

Is it possible to distribute libspotify in tar.gz format alongside mopidy without violating any licenses?

[chises]

i think the problem is that the library will not work anymore if spotify stops the development. are there any alternatives announces by spotify? i am really interested in this Extension and Keeping it up.

[forslund]

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?

[axelsimon]

I imagine you are already aware of the it, but just in case, librespot is an effort to fix the libspotify deprecation issue, from what I understand: https://github.com/plietar/librespot

[adamcik]

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.

[sashahilton00]

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.

[kingosticks]

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.

[sashahilton00]

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.

[kingosticks]

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?

[sashahilton00]

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.

[dbischof90]

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. :(

[sashahilton00]

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...

[sashahilton00]

Also @kingosticks this is what I was talking about in February :/

[kingosticks]

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.

[allquixotic]

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 :/

[kingosticks]

I think @sashahilton00 already covered that in https://github.com/mopidy/mopidy-spotify/issues/110#issuecomment-278661295

[sashahilton00]

@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...

[dbischof90]

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. How did they find this? Librespot doesn't seem to be the most stable solution either - but a great start...!

[sashahilton00]

@dbischof90 librespot is pretty stable, and has been around for a couple of years now. I suspect the unstable impression is mainly because the Gitter chat room is used as a means for reporting exceptions. Occasionally there will be a song that won't load, in which case it will be skipped (this is rare) or librespot may crash if one is using some of the experimental features such as multi-account streaming. For the most part, it should be stable enough, and is probably the long term solution for Spotify streaming functionality as it stands.

The biggest barrier to adoption in my view is that it is written in rust. Whilst rust is a pretty good language, there are very few (relatively speaking) who are proficient in it. What we really need is for the protocol to be documented so that more accessible implementations can be developed. Paul is busy until July, hence the slow pace at the moment, though development should pick up pace again over summer.

Writing a wrapper for librespot that exposes audio and metadata through an HTTP API or similar is on my to-do list, it's just not very high on it right now.

[allquixotic]

Depending on the complexity of librespot, might it also be possible to maintain ports in other languages, such as Python (:)) or C++ or Java? One benefit of going C++ is that it's literally portable everywhere - there are precious few programming languages that can't invoke a native library, and we can also write the public interface in a "pure C" dialect so it can be called from C, JNA, etc. without using C++ mangling semantics.

We could use upstream librespot as our authoritative source of the specifications of the wire protocol that we need to support, and backport fixes there to other language ports, unless/until a port of librespot to another language has a more active maintainer or manages to write a library with substantially fewer bugs/limitations.

If that sounds awfully complex, well, it wouldn't be the first time. Look at all the bindings the Selenium project has. And all the ones listed on that page have extremely close feature parity with the "main" implementation of Selenium written in Java.

... I'm also equally interested in a REST or SOAP based API for librespot, but that basically means dragging along the Rust runtime to the system where this needs to live, and spawning a separate process for librespot, then doing cross-process IPC. While this may not seem like a big deal, managing an external process makes it harder to do logging and debugging, state management, and creates bloat that can be an issue if you're on an embedded system with limited persistent storage and RAM.

Since people are using mopidy on Raspberry Pis and stuff, I'm not sure if all that extra overhead would make a difference. Probably not on the storage side, since MicroSD cards can have many gigs of storage, but on the RAM/CPU side, ... maybe.

[adamcik]

From my point of view having just a bare bones library for streaming would be enough. The metadata should be doable via the web APIs.

[trygveaa]

Does librespot support the same authentication method as the web API? Or would these be just as inconvenient to use together as libspotify and the web API is?

If we can use the same authentication method, I agree with @adamcik.

[sashahilton00]

@adamcik soon Spotify is going to require all calls to the web API's to be authenticated. If one pulls the metadata from the Spotify API, authentication is not required.

@trygveaa no, it doesn't. I don't know the specifics, but it uses a different auth method to the web APIS.

I'm also equally interested in a REST or SOAP based API for librespot, but that basically means dragging along the Rust runtime to the system where this needs to live, and spawning a separate process for librespot, then doing cross-process IPC. While this may not seem like a big deal, managing an external process makes it harder to do logging and debugging, state management, and creates bloat that can be an issue if you're on an embedded system with limited persistent storage and RAM.

@allquixotic You're preaching to the choir here. Whilst I think rust is the theoretical language of choice for librespot, the entry level to getting involved is pretty high. Librespot will always need a separate process as Spotify connect is something that is initiated by Spotify servers so to speak, hence librespot is always listening for events. The memory usage of librespot is pretty damn efficient as well; writing it in another language will almost certainly use more memory. Though as stated before, I think it's a worthwhile tradeoff in exchange for being a more accessible FOSS project. Still, at this point in time, beggars can't be choosers...

[dbischof90]

So for example for a Python library it would be the sanest thing for now to "simply write a wrapper"?

[brianclinkenbeard]

https://github.com/plietar/python-librespot/

[languitar]

This one seems to be maintained: https://github.com/plamere/spotipy

[kingosticks]

No, there is no streaming music support through the Web API.

[Michcioperz]

It looks like there's now some web streaming API, but it requires EME https://beta.developer.spotify.com/documentation/web-playback-sdk/

[adamcik]

Sadly it also seems to be in browser only, so not exactly something you could embed in mopidy and combine with GStreamer :(

[Michcioperz]

Yeah, I suppose you can't touch the audio packets, they go straight through EME to browser audio output

[kingosticks]

I've tried twice to ask if this is supposed to the libspotify replacement but so far no response. In sort of related news, they broke libspotify search again.

[Michcioperz]

They say this is not libspotify replacement, sorry for drama https://twitter.com/SpotifyPlatform/status/949225448336248832

[kingosticks]

I got a response:

We still know there's demand for playback in other situations including native/embedded devices, we promise we haven't forgotten! No announcements to make right now though.

EDIT: I see you got the same response. I can't see them doing it personally.

[tnymlr]

Well, at least you can download it it yet http://developer.spotify.com/download/libspotify/libspotify-12.1.51-Linux-x86_64-release.tar.gz

[craigbrett17]

Holy crap, this will teach me for not using mailing lists and all that, I've only just seen this. I guess my latest batch of work on Blindspot will be put on indefinite hold.

This has literally just ruined my day

[sashahilton00]

@craigbrett17 you may be able to use https://github.com/librespot-org/librespot in it's place. It's not perfect, but it's fairly stable.

[craigbrett17]

@sashahilton00: Thanks for the suggestion. Rust interop with C# doesn't sound like anything too promising. It MAY work, I don't know. That and building Rust through Windows isn't even a scenario they cover. I could use a Unix subsystem to do it but then using that built DLL on windows... I'm just not confident it will work here. I'll try that before properly giving up. That being said, their disclaimer also puts me off. I'm not trying to do anything inflamatory, not now at least, I'm just trying to get access to the content I've paid for in a way that's accessible. I'd rather not get sued for quadrillions of dollars in some shadey court in California if I can help it :(

[sashahilton00]

@craigbrett17 rust on windows isn't a problem, the project can be compiled on windows. With regards to the disclaimer, it's more there as a 'don't be stupid' policy; we've been in contact with Spotify about it before, and whilst they aren't endorsing it, they've let it exist as an OSS solution for a few years now.

[richwoon]

Hi y'all, Sorry if I am off topic... was testing out Tizonia that uses libspotify and just found out it doesn't work anymore. I am building a new wearable music gadget and we're in the midst of deciding on the operating system. The gadget is supposed to play Spotify Premium offline... I am under the impression that I must run Android (or perhaps Linux) to get it working vis the current SDKs. Am I right here? Thanks

[kingosticks]

Android is your only option and there's plenty of info on the Spotify developer website. If you have further questions please ask Spotify, not here. Good luck.

[insipx]

So i'm guessing mopidy-spotify no longer works because of libspotify deprecation.

Sucks, guess we just wait to see and hope that spotify will release something in the future which will let it work as it once did?

[allquixotic]

Mopidy-spotify should work still if you have a copy of the library for your platform, unless something has very recently changed.

If they killed it from the server side, you might want to check out my project “tribblify” and use a “real” Spotify client. Unfortunately this requires an x86 processor to work and won’t work with ARM because I don’t think they have a full Spotify client that works on ARM.

I still need to document/fix Tribblify a bit but it should basically work. Let me know if you have problems.

[PabloReszczynski]

Is there some fast way to use librespot instead of libspotify when building this lib?

[kingosticks]

No. There is not.