Web API Connect Endpoint - Queue

[TigerC10]

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.

[mmontag]

Thanks for the request @TigerC10. No guarantees for now, but we're definitely aware of this need internally.

[thSteve]

+1, I'm trying to build a Spotify/Slack integration for people at the office to queue up music!

[TigerC10]

@thSteve me too.

[NicolasHaeffner]

+1
And the ability to GET the next songs in the queue would be a major deal as well!

[terhuerne]

+1

[AnwariasEu]

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.

[timo-merlin]

+1
This would be very useful for a physical jukebox project I'm currently planning.

[olejon]

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

[maccettura]

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

[olejon]

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

[jpiepkow]

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

[TigerC10]

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

[olejon]

@TigerC10 If the API behaved this way it wouldn't be a problem:

• If context_uri is sent together with uris, the first track (or first in offset) in uris would not play before the currently playing track is finished. Then it would play the track(s) in uris and when the track(s) in uris are finished playing it would play context_uri
• That way I could store which album/artist/playlist URI my user was playing before playing a single track, PUT the album/artist/playlist URI to context_uri and the single track to uris, 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.

[dustinlieu]

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

[marcinciarka]

+1
I need this.

[okaufmann]

I need this too :)

[BenChand]

+1 This would be so much better than interrupting the current song

[mminklet]

I think every single Spotify API integration wants this feature.

[renpen]

+1
need this, too

[rewalker]

+1
I also need this

[TTF5]

+1

[rewalker]

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

[jdstregz]

👍

[niekert]

Like many others in this thread I've ran into the same issue with this endpoint not existing. So I would really like to see it added as well :)

As others described in this thread, my app wants to dynamically add tracks to the play queue (aka next song). Whenever a song ends or a user skips to the next song it should go the the song my app wants the user to hear.

I tried managing a playlist and adding songs my app wants played next after the currently playing track in that playlist, but that doesn't work either.

I've seen some comments with workarounds for libspotify but because that is deprecated I tried a workaround with the newer web playback SDK. It works but with some clear downsides. I'll try to explain the steps below

• Make sure your app knows about which track should come after the current track has ended (or skipped)
• Connect your app with the Web Playback SDK and control playback with it
• Listen for the Playback state changed event
• Each time the event is called, check if a new track has started (by checking if the position in a a track is 0).
• Check if the trackId matches the track your app expects. If not, send a play request for the track you expect

Obviously this is pretty cumbersome and far from ideal because

• You need to control playback from your app. So some devices like iPhones are not supported
• Your app needs to be open at all times to be able to handle the player_state_changed event. I think it's not possible in a node environment?
• You'll hear the next track if it's incorrect for a split second (before the play command lands) which you'll notice if a track starts loud

The APIs are great otherwise. Hopefully this is of some help for some 🙏

[fredbeast]

All I want for Christmas is this functionality.

[jorgenhanssen]

Dear Santa ...

[ecampostrini]

A couple of months ago it was possible to simulate a queue by adding a track to the ongoing playlist since it was eventually picked up. Now the client doesn't even do that, the tracks that are added after the PLAY request is sent with the playlist as the context are just ignored :(

Definitely +1 to the queue endpoint request.

[alexkohler]

+1

[sanieldalib]

+1

[florianbaer]

Probably better luck here...
https://community.spotify.com/t5/Social-Off-Topic/Response-to-the-Github-ChangeRequests/m-p/4634794#M30142

[AlbertMN]

+1 let's keep this issue going throughout 2019 as well. Would be an awesome feature.

[kaziwon]

+1

[BenChand]

+5

[humusdigital]

this functionality will be grate !

[2hands10fingers]

I have gotten the impression that people really want this feature.

[chatn0ir07]

Soo... any plans on introducing this functionality in 2019?

[frybin]

+1

[BenChand]

As a British person, this lack of queuing support is deeply offensive

[hhurja]

+1
I would be happy with even just the ability to retrieve the current queue

[arirawr]

Hi again folks -

We are very aware of your interest in this feature! I don't have any updates to share right now but I promise we'll post here as soon as we have an update for you.

[SebbeJohansson]

We are very aware of your interest in this feature! I don't have any updates to share right now but I promise we'll post here as soon as we have an update for you.

Okay great! Hope it's not that far off. The only reasoning I can come up with for not having a queue API endpoint is if Spotify is developing something on their own that they want to have 100% market share on.

[RobinvandenHurk]

Holy.... Spotify responded. Basically saying they're not working on it and it might take years?

[sirdoombox]

Holy.... Spotify responded. Basically saying it they're not working on it and it might take years?

I'm pretty sure the phrase "we're working on it" was never used. Doesn't seem like we're ever getting this feature honestly for reasons that they can't share.

[donifer]

@RobinvandenHurk Welcome to the real world. This is how companies work. Does the feature makes decent extra money? No? Then its way back in the backlog. 100% Understandable.

[RobinvandenHurk]

@RobinvandenHurk Welcome to the real world. This is how companies work. Does the feature makes decent extra money? No? Then its way back in the backlog. 100% Understandable.

Sure, it's understandable. However, a company also needs it's positive attention. Ignoring such a big request like this one does exact the opposite for them (at least in a developers view). That could lead to developers using different platforms. As a result Spotify could lose money on the long term.

For people to keep using your platform, you need to keep them happy, and give them what they want.

[donifer]

I agree, but 200 devs are really irrelevant to their business. It's not a big request.

I'll stop posting now, I don't want to keep spamming everyone. Apologies. Agree to disagree.

[jscholes]

Pretty sure Spotify have mentioned in the past the queue management is somewhat in a state of disarray at the moment, with each Connect client maintaining their own copy of the queue rather than it being centrally-managed. If they can't guarantee support for and a response from every Spotify Connect client in regards to queue handling, I can understand why this feature wouldn't be as simple as adding an endpoint and letting everybody go on their way.

[arirawr]

Locking this conversation to prevent spam to watchers. We'll still update here as soon as we have more info to share.