Web API Connect Endpoint - Queue
TigerC10 opened this issue · 138 comments
The new Web API Connect Endpoints that @asmitter informed us about in #15 are fantastic! However, I notice that there's no endpoint listed to append a track to the queue. As it is, /v1/me/player/play will replace the currently playing song if you pass URIs.
It'd be great to have a queue endpoint to append tracks to the currently playing queue. That way music isn't interrupted but requested songs will eventually play.
Thanks for the request @TigerC10. No guarantees for now, but we're definitely aware of this need internally.
+1, I'm trying to build a Spotify/Slack integration for people at the office to queue up music!
+1
And the ability to GET the next songs in the queue would be a major deal as well!
+1
I also would like the option to queue songs via the web api.
This function is required to create a party mode where unauthorized users are able to enqueue songs but not able to change the current playback.
+1
This would be very useful for a physical jukebox project I'm currently planning.
+1. Queue is really needed. Playing a track with "play" endpoint plays the track over and over again instead of continuing playing what was playing before, like a playlist (default behavior of the Spotify desktop client and apps).
+1
On the "vote for next song" app I am making for the office, its becoming apparent that this feature is needed to continue.
The ability to add to queue and query said queue would be a huge help.
Why is it not possible to provide a context_uri along with uris? That way, one could put a single track from an artist, album or playlist to the API and the artist/album/playlist URI as context_uri so that the the context continues to play after the track. That way only two URIs would be needed to send to the API (track and context).
ALSO it would effectively make it a Queue API which many wants as one could then put single tracks to the API, for example all tracks in an album and then a Playlist as context and the playlist would play when the album finishes.
BTW I see you have increased the data one can PUT to the endpoint. When providing a URI as offset, before it was only possible to PUT 266 track URIs and now it is possible to put 378. I wish there was a reasonable limit. All track URIs have the same length so... Set a limit for at least 1000 URIs (including offset etc, I know the API cares about how many bytes you send and not the amount of URIs).
@maccettura I made an application ( https://spin.social ) that does exactly what your trying to do.
Join based on location and vote for the next song. The code is not open but I will say in order to get it semi working I had to use the hackish way of adding a song to a playlist and doing a couple different things to make sure that the client would pick up the fact a new song was added. On big downside is the song added has to be 1 song out from the next or desktop/phone client will go to radio even though it shows a song added.
@olejon I don't think that's enough, using the context_uri that way wouldn't prevent the issue of replacing the currently playing track. Furthermore, you'd have to create a new playlist and append the tracks to that new playlist then send that playlist to the context_uri. I mean, it's a hacky workaround, but theoretically possible. Still, you don't queue up songs to be played next with this strategy and moreover you still have the problem of replacing the currently playing song (cutting it short).
We need a full fledged queuing endpoint.
@TigerC10 If the API behaved this way it wouldn't be a problem:
- If
context_uriis sent together withuris, the first track (or first inoffset) inuriswould not play before the currently playing track is finished. Then it would play the track(s) inurisand when the track(s) inurisare finished playing it would playcontext_uri - That way I could store which album/artist/playlist URI my user was playing before playing a single track,
PUTthe album/artist/playlist URI tocontext_uriand the single track touris, or more tracks
I see Spotify has increased the amount of data one can PUT to /v1/me/player/play to 378 uris when also sending offset as a URI, after some testing I found that that was the limit (it is a data limit so I suppose one can add 1 or 2 more URIs if not using offset. Before it was 266 URIs when also sending offset as URI), since all URIs have the same length.
This way one could at least have a Queue with 378 tracks or more. In your code you could easily make a GUI to modify the array of URIs to PUT together with context_uri, for example move a URI up or down, or remove it, then PUT the new info to the API.
+1
I've tried working around the lack of a queue API by using playlists, but adding tracks to the playlist and playing the playlist in quick succession ends up extremely glitchy. It'd be really useful to have a queue endpoint to do it properly.
+1
I need this.
I need this too :)
+1 This would be so much better than interrupting the current song
I think every single Spotify API integration wants this feature.
+1
need this, too
+1
I also need this
+1
@mmontag Hi, we are planning to built an app that needs to access the queue from the web api. We would like to know if the spotify dev team are currently working on this?
Wats the state? When to expect a queue API?
+1
@mmontag Can you give us an update for this feature request / issue?
+1
Really interested in this ability.
+1
It appears that between this issue and #537 it is impossible to dynamically control tracks to be played via this API without completely managing the player. Am I reading this correctly?
It's unlikely they're going to implement this anytime soon, but if anyone wants a workaround you can install mopidy and mopidy-spotify, and then use a client (http, mpc) to control the queue. It's far more involved than just controlling spotify via an api, but it's more powerful.
@MichaelMallett Why? What gives you the reason to say this? Don't understand me wrong, i'm just wondering 😁
It's unlikely they're going to implement this anytime soon
This is a horrible thing to say man :(
Not really. People have been asking for this for years, it's clearly not on their roadmap or list of priorities. Maybe it'll happen someday but don't hold your breath, find another way.
I don't subscribe to this post for such negative comments Michael
I like the +1s, they keep the dream alive
@MichaelMallett I don't think mopidy is a solution for an api endpoint request. Most people are after the endpoint to integrate with some software they are developing. Mopidy only slots into a very specific locally playing scenario, and relies on the deprecated libspotify.
Mopdiy has nothing to do with the web API, it's based on libspotify and requires therefore Premium for everything, which the web API doesn't (paying Premium is just logical for me but still). Many endpoints do not but I suppose a queue endpoint will as part of the player API.
The current set of Connect Web API endpoints do require a premium account. There's every reason to assume that, if/when queue manipulation endpoints are implemented, the same will hold true for them too.
@jscholes Did you read the last sentence in my comment?
Many endpoints do not but I suppose a queue endpoint will as part of the player API.
It's quite weird how Spotify has put so much effort into the player API but no added this feature. I kind of assumed this API was created for Spotify's apps as well, including the desktop app and the web player, to make one single solution that suits them and developers. Of course their apps will have an exception where the player API works even when not premium. That's just how it must be. I totally accept premium being a requirement for third parties. Anyway my app can control the desktop client without premium as well, since it's for Linux, and therefore can use D-Bus and automatically check if the user is premium or not when authenticating, and use the player API if so, and if not, D-Bus (MPRIS) and lose some functionality, but get a lot (remote control and all endpoints without premium or auth requirement), including actually a better queue, but only if downgrading to v 0.9... which works good still with some extra steps on latest distributions. Also supports Spotify Connect and responds to the player API.
@MichaelMallett I have implemented a working solution for a queue, yes. It works just fine, as long as you don't PUT too many URIs to the play endpoint, since there's a data limit. Problem is it's a workaround of course as you say. Also it will never integrate well with the queue in the actual Spotify app/program, if the user switches to and from that to control it.
+1
+1 Would love to be able to control and query a queue like you can in the app from the Web API
+1 Like everyone else, I would love to have this for a Slack integration for the office.
Ditto. Slack, shared queue.
Its worth remembering that Spotify do not store the queue as part of their player state. Simply adding a queue API endpoint is a tiny part of the problem. Currently each player application (be it the official client, be it mopidy etc) keeps a local copy of the queue state. For Connect, the currently active app constantly publishes it's queue state for the listening apps to pick up and update their copy. I guess there's a limit to the length of that state update message (it can be sent very often).
my android client and my desktop client can send it over doh
when i add add a song to my queue and go to my android, and press next (with or without) switching to android to play music there, it knows what is next in the queue
so something is there. its not documented (yet)
Your desktop client publishes the state change and your subscribed Android app picks it up. There is no queue information held on their servers.
It's easy to observe this in action:
- Open the Android application and queue up a bunch of songs.
- Open the desktop application and observe those songs are in the queue.
- Close the desktop application.
- Go back to the Android application and queue up a bunch of different songs.
- Disconnect the internet connections on your Android device (flight mode is easiest).
- Reopen the desktop application again and observe the queue is empty.
I'm not talking about documentation or lack thereof, I'm talking about how Spotify works.
It's also worth noting that every spotify client (or at least every desktop client) is also a web server. The https://open.spotify.com/ is served by it. This locally running web server isn't publicly accessible, but it does provide the playback control for the desktop. Adding queuing support to this locally running web server is all that would really need to happen to make it available to the Web API Connect Endpoints.
I believe that the reason they're ignoring this issue is because of Spotify Connect. Spotify Connect compatible speakers have a shared queue that anyone at the party can add to with their own spotify apps on their phones. It's something hardware manufacturers pay for. If Spotify opened up queueing endpoints, what company would want to pay for Spotify Connect when they could just use the free queuing endpoints instead?
Then perhaps some official support for updating the queue via the Spotify client's server?
Every commercial enterprise that uses any of Spotify's technology in their product must license that technology i.e. pay. That's crystal clear if you read their developer terms. There is no such thing as free endpoints for commercial use (with some exceptions).
(This is going off topic, sorry.)
Exactly. In every country Spotify is in I'm sure they're have Trademark Registered and Copyrighted their name. So they have all legal means to take down physical products (and services and applications) not certified by Spotify or using their service illegally or not correctly. Every developer must register himself/herself to be able to access the API and let users authenticate, which would be even easier to shut down such developer accounts. And one can't just create a Spotify account using VPN if living in a country where Spotify doesn't operate, AFAIK it won't work unless you also have a valid standard credit/debit card from the country you're registering from. At least it was like that.
It would just be a cat and mouse game where Spotify would always win by taking legal actions against products sold in a country where Spotify operates, and outside bought products should be easy for them to shut down by everything from developer account, developer's domain name used for the secure authentication (if registered in said countries at least), and general detection of suspicious behaviour from tokens connected to a developer account. They would be shut down one by one.
I don't think the argument against third part hardware misusing the API holds. Then I would rather think it's the technical way the queue operates as described in the comment above. To make a queue API that works flawlessly they then need to do a lot of recoding. As Spotify themselves uses this API for their apps, I do think a queue API would have been there from the start if it wasn't for some problems the way the queue operates today. Spotify has given us so much with their API, and I see no other reason to not give us the queue except the above.
If say running an HTPC with Spotify using the official mobile app to control it, one can pretty easily build more or less a clone both functionality wise and design wise (or IMO better, stick to the platform's guidelines...) and control everything, if the user is Premium (or running Linux thanks to MPRIS and PulseAudio), and actually control even more than the mobile app. Like the PC itself for instance (suspend, wake on LAN, lyrics, such things). The exception, which is crucial, is the queue. My workaround works OK but definitely more code than should be needed, and some bugs (or maybe I'll say tricks, to make it work as expected).
But it's interesting their response is "they're definitely aware of this problem internally" so...
... yes going a bit off topic but what more can we do than guess why Spotify doesn't give us a queue API when there's no official and technical response as to why? :)
i found this https://www.jqbx.fm/ website does what some of the people wanted to achieve here...
+1, would love to see a dedicated queue endpoint
I don't know if this is useful to anyone but I think I'm onto a way to implement a play queue closer to an approximation to an official queue endpoint as has previously been possible, by using a combination of the web API and the new web SDK.
The current issue is that the only way you can get Spotify to play a song with these endpoints is to use the play endpoint, which clears the context of what the user was previously listening to. However, new information that we can now get from the web SDK released in December is the context URI, i.e. what playlist/artist page/album Spotify is currently playing from.
The concept I am trying to implement is the following:
- Store a local play queue in the application consuming Spotify's API.
- When a song finishes (the SDK gets its playback state updated regularly, so you can find this information out now), store the current context and use the play endpoint to start playing the first song in the queue.
- Repeat for any further songs in the queue.
- Once the queue is exhausted, resume the users' previous playback by calling the
playendpoint with the stored context URI. - One restriction is that if the previous context was shuffled, you won't be able to resume that same shuffle state. However, you are told in the playback state object whether the context is shuffled, so you can at least create a new shuffled version of that context. If you're feeling really fancy you could even keep track of played songs and what the upcoming songs previously were, and shuffle a bunch of times until you have as close an approximation to the previous shuffle state as possible.
- Another limitation is that the user has to be listening through a web application implementing the web SDK for this to work, as the application implementing the SDK only receives the current playback state if it is the active device. However you can have the server side component keep track of the playback state as well so that if the user ends playback on that device, at the least you can copy your local queue to a temporary playlist and use the web API server-side to consume that playlist through to completion and then resume context and remove the playlist.
Some of this is perhaps a little over-engineered, and to be clear I haven't implemented it all yet, these are just some thoughts on working around this limitation, but I hope it at least helps a few people.
+1 would love this feature.
+1 I really need this feature for an app I have in mind
+1 this would be really amazing, also the ability to get the current queue
+1 would be fantastic
+1, Please add this feature!
+1 would love to have this feature!
+1 would love to have this feature!
+1 working on a twitch extension and would like to have users be able to request a song and add it to the broadcasters music queue
would be fantastic, looking forward to this.
Looking for that! That would be awesome
+1
+1
+1
+1
+1
+1
Hi developers! We know you want to show support for this issue, but please refrain from writing comments containing only +1, as this sends unnecessary notifications to everyone on the thread. Instead, use a GitHub Reaction to plus-one comments or issues and click the "Subscribe" button in the right-hand menu to receive updates. Thanks 😄
@arirawr Please deliver so we can stop spamming you (and everyone) with +1s
tldr; Nobody from Spotify is responding to these threads saying that it's even on the roadmap - literally the only thing we can do is demand the feature via popular harassment. Until someone can give us an ETA to look forward to, this is our only option.
Someone else, on a totally different ticket (#15) asked exactly the same thing on Jun 4, 2016 and it didn't stick. #15 gained 98 thumbs ups. This issue, #462, has 106 thumbs and is currently the second most requested issue on the issue sorting page. I would argue, given all the requests for it from the original #15, it is the most requested feature.
+1
+1
+10086
pleaaaaaaaseeeeeeeeeee +11111111
+1
+1
+1 for God's sake
Manual Implementation:
- Create a Spotify playlist
- Queue one song at a time into the player
- Keep playlist tracks stored locally
- Display a fake "queue" of those tracks
- Allow user to update playlist as needed, send request to update playlist, then update your "fake queue", but don't change the player
- On song end, load the next song uri asap
- Send github request to add "+1" comment on this thread on every new song
More or less my solution except spamming this thread.
+1
+1
Plus one ^.^
Is this thread ever going to be closed ?
Queue is really needed
@jeanvallon I think they're just as amused as we are in keeping this thread alive.
+2
+404 feature not found
+1
@mmontag Any news about this ? Is it at least in your roadmap ?
Thank you !
Hey @blackarcanis and others, we don't have any updates on this feature request right now. I'll be sure to update here as soon as we have any more information for you.
+1
+1
Since we might have to wait a couple more years for our requested features to be added, you could try to kind of create your own "queue".
You could create a new playlist, and only use that playlist as context, without shuffle. From there, you can at least add/remove songs from the "queue". Though i have tested this a bit, and it works, I'm not sure how well this "workaround" works. Just thought it might help someone out ther.
Surely, this isn't a very practical solution, but I guess it's better than nothing?
+1
+1
Spotify pls +1
I am in the lucky position where I have a working "append" capability in my project - but only because I still use the long-deprecated libspotify API for playing (with Web API for browsing/choosing). So far, back-end support for this ancient library has not yet been withdrawn or broken. But I would love to move onto a more modern API without losing existing functionality - and that means being able to enqueue further albums or tracks onto a running player.
Please (please!) do not break libspotify support until this has been implemented long enough for me to re-work my implementation.
It would really help if there is a way to update the currently playing playlist to it's latest snapshot_id.
+1
Just ran into the need for this myself, disappointed to see that this issue is well over a year old and is seemingly dead in the water even though the need for it is quite clear.