Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out what to do with mopidy-spotify "vs" mopidy-spotify-web recent given Spotify changes? #114

Closed
adamcik opened this issue Aug 29, 2016 · 20 comments
Assignees
Labels
A-webapi Area: Spotify Web API

Comments

@adamcik
Copy link
Member

adamcik commented Aug 29, 2016

Given #110 we will probably end up having to move in a direction where we do one of the following:

  1. mopidy-spotify does just streaming
  2. mopidy-spotify steps on the toes of mopidy-spotify-web
  3. 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?

@lfcabend
Copy link

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.

@adamcik
Copy link
Member Author

adamcik commented Aug 29, 2016

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

@trygveaa
Copy link
Member

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.

@allquixotic
Copy link

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.

@adamcik
Copy link
Member Author

adamcik commented Aug 31, 2016

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.

@nefaspartim
Copy link

Is there work already started on merging these two modules?

@lfcabend
Copy link

No, I guess we are waiting for this new library to replace libspotify.

@nefaspartim
Copy link

Is that library a real thing? I have some contacts at Spotify, I'll ask to see if they know anything about it.

@lfcabend
Copy link

If you go to https://developer.spotify.com/technologies/libspotify/ they are promising this.

@trygveaa
Copy link
Member

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

@kingosticks
Copy link
Member

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.

@fleeco
Copy link

fleeco commented Apr 27, 2017

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?

@kingosticks
Copy link
Member

Yes, there's no avoiding the requirement for both authentication methods.

Nobody has done any work on this as far as I know.

@fleeco
Copy link

fleeco commented Apr 27, 2017

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

@marsjaninzmarsa
Copy link

marsjaninzmarsa commented Aug 24, 2017

until Spotify comes out with the vaunted replacement) for full-song Spotify playback in Mopidy.

There is also librespot.

@jjok
Copy link

jjok commented Sep 25, 2018

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

@mdedetrich
Copy link

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

@adamcik
Copy link
Member Author

adamcik commented Feb 23, 2019

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

@kingosticks kingosticks self-assigned this Dec 18, 2019
@kingosticks kingosticks added the A-webapi Area: Spotify Web API label Dec 18, 2019
@kingosticks kingosticks added this to the v4.0 milestone Dec 18, 2019
@kingosticks
Copy link
Member

kingosticks commented Dec 18, 2019

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.

@jodal jodal modified the milestones: v4.0.0, v4.1.0 Dec 22, 2019
@kingosticks
Copy link
Member

Not sure why this one is still open other than to track the remaining missing features, they can live in their own issues if people feel they are important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-webapi Area: Spotify Web API
Projects
None yet
Development

No branches or pull requests