Figure out what to do with mopidy-spotify "vs" mopidy-spotify-web recent given Spotify changes?
adamcik opened this issue · 19 comments
Given #110 we will probably end up having to move in a direction where we do one of the following:
- mopidy-spotify does just streaming
- mopidy-spotify steps on the toes of mopidy-spotify-web
- they just merge.
I've not put much thought into any of this yet, but we should probably start doing just that and also loop @lfcabend in. Perhaps this is an opportunity to bring someone onboard to do the conversion and ensure we have more people giving this plugin love?
This site https://developer.spotify.com/technologies/libspotify/
mentions a possible new library in 2016, don't know if u guys were aware of this statement:
"Important! 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. We hope to be able to provide you with a new library for other platforms during 2016.
Until then, you can still provision new keys for your project. However, please be aware that we cannot offer active support or guarantee future functionality on LibSpotify or CocoaLibSpotify."
Don't know if you want to wait to see this API, to decide on any of the three points mentioned above.
We are aware of that, which is why I thought it was time to start this conversation.
The final option that I didn't mention would be to turn to keep the pyspotify API, but internally use the web API instead of libspotify everywhere we can. But that would end up with a lot of extra effort in maintaining the translation layer :(
If we want to merge, we need to consider that mopidy-spotify and mopidy-spotify-web uses two different login methods. Hopefully this new library will use the same login method as mopidy-spotify-web.
When (if?) this new library arrives, I think it would be preferable to have only one mopidy plugin that both uses the web API for querying and this library for playback. One option would be to add support for this library in mopidy-spotify-web and deprecating mopidy-spotify (though I have no idea of the state of mopidy-spotify-web, and it's a bit worrisome that it doesn't have any tests, and that spotipy which it uses seems a bit short on tests as well).
Another option would be to rewrite mopidy-spotify to use a new backend, or somehow merge them. We should probably compare the two code bases to figure out which option to go for.
The Spotify web API only allows for 30 second previews of songs, right? So if we migrated away from libspotify, we would have no solution (as of this writing, that is; until Spotify comes out with the vaunted replacement) for full-song Spotify playback in Mopidy.
For the immediate future we are stuck with libspotify for streaming, there is no good way around that. But we can still start looking at what to do with the rest of the APIs we use.
Is there work already started on merging these two modules?
No, I guess we are waiting for this new library to replace libspotify.
Is that library a real thing? I have some contacts at Spotify, I'll ask to see if they know anything about it.
If you go to https://developer.spotify.com/technologies/libspotify/ they are promising this.
Is that library a real thing?
Hard to say. They have had a notice saying it will come on the page @lfcabend linked to for about two years I think. If I recall correctly, it previously said it would come during 2016, but now it is more vague saying "We hope to be able to provide you with a new library for other platforms.".
We need to work on merging the modules, I don't personally have any time to do this right now. We'll be waiting until the end of time for that new library, it's vapour-ware.
I spent a little time tonight wrapping my head around how libspotify, mopidy-spotify and mobity-spotify-web work. It's unfortunate, I feel like the new library is vaporware as well
We hope to be able to provide you with a new library for other platforms.
Doesn't give me any warm fuzzies.
So if we use mopidy-spotify-web to handle all requests except actually loading / playing the tracks, I feel like we would still be in a position where we would require both authentication methods in order to handle searching / loading playlists / etc.
Part of me wants to try and start monkey patching this together with sp_session_player_load & sp_session_player_play, has anybody taken a stab at this?
Yes, there's no avoiding the requirement for both authentication methods.
Nobody has done any work on this as far as I know.
Alright, I'm going to take a stab at just refactoring mopidy-spotify-web to handle loading playlists instead of libspotify. That's the main thing that brought me here. I feel like if we can just pump the track data directly into libspotifys load/play methods we might be able to move piece by piece over. If that works well then I think that just having libspotify handle the streaming might not be too bad? I could be super naive tho ha. Going to look this weekend
until Spotify comes out with the vaunted replacement) for full-song Spotify playback in Mopidy.
There is also librespot.
It looks like @adamcik did a load of work on this last year. Does anyone know what the status of that branch is? Was the work completed?
https://github.com/mopidy/mopidy-spotify/commits/feature/web-api-lookup
Echoing what @jjok said, does it make sense to merge some of the web api functionality into mopidy-spotify?
BTW the new version of librespot can be found here https://github.com/librespot-org/librespot
I ran out of time to work on it, too much other stuff going on :( In other words this is up for grabs if someone else wants to solve it their way (or build on what I started).
So far we've implemented "your music" and fixed user playlists and personal "top lists".
There's still a few other features available through the Web API that we can integrate:
At which point I think we'll have everything Mopidy-Spotify-Web provides.