For quite some time I have felt the urge to do something with libspotify. In my living room I am using the kodi plugin Spotlight to play Spotify music on my stereo from my Raspberry Pi. I wrote a small patch to enable the last.fm scrobbling functionality that libspotify has integrated since I, for some unknown reason, really like to scrobble everything I listen to on last.fm.
Spotlight is really light-weight and one thing I really missed was the “Your Music” feature from the official Spotify clients. After a little research I found that libspotify did not support that feature at all and when looking further I found quite a few features missing. On the official libspotify page there is a comment section in the bottom and of course people had started to request various features and builds for new architectures. All of these are met with responses like “No current plans, I’m afraid.”, “It’s not something that we’re planning on.” and variants of those sentences. Basically the project seems dead. This prompted me to ask the following question
Is there any active development of libspotify at all?
There seems to be some missing features compared to the official client(s), for example Your Music and Spotify Connect. Is there any hope of those being added sometime?
The reply I got from Spotify staff was this:
Not currently – we are concentrating our resources on the iOS SDK, Android SDK and bringing more functionality to the Web APIs.
Andy Smith, 2015-02-11
Well then. I interpret this as the feature development has completely halted for this library. Too bad. Please note the “Not currently” in Andys responses. There might be a slim chance that some day the focus at Spotify will shift and they decide to implement these and other features into the library.
Neverminding the missing features I decided to play around with the media player VLC and experimented with plugins and one day I started to implement a Spotify plugin for said media player with the very “exotic” project name vlc-spotify. The idea was to simply start VLC and be able to play or enqueue tracks represented by the unique Spotify URI or the open.spotify.com URL. Either via clicking Media -> Open Network Stream -> https://open.spotify.com/track/6WoNBlwgSRD3CEeOlrQSXq or via command line $ vlc https://open.spotify.com/track/6WoNBlwgSRD3CEeOlrQSXq .
After some happy hacking I managed to fetch the track meta data and play the track. The support for pausing, seeking and getting the track duration and current time position was quite easy to implement. But I ran into an issue that was really annoying… When calling the library function sp_session_logout() I would get a segmentation fault ~33% of the time resulting in VLC crashing down. How often do the plugin logout the Spotify session? Answer: after each track.
The reason for logging in and out for each track lies in the structure of VLC. Each track is a separate input item, be it a mp4 file, a FLAC audio file or a mms stream and when a new input item is opened (that is, you double click on a playlist item or such) VLC will inspect the file/stream/whatever and open the appropriate chain of modules for access/demux/decoder/audio_output/video_output and so on. The key is that each input item is associated with new instances of each of the modules that will be used to succesfully play the item. When the VLC core would like to use a module the Open() callback defined by the module is called and when the use of it is done (ie. the track has ended or the user has pressed the Stop button) the Close() callback is called. Open shall allocate all resources needed and Close shall release all resources. Simple.
Therefore it is quite natural that when VLC has a Spotify URI as an input and calls the Spotify module (the type of it is access_demux by the way) the module will then create a sp_session object and login the user. When closing the input item the module will logout and destroy the release the sp_session object.
As you might understand the 33% crash rate (which is an approximation and has a wide variation; sometimes it crashes after the first logout, sometimes after the tenth) will cause alot of problems and render the plugin useless due to poor stability. I thought to myself that this issue really needs the attention of Spotify staff due to the severity and obviousness of the bug.
On the Spotify Developer pages there is a support page where they basically refer technical questions to Stack Overflow and adding the “Spotify” tag. The Web API, Android SDK and iOS SDK have their own pages on github where independent developers can add bug reports and feature requests. One user asked a question regarding libspotify that I found really interesting:
how to add feature requests or bug reports for libSpotify?
The answer he got is the core of this blog post:
We don’t accept either bug reports or feature requests for libspotify.
Michael Thelin, 2015-03-23
Wait… What? Just… What? My response:
How can you *not* accept bug reports? I understand that there might be
reasons to stop feature development of a certain product, but to stop
the maintenance seems a little irresponsible.
This comment was deleted by Michael Thelin and was never published on the support page. I guess Spotify doesn’t respond well to criticism. However, Daniel had posted a reply to Michaels comment:
does that mean libSpotify is discontinued? Will there be another way to play Spotify music on Windows and OSX machines? Maybe simply by adding a download / stream URL to the web API (like competitors do it)?
And the answer:
on our developer website, there are several resource pages for the iOS SDK, Android SDK and our Web API. These are the services we will be providing going forward.
I don’t see Rebeckas reply as an answer to Daniels question at all and this is one of the things that really bugs me. Alot. No one dares to say “libspotify is dead, don’t use it”. Spotify has an official developers page for libspotify, but they can’t clearly state that it is unmaintained and should not be used. Except for Android and iOS since they have new projects for those platforms, but claiming that a library that supports A, B and C but is deprecated for C gives the impression that everything is OK with A and B.
I wrote a question on the libspotify comment section in reply to Andy Smiths statement (quoted in the top of this post):
The warning on the top of this pages states: “[…] LibSpotify and CocoaLibSpotify is considered deprecated for [iOS and Android]”.
Isn’t LibSpotify considered deprecated for *all* platforms? Since there isn’t any development/maintenance of the library (not even bugfixes) I would recommend a warning to developers to not use it.
This comment is, as of this writing, pending moderation and has been so for 8 days.
What do I mean with unmaintained and why does it bother me so much? Basically I think that if a commercial company releases something they need to stick with it or officially close it down, and this is especially true for closed-source software since no-one can pick it up and create forks. I am fine with the fact that they will not implement new features or produce builds for new architectures but as a company it is vital to have some resources that can spend time on maintenance and fixing reported bugs. If no new features is implemented the resources needed will decline over time. In this case it seems (I am only guessing here) that Spotify has pulled all resources out of the project and just pretends like it is raining without telling anyone that the library might be ticking time bomb. What would happen if there was a security issue with the lib?
So what happened to my specific bug then? I posted a question on Stack Overflow which you can find here but no one from Spotify has responded. It is noteworthy that Spotify employees has responded to SO questions both before and after mine was posted. Upon further research I noted that I was not the only one that had encountered this bug. Here, here and here are other examples of similar or related bugs and the last one is the most interesting due to a Spotify employee actually responds:
At the moment (and it’s very bad form), libspotify only supports “one instance of sp_session per process”, and as you see it’s unreliable when releasing. In theory, releasing the session after logging out (and waiting for the logout callback) should be fine, but we’re seeing some reliability problems as you can see.
Our own internal libspotify unit tests create a process for each test to really make sure state is reset, which is why we missed this problem for libspotify 12.
CocoaLibSpotify’s unit tests run all the tests in one process, but don’t log out etc between them.
Note the date. 2013-01-16. That’s over two years ago where they acknowledge that the destruction procedure is unreliable in version 12, which is the latest version and hence the library hasn’t been updated for over two years with known bugs.
On a side-note. The documentation for sp_session_logout() states: “Always call this before terminating the application and libspotify is currently logged in. Otherwise, the settings and cache may be lost.” But this function is not used in the examples that is shipped along the library. Oh the irony.
Again, why does all this bother me so much? I think the purpose of the library fits the goals that the Spotify CEO Daniel Ek is talking about in media over and over again:
We believe that music should be like water. It should just exist everywhere so if you think about that for a moment. What we are really trying to do (is) making music more accessible.
We want music to be everywhere and in every device, in every place. It really doesn’t matter where in the world that is or on what device that is or what I’m doing. I should always have music accessible.
When I am (or rather: “when I was”. I kind of lost interest in it) developing the vlc-spotify plugin on my spare time I make the music (for the premium subscribes) more accessible and available on more platforms. In some sense I work for Spotify but without any kind of monetary gain. Since I need to be a premium subscriber to use the library (it costs me 99 SEK/month) one could argue that I am actually paying for doing the work. One thing I would really need is the decency of Spotify to outright say that I am wasting my time since there are know issue that will not be fixed. That could be accomplished by a big fat warning on the top of the libspotify page with the information that the library will not be receiving any more updates and has issues. I shouldn’t really have to find that out by interpreting comments on various locations. Or, the thing I would really need is for Spotify to make sure their own stuff works.
I would like to point out that I am not disappointed at individual engineers at the company. This smells more like a strategic decision where middle or top management just pulled the plug on the project and shifted the resources elsewhere without allocating anyone for sticking around and cleaning up. And then be very vague about it.
Woohaa. This was one big first blog post. I wonder if I will be able to keep it up :-)