Problem Statement
Current track playback via Connect is fully synced — metadata, seek, skip, pause all work correctly (confirmed after the #126/#129 fixes). But the actual queue isn't:
- Adding tracks to the queue from the Spotify app (tested from both a MacBook and a phone, same account) never shows up in LMS's queue/playlist view
- Consistent across JiveLite and Material Skin — only the currently playing (or paused) track is ever shown
- Meanwhile the Spotify app itself correctly shows the queue
Checked Connect.pm for any existing queue handling — there is none at all (no queue/next_track/prev_track references).
Proposed Solution
There are two viable paths here, at different levels:
Option A — Web API polling (GET /me/player/queue). Verified this works today with the bundled (Extended Quota) Client ID — I haven't tested this with my own Dev Mode Client ID, so not sure if it's restricted there too:
curl "https://api.spotify.com/v1/me/player/queue" -H "Authorization: Bearer $TOKEN"
Tested with 2 manually-queued tracks (one from a MacBook, one from a phone) plus autoplay continuation — the response correctly reflects currently_playing and both manually-queued tracks. This is the easy path: purely Perl-side, no librespot fork merge, no Rust→Perl channel changes.
But it's polling, not push — there'd always be a lag between a queue change (e.g. reordering a track in the Spotify app) and SpotOn noticing it, and it adds recurring calls to the same shared rate-limited pipeline that DSTM and everything else already competes over (the ~30 calls/30s budget mentioned in the DSTM thread). Given that constraint, I'd actually lean away from this as the primary approach.
Option B — Spirc-level events (preferred). Two complementary upstream librespot PRs:
- librespot#1677 —
Player::SetQueue event, emitted the instant the queue changes (reorder, add, remove), with full state (context_uri, current_track, next_tracks, prev_tracks, each tagged context/queue/autoplay). Opt-in via ConnectConfig.
- librespot#1676 —
Spirc::add_to_queue(), the complementary piece for adding to the queue from LMS.
This is more work (cherry-picking both into the fork, since neither is in the current "upgraded to dev branch" set, plus extending the Rust→Perl event channel to carry structured lists instead of single scalars — similar shape to #126/#129, larger scope), but it's event-driven rather than polled, doesn't touch the shared Web API rate budget at all, and would presumably also catch reordering (moving a track within the queue in the Spotify app), not just additions — something I haven't verified Option A handles well either, given the lag.
Given the rate-limit-sharing concern, Option B seems like the better fit long-term even though it's the larger lift. Happy to help test whichever direction this goes.
Completely understand this is a bigger ask and your time/tokens isn't unlimited across everything else going on — no pressure at all. Just think this could be a genuinely nice feature to have, especially with Spotify Jam sessions becoming more common (multiple people adding/reordering tracks in a shared queue) — that's exactly the scenario where LMS staying blind to the queue is most noticeable.
Cheers
Alternatives Considered
No response
Problem Statement
Current track playback via Connect is fully synced — metadata, seek, skip, pause all work correctly (confirmed after the #126/#129 fixes). But the actual queue isn't:
Checked
Connect.pmfor any existing queue handling — there is none at all (noqueue/next_track/prev_trackreferences).Proposed Solution
There are two viable paths here, at different levels:
Option A — Web API polling (
GET /me/player/queue). Verified this works today with the bundled (Extended Quota) Client ID — I haven't tested this with my own Dev Mode Client ID, so not sure if it's restricted there too:Tested with 2 manually-queued tracks (one from a MacBook, one from a phone) plus autoplay continuation — the response correctly reflects
currently_playingand both manually-queued tracks. This is the easy path: purely Perl-side, no librespot fork merge, no Rust→Perl channel changes.But it's polling, not push — there'd always be a lag between a queue change (e.g. reordering a track in the Spotify app) and SpotOn noticing it, and it adds recurring calls to the same shared rate-limited pipeline that DSTM and everything else already competes over (the ~30 calls/30s budget mentioned in the DSTM thread). Given that constraint, I'd actually lean away from this as the primary approach.
Option B — Spirc-level events (preferred). Two complementary upstream librespot PRs:
Player::SetQueueevent, emitted the instant the queue changes (reorder, add, remove), with full state (context_uri,current_track,next_tracks,prev_tracks, each taggedcontext/queue/autoplay). Opt-in viaConnectConfig.Spirc::add_to_queue(), the complementary piece for adding to the queue from LMS.This is more work (cherry-picking both into the fork, since neither is in the current "upgraded to dev branch" set, plus extending the Rust→Perl event channel to carry structured lists instead of single scalars — similar shape to #126/#129, larger scope), but it's event-driven rather than polled, doesn't touch the shared Web API rate budget at all, and would presumably also catch reordering (moving a track within the queue in the Spotify app), not just additions — something I haven't verified Option A handles well either, given the lag.
Given the rate-limit-sharing concern, Option B seems like the better fit long-term even though it's the larger lift. Happy to help test whichever direction this goes.
Completely understand this is a bigger ask and your time/tokens isn't unlimited across everything else going on — no pressure at all. Just think this could be a genuinely nice feature to have, especially with Spotify Jam sessions becoming more common (multiple people adding/reordering tracks in a shared queue) — that's exactly the scenario where LMS staying blind to the queue is most noticeable.
Cheers
Alternatives Considered
No response