[leodurandfr]

Lets a client show the tracks before and after the current one, like the queue view and the mini player swipe in the Spotify apps, and go back to the track it showed.

The daemon already holds that play order: the window Spotify Connect publishes, up to 32 tracks on each side with the user's queue and shuffling applied, and the metadata cache already prefetches it. Only next_track is exposed today. The Web API's GET /me/player/queue is not an option: with the daemon's token it answered 429.

Change

• GET /player/queue returns {prev_tracks, track, next_tracks}, each entry {uri, uid, provider, track}:

  • provider is queue, context or autoplay, which is how the apps split their queue view.
  • uid tells two copies of a track apart, and is null where Spotify gives none, as for an album's tracks.
  • track has the /status shape, or is null until its metadata is cached (always null without metadata.enabled). The current entry carries the playing position, the others 0.

  prev_tracks is the play order, not a history. Without a session the endpoint answers 204.

• A queue event, with no data, says the response changed: the order moved, entries got their metadata, or the session ended. The position alone raises none.

• POST /player/prev takes an optional {"allow_seeking": bool}, the option of Connect's own skip_prev. false skips back from a track played past three seconds instead of rewinding it. The default is true, and a body that doesn't parse gets it too, since prev used to ignore its body.

• The first commit, independent of the others, makes track descriptions tolerate incomplete cached metadata: a cached track missing its album, an artist's name or its gid panicked the daemon on a /status read.

GET /status is unchanged: listing the window there would make every read about twenty times larger.

While a queued track plays, prev_tracks misses the context track played just before it: GoNext enters the queue without moving the context position, so a prev from the queued track lands one context track earlier and the queued track stays queued. Connect receives the same window. The PR doesn't change this; the /player/prev description now says where prev lands.

Tested

• gofmt, go vet and go test -count=1 -tags "test_unit test_integration" ./daemon/... ./spclient/... on each commit; oapi-codegen v2.5.0 regenerates daemon/api_gen.go without a diff.
• TestApiPlayerQueueWireFormat and TestPlayerQueue* cover the response (wire format, positions, local files, no metadata). TestQueueEvent* cover every emit site, the session end included: removing any one call fails a test. TestQueueKeepsItsEntriesNamed covers eviction during sweeps and listings, TestApiPrev the /player/prev body, and TestApiTrackToleratesIncompleteMetadata incomplete track and episode metadata. The allow_seeking dispatch has no unit test, since the three-second check needs a player with an output; the device run below covers it.
• On a Raspberry Pi 5 with the iOS app, on the reviewed revision (f64f57e): playlist entries are context with a uid and album entries have none; queued tracks are queue (q1, q2, …, two uids for a track queued twice) and stay queued when a new context starts; an album running out with autoplay on continued as a station with 32 autoplay entries; 32 to 37 named entries are 21 to 25 KB, read in 1 to 5 ms, against about 1 KB for /status; {"allow_seeking": false} 7 s into a track went to the previous one. On the current revision (150b9c0 on master 9085364), going back from a carousel with {"allow_seeking": false} went to the previous track rather than rewinding the current one. The queue event wiring as changed by the review has not been re-checked case by case on the device.

Not in this PR: playing or removing an entry by uid, and reordering the queue.

🤖 Generated with Claude Code

[devgianlu]

🤖 This review was generated by Claude (Claude Code), not written by hand. Please verify before acting on it.

None of these crash the daemon or play the wrong thing. The ones I'd fix before merging are the null entries after LRU eviction, the missed "gone" event, and the POST /player/prev 400 on bodies that aren't JSON. The API.md note is a quick docs fix.

Checked and fine: the req.Data.(ApiPrev) assertion can't panic (only built in PlayerPrev), provider values are always queue/context/autoplay, and peek handles a nil cache when metadata is disabled.

[leodurandfr]

Thanks for the review. I rebased on master (9085364) and folded the fixes into the same three commits: bdcc739, 19de8e9 and 150b9c0. The queue event is now emitted where the play order or its metadata changes, and only when the response's signature differs from the last one announced; removing any of those calls fails a test. The only thing I kept as it was is the k.uri != "" filter; the thread on it explains why.