Skip to content

feat: remove from playlists and tell whether one holds a track - #411

Merged
devgianlu merged 1 commit into
devgianlu:masterfrom
isnogudus:feature/playlist-remove
Oct 14, 2026
Merged

devgianlu merged 1 commit into
devgianlu:masterfrom
isnogudus:feature/playlist-remove

Conversation

@isnogudus

@isnogudus isnogudus commented Oct 2, 2026 •

Copy link
Copy Markdown

Adds the two pieces a client needs to edit playlists comfortably: removing an entry, and checking for a duplicate before adding.

POST /library/playlists/remove_track {"playlist_uri", "uri", "position"} removes one entry from a playlist the user may edit.

  • Playlists can hold the same track more than once, so the client passes the position it listed the entry at (position is optional; without it the first occurrence goes).
  • The daemon reads the playlist, checks that the position still holds uri, and sends a REM change by index range (from_index, length 1) based on the current revision; it is retried once if the playlist changed meanwhile. An entry no longer at its position answers 409, so the client lists the playlist again instead of removing the wrong track.
  • I first keyed the removal by the item (Rem.items_as_key, as some clients do): Spotify then removed every duplicate of the track. Removing by index range removes exactly the named entry.
  • Like appending, a removal drops the cached /context/tracks listing.

GET /library/playlists/contains?playlist_uri=…&uris=… tells whether a playlist already holds up to 50 items, so a client can ask before adding a duplicate. The playlist is read fresh on every call.

Both read the playlist with the new Spclient.PlaylistContents, which pages through it (from/length, following truncated) and reports a revision change between pages as a conflict. PlaylistAppend and PlaylistRemove now share how a change is sent.

Testing

  • Unit tests for paging and its conflict, the index-range removal (not keyed), picking the entry (named duplicate, first occurrence, stale position, missing item) and the API validation.
  • Ran against a real account on a scratch playlist: with entries A, A, B, A, removing position 3 left A, A, B — the named duplicate only; contains answers correctly for a held and a missing track; a 1508-track playlist reads completely.
  • go mod tidy, go generate ./..., gofmt, build and go test -tags "test_unit test_integration" ./... are clean.

🤖 Generated with Claude Code

Add POST /library/playlists/remove_track, which removes one entry from a
playlist the user may edit: a REM change by index range, one entry at
the position the client listed it, or else at the first occurrence.
Playlists may hold an item more than once, and keying the removal by the
item (Rem.items_as_key) would remove every duplicate, so the daemon
checks that the position still holds the track and removes that entry
only. The removal is based on the playlist's current revision and
retried once when it changed; an entry no longer at its position is
reported as 409 so the client lists the playlist again. Like appending,
it drops the cached listing.

Add GET /library/playlists/contains, which tells whether a playlist
already holds items, so clients can ask before adding a duplicate.

Both read the playlist through the new Spclient.PlaylistContents, which
pages through it and reports a change between pages as a conflict.
PlaylistAppend and PlaylistRemove now share how a change is sent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@isnogudus
isnogudus force-pushed the feature/playlist-remove branch from 9cb6f4d to 7e387e9 Compare October 3, 2026 13:32
@devgianlu
devgianlu merged commit d0f8d12 into devgianlu:master Oct 14, 2026
11 checks passed
@isnogudus
isnogudus deleted the feature/playlist-remove branch October 14, 2026 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants