[GH-ISSUE #145] Viewing the current Play Queue

kerem commented

2026-02-28 14:46:51 +03:00

Owner

Originally created by @SethGower on GitHub (Nov 7, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/145

I feel like an essential part of listening to music, at least for me is the ability to check the current play queue, and add things to that queue. Is there any way this could get implemented? If you or other people can't do it, I may be able to try, but given I don't know rust, it'll take a while. Is this even possible with the api?

Originally created by @SethGower on GitHub (Nov 7, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/145 I feel like an essential part of listening to music, at least for me is the ability to check the current play queue, and add things to that queue. Is there any way this could get implemented? If you or other people can't do it, I may be able to try, but given I don't know rust, it'll take a _while_. Is this even possible with the api?

kerem closed this issue

2026-02-28 14:46:51 +03:00

kerem commented

2026-02-28 14:46:51 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Nov 8, 2019):

I too would love to have this. After glancing through the rspotify source and then also taking a look at the player endpoint of the web API to confirm, it unfortunately does not look possible at the moment.

This would be a really great (and presumably fairly simple) feature for Spotify to open up to the endpoint, though!

@sputnick1124 commented on GitHub (Nov 8, 2019): I too would love to have this. After glancing through the `rspotify` source and then also taking a look at the [player endpoint](https://developer.spotify.com/documentation/web-api/reference/player/) of the [web API](https://developer.spotify.com/documentation/web-api/reference/) to confirm, it unfortunately does not look possible at the moment. This would be a really great (and presumably fairly simple) feature for Spotify to open up to the endpoint, though!

kerem commented

2026-02-28 14:46:51 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Nov 8, 2019):

Curiously, it does look like the information is available to the Web Playback SDK (or at least a close enough approximation). I wonder if we could leverage it somehow...

UPDATE: I don't see any way of interacting with whatever endpoint the SDK queries. I think this is dead in the water until the web API is extended.

@sputnick1124 commented on GitHub (Nov 8, 2019): Curiously, it does look like the information is available to the [Web Playback SDK](https://developer.spotify.com/documentation/web-playback-sdk/reference/#object-web-playback-state) (or at least a close enough approximation). I wonder if we could leverage it somehow... UPDATE: I don't see any way of interacting with whatever endpoint the SDK queries. I think this is dead in the water until the web API is extended.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 8, 2019):

You're right @sputnick1124, Spotify doesn't give is this feature via their API.

It might be possible to manually create this feature - the play endpoint can accept an array of track uris. However, going down this route would mean that everytime you want to edit the play queue you'd have to send the play request and interrupt your current playback.

So yes, doesn't look like there's a way to do this right now.

@Rigellute commented on GitHub (Nov 8, 2019): You're right @sputnick1124, Spotify doesn't give is this feature via their API. It might be possible to manually create this feature - the `play` endpoint can accept an array of track `uris`. However, going down this route would mean that everytime you want to edit the play queue you'd have to send the play request and interrupt your current playback. So yes, doesn't look like there's a way to do this right now.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@SethGower commented on GitHub (Nov 8, 2019):

After some research, I also found this isn't really possible. I found this talking about it. It mentions "as they are stored locally on the device right now", which could make it possible. If there is a way to access that, that way. I have been poking through the source code for spotifyd trying to find a way to potentially implement something like and another feature I want. I am not sure how the Spotify client works, if that stored info is able to be accessed then it may be possible, but probably only for local playing.

I am confused however, because obviously the queue is available, since when I am playing on spotifyd I can see the current queue on my phone on the android app. So this information must be accessible somehow between devices.

@SethGower commented on GitHub (Nov 8, 2019): After some research, I also found this isn't really possible. I found [this](https://github.com/spotify/web-api/issues/921) talking about it. It mentions "as they are stored locally on the device right now", which could make it possible. If there is a way to access that, that way. I have been poking through the source code for `spotifyd` trying to find a way to potentially implement something like and another feature I want. I am not sure how the Spotify client works, if that stored info is able to be accessed then it may be possible, but probably only for local playing. I am confused however, because obviously the queue is available, since when I am playing on `spotifyd` I can see the current queue on my phone on the android app. So this information must be accessible somehow between devices.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@SethGower commented on GitHub (Nov 8, 2019):

Forgive me if this is a stupid question, but I am not experienced with Web development, Rust or dealing with APIs. But would be able to leverage this part of spotify's web sdk? The WebPlaybackState object has an attribute next_tracks: [<WebPlaybackTrack>, <WebPlaybackTrack>, ...] // Tracks queued next. Number can vary..

@SethGower commented on GitHub (Nov 8, 2019): Forgive me if this is a stupid question, but I am not experienced with Web development, Rust or dealing with APIs. But would be able to leverage [this](https://developer.spotify.com/documentation/web-playback-sdk/reference/#object-web-playback-track) part of spotify's web sdk? The WebPlaybackState object has an attribute `next_tracks: [<WebPlaybackTrack>, <WebPlaybackTrack>, ...] // Tracks queued next. Number can vary.`.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Nov 9, 2019):

It looks like this is an oft-requested feature and the Spotify developers are aware of the need/demand for the gap to be filled.
Closed issues:
https://github.com/spotify/web-api/issues/921
https://github.com/spotify/web-api/issues/629
https://github.com/spotify/web-api/issues/15
https://github.com/spotify/web-api/issues/453

Current tracking issue (last update Jan 2019):
https://github.com/spotify/web-api/issues/462

@SethGower, after reading through some of the issue threads above, it seems that all of the workarounds for the lack of a queue api have been far less than ideal. I think if spotify-tui were to implement some local queuing, it would be likely be quite tricky and cumbersome to manage (see a possible design with drawbacks below).

The WebPlayback request you mentioned exists in the javascript frontend SDK, and looks limited at any rate. It does not expose any endpoint that we can access through the Web API.

We could potentially implement a local queue of sorts, but that comes with at least the following complications:

Firstly, all storage/management/update of the queue falls on the local app.
We would have to handle repeat/shuffle on our own.
Every new track in the local queue would have to be played individually through the API, which means we would have to poll more frequently to get the current status of the player to know when to send the command to get to the next track.
Since all of the above are separate, but parallel, features from the API itself, the app has to be very context-aware of the queue, and handle the user's input differently for the queue than everywhere else in the app.

The only other option I could see would be to manage a playlist and pretend that it is a queue, but that is an abuse of what the playlist object is supposed to be, imo. Besides that, there is already an item on the Roadmap for implementing playlist management.

And no, this was not a stupid question! This is a legitimate gap in Spotify's API, and it was certainly worth the thought in trying to find a workaround for it! Unfortunately, I think solving this particular issue lies firmly in the purview of the Spotify developers, and not on the client-side consumers.

@sputnick1124 commented on GitHub (Nov 9, 2019): It looks like this is an oft-requested feature and the Spotify developers are aware of the need/demand for the gap to be filled. Closed issues: https://github.com/spotify/web-api/issues/921 https://github.com/spotify/web-api/issues/629 https://github.com/spotify/web-api/issues/15 https://github.com/spotify/web-api/issues/453 Current tracking issue (last update Jan 2019): https://github.com/spotify/web-api/issues/462 @SethGower, after reading through some of the issue threads above, it seems that all of the workarounds for the lack of a queue api have been far less than ideal. I think if `spotify-tui` were to implement some local queuing, it would be likely be quite tricky and cumbersome to manage (see a possible design with drawbacks below). The `WebPlayback` request you mentioned exists in the javascript frontend SDK, and looks limited at any rate. It does not expose any endpoint that we can access through the Web API. We could potentially implement a local queue of sorts, but that comes with at least the following complications: * Firstly, all storage/management/update of the queue falls on the local app. * We would have to handle repeat/shuffle on our own. * Every new track in the local queue would have to be played individually through the API, which means we would have to poll more frequently to get the current status of the player to know when to send the command to get to the next track. * Since all of the above are separate, but parallel, features from the API itself, the app has to be very context-aware of the queue, and handle the user's input differently for the queue than everywhere else in the app. The only other option I could see would be to manage a playlist and pretend that it is a queue, but that is an abuse of what the playlist object is supposed to be, imo. Besides that, there is already an item on the [Roadmap](https://github.com/Rigellute/spotify-tui#roadmap) for implementing playlist management. And no, this was not a stupid question! This is a legitimate gap in Spotify's API, and it was certainly worth the thought in trying to find a workaround for it! Unfortunately, I think solving this particular issue lies firmly in the purview of the Spotify developers, and not on the client-side consumers.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@SethGower commented on GitHub (Nov 10, 2019):

Thanks, for all of the info. I saw all those issues, but was hoping there was a way to get around it. It still keeps bugging at me how the other apps and such do it. Since the issue I referenced earlier states that the local device performs the queuing, but after looking through the source code for both spt and spotifyd it is obvious that that isn't really the case. Then again I could have missed something, since I am still trying to learn rust (currently reading through the book, which is superb). I do want to try and contribute to this program, so will try to keep my eye on issues to see if I can tackle something.

@SethGower commented on GitHub (Nov 10, 2019): Thanks, for all of the info. I saw all those issues, but was hoping there was a way to get around it. It still keeps bugging at me how the other apps and such do it. Since the issue I referenced earlier states that the local device performs the queuing, but after looking through the source code for both `spt` and `spotifyd` it is obvious that that isn't really the case. Then again I could have missed something, since I am still trying to learn `rust` (currently reading through the book, which is superb). I do want to try and contribute to this program, so will try to keep my eye on issues to see if I can tackle something.

kerem commented

2026-02-28 14:46:52 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 11, 2019):

Thanks for the investigation work @sputnick1124 @SethGower.

Shame that Spotify don't offer the play queue in their API.

I'll close this issue as there's no much we can do for now.

@SethGower great that you're learning Rust - the book is the best place to start. And also great to know you're interested in contributing!

@Rigellute commented on GitHub (Nov 11, 2019): Thanks for the investigation work @sputnick1124 @SethGower. Shame that Spotify don't offer the play queue in their API. I'll close this issue as there's no much we can do for now. @SethGower great that you're learning Rust - the book is the best place to start. And also great to know you're interested in contributing!

kerem referenced this issue

2026-02-28 14:50:08 +03:00

[PR #79] [MERGED] Handle delete key (for real) #594

Rows
Columns

[GH-ISSUE #145] Viewing the current Play Queue #79