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?

[ski7777]

Wats the state? When to expect a queue API?

[brandoncornel]

+1

[florianbaer]

@mmontag Can you give us an update for this feature request / issue?

[2hands10fingers]

+1

Really interested in this ability.

[mayoforkovic]

+1

[andyjduncan]

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?

[mminklet]

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.

[florianbaer]

@MichaelMallett Why? What gives you the reason to say this? Don't understand me wrong, i'm just wondering :grin:

[marcinciarka]

It's unlikely they're going to implement this anytime soon

This is a horrible thing to say man :(

[mminklet]

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.

[BenChand]

I don't subscribe to this post for such negative comments Michael

[mminklet]

It's not being negative, I've just offered an alternative way to do it with open source software (mopidy). Surely that's slightly more helpful than endless "+1s"?

On 24 Nov. 2017 09:11, "Ben Chand" notifications@github.com wrote:

I don't subscribe to this post for such negative comments Michael

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spotify/web-api/issues/462#issuecomment-346703439, or mute the thread https://github.com/notifications/unsubscribe-auth/AEYKGOExakzR9lcowZianodxoTlKI5HXks5s5e2egaJpZM4Mv-Up .

[BenChand]

I like the +1s, they keep the dream alive

[mminklet]

Great! And for people who want to get something done now, rather than sit and wait for an unknown length of time, there are alternative methods to achieve this.

If that's not for you, no problem, keep waiting. But it's not being negative it's being proactive.

Bye!

On 24 Nov. 2017 09:14, "Ben Chand" notifications@github.com wrote:

I like the +1s, they keep the dream alive

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spotify/web-api/issues/462#issuecomment-346703676, or mute the thread https://github.com/notifications/unsubscribe-auth/AEYKGFJDH2OotGCBHDS7FZx96wzMniYVks5s5e4-gaJpZM4Mv-Up .

[evanrobertson]

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

[mminklet]

Right, but for a lot of use cases it can achieve what people want eg controlling an office playlist through slack. If it doesn't, sorry.

On 24 Nov. 2017 09:21, "Evan Robertson" notifications@github.com wrote:

@MichaelMallett https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spotify/web-api/issues/462#issuecomment-346704185, or mute the thread https://github.com/notifications/unsubscribe-auth/AEYKGEcIp0vi_a2G1Z_3q08JMoGK3e8Vks5s5e_4gaJpZM4Mv-Up .

[olejon]

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.

[mminklet]

Sigh

At no point am I suggesting it's part of the actual Spotify Web api. All I'm saying is that you can achieve what a lot of people are trying to achieve with this api call, but with a more involved solution. I know it works because I've done it

If that doesn't fit your model, then apologies. However I wouldn't hold your breath requesting this queue endpoint. I hope it comes soon but this is not the first ticket asking for this feature. So, being software developers, if it's something you need now it's probably a good idea to explore other solutions

On 24 Nov. 2017 10:15, "Ole Jon Bjørkum" notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spotify/web-api/issues/462#issuecomment-346708176, or mute the thread https://github.com/notifications/unsubscribe-auth/AEYKGI51IPTE5ITWflxOj_KF509WNTUqks5s5fyagaJpZM4Mv-Up .

[olejon]

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.

[olejon]

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

[armada877]

+1

[GhostfromTexas]

+1 Would love to be able to control and query a queue like you can in the app from the Web API

[devinshoemaker]

+1 Like everyone else, I would love to have this for a Slack integration for the office.

[jpack482]

Ditto. Slack, shared queue.

[kingosticks]

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

[MakerTim]

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)

[kingosticks]

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:

1. Open the Android application and queue up a bunch of songs.
2. Open the desktop application and observe those songs are in the queue.
3. Close the desktop application.
4. Go back to the Android application and queue up a bunch of different songs.
5. Disconnect the internet connections on your Android device (flight mode is easiest).
6. 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.

[TigerC10]

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?