Queue a whole album or an artist's entire discography in one action #7

Merged

kyuno merged 1 commit from feature/queue-album-and-discography into master

2026-09-16 07:54:14 +02:00

kyuno commented

2026-09-16 07:46:52 +02:00

Owner

Summary

views/album gets a page-level "Écouter cet album" / "Ajouter l'album à la file" button, alongside the existing per-track ones.
views/artist gets its first listen-party action ever: "Écouter toute la discographie" / "Ajouter la discographie à la file".
Resolved server-side, not via a client-side loop - same reasoning as the existing playlist launch: a discography can be dozens of albums/hundreds of tracks, so this is one atomic operation instead of N sequential requests. New resolveMusicTracksForItem + createMusicPartyFromTracks (index.ts), and a new batch MusicQueueService.addTracks (one broadcast per batch, not per track) that also let the existing playlist-launch code drop its own per-track loop.
New POST /api/parties/:partyId/queue route for adding to an already-live party's queue by itemId (album/artist/track), separate from the existing POST .../tracks (which takes an already-built track object).

Test plan

npm run typecheck / npm test / npm run build on both projects (147/147 server tests)
New coverage for addTracks: batch order preserved, auto-start only on the batch's own first track, exactly one broadcast per batch, no-op for an empty batch
New buttons' layout checked visually against the real compiled CSS (static render)
Not verified: an actual large discography queuing end-to-end against a real server - no Emby login reachable from this sandbox

🤖 Generated with Claude Code

## Summary - `views/album` gets a page-level "Écouter cet album" / "Ajouter l'album à la file" button, alongside the existing per-track ones. - `views/artist` gets its first listen-party action ever: "Écouter toute la discographie" / "Ajouter la discographie à la file". - Resolved **server-side**, not via a client-side loop - same reasoning as the existing playlist launch: a discography can be dozens of albums/hundreds of tracks, so this is one atomic operation instead of N sequential requests. New `resolveMusicTracksForItem` + `createMusicPartyFromTracks` (`index.ts`), and a new batch `MusicQueueService.addTracks` (one broadcast per batch, not per track) that also let the existing playlist-launch code drop its own per-track loop. - New `POST /api/parties/:partyId/queue` route for adding to an *already-live* party's queue by itemId (album/artist/track), separate from the existing `POST .../tracks` (which takes an already-built track object). ## Test plan - [x] `npm run typecheck` / `npm test` / `npm run build` on both projects (147/147 server tests) - [x] New coverage for `addTracks`: batch order preserved, auto-start only on the batch's own first track, exactly one broadcast per batch, no-op for an empty batch - [x] New buttons' layout checked visually against the real compiled CSS (static render) - [ ] Not verified: an actual large discography queuing end-to-end against a real server - no Emby login reachable from this sandbox 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-16 07:46:53 +02:00

Queue a whole album or an artist's entire discography in one action

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

62afa88bb7

Asked for directly: views/album's and views/artist's per-track/
per-album buttons had no whole-album or whole-discography equivalent -
queuing an album meant clicking every track one at a time, and an
artist page had no listen-party action at all beyond drilling into a
specific album.

Resolved server-side, not via a client-side loop - the same choice
already made for playlists, and for the same reason: an artist's
entire discography can genuinely be dozens of albums and hundreds of
tracks, and a client loop of individual add-track calls would mean
that many sequential round trips (slow, and non-atomic) instead of
one. New resolveMusicTracksForItem (index.ts) takes a raw Emby item
already known to be Audio/MusicAlbum/MusicArtist and resolves it to a
flat, ordered track list - a single track, every track in an album (in
Emby's own IndexNumber order), or every album's tracks for an artist's
whole discography (fetched in parallel, in Emby's own chronological
album order). POST /api/parties gained a MusicAlbum/MusicArtist branch
right alongside the existing Playlist one, using this plus a new
shared createMusicPartyFromTracks - which also let
createPartyFromPlaylist's own music branch drop its separate per-track
loop in favor of the same two calls.

MusicQueueService.addTracks is the batch sibling of the existing
addTrack (both now share a buildTrackEntry helper) - same
auto-starts-if-the-queue-was-empty behavior, but one queueUpdated
broadcast for the whole batch rather than one per track, so a
hundred-track discography doesn't spam the party with a hundred
intermediate broadcasts for what's really one user action.

Adding to an already-live party's queue needed its own new route, POST
/api/parties/:partyId/queue - given just an itemId, resolves it the
same way and calls addTracks. Kept separate from the existing
POST .../tracks, which takes an already-built track object a caller
already has in hand (views/album's own per-track buttons) - overloading
that route to guess whether it received a full track or a bare id
would have been more surprising than a second, clearly-named one.

The buttons themselves mirror views/playlist's own "Lancer cette
playlist" - same label-reflects-current-state-and-re-checks-on-click
discipline views/album's per-track buttons already had, same
attach-the-bar-and-stay-put behavior when starting fresh. views/album
gained one page-level button (reusing .playlistActions from
Playlist.css, same "one CSS bundle regardless of which view's file a
rule started in" precedent Album.css already set for .seriesInfo).
views/artist gained its first listen-party action ever, sitting in
.pageHeader itself (its own justify-content: space-between already
puts a second child on the right of the title with no new CSS needed).

Verified: full typecheck/test/build on both projects (147/147 server
tests - new coverage for addTracks: batch order preserved, auto-start
only fires for the batch's own first track when the queue was empty,
exactly one broadcast regardless of batch size, harmless no-op for an
empty batch). resolveMusicTracksForItem/createMusicPartyFromTracks
themselves are index.ts route glue, not independently unit-tested -
consistent with this project's existing boundary that route-level
orchestration isn't, only the services it calls into are. The two new
buttons' layout was checked visually against the real compiled CSS (a
static render, real theme tokens), not eyeballed. Not verified: an
actual large discography queuing correctly end to end against a real
server - no Emby login reachable from this sandbox.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

kyuno merged commit b922e4236f into master

2026-09-16 07:54:14 +02:00

kyuno referenced this pull request from a commit

2026-09-16 07:54:16 +02:00

Merge pull request 'Queue a whole album or an artist's entire discography in one action' (#7) from feature/queue-album-and-discography into master

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kyuno/watchparty#7

No description provided.