On a pull_request event github.ref_name is the PR number (e.g. "29"),
not a fetchable ref, so the test job failed at "Récupérer les sources"
on every PR ("couldn't find remote ref 29"). Fetch the PR's head branch
(github.head_ref) instead, falling back to ref_name for pushes/tags.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The "only rewrites the party that changed" test compared a file's
mtimeMs against the exact millisecond passed to utimesSync. Linux
reports mtimeMs as a float that can land a hair off it (...780.999 for
...781), failing CI on master. Compare against the mtime the filesystem
reports right after setting it instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- UI wording: "Watch party" = classic video, "Listen party" = classic
audio, "Lounge party" = static party (tab, page, create buttons,
toasts/confirms, server error messages); code names are unchanged
- home: "Parties en cours" with a Watch party / Listen party badge on
each card
- music launch buttons say "Lancer une listen party"; a failed tile
launch now restores its own label instead of always "watch party"
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- new "Parties permanentes" tab (/static, sidebar + mobile sheet),
highlighted on a party's own page too; the home page no longer lists
static parties, and its live "Watch parties en cours" list leaves
their sessions out
- StaticPartyStore now writes data/static-parties/<id>.json - one file
per party, debounced per party, so a write only touches the party that
changed and a corrupt file only costs that party (moved aside to
.corrupt, the rest still load); leftover .tmp files are cleaned up;
deleting a party removes its file and cancels any pending save
- the first release's single static-parties.json is migrated once on
load, then kept as .migrated
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A watch party built from a whole series or video playlist that remembers
the group's progress and each member's, so someone coming back or joining
late sees the items they missed and can catch up (solo, as a catch-up
watch party, or by marking items watched).
- StaticPartyService + StaticPartyStore: first on-disk state (JSON file
under DATA_DIR, atomic debounced writes, flushed on SIGTERM)
- each session is an ordinary Party linked via party.staticLink; group
position is saved by the 20s sweep and resumed on the next session
- PartyService.completeCurrentItem centralizes "item done" (Emby Played +
static progress); new host-only "itemEnded" socket event covers the
last queued item, which was never marked Played before
- missed = group-completed minus watched in-app minus Emby Played
- /static/:id view, create buttons on series/playlist pages, home section
- Docker volume for /data, spec/static-watch-party.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A joining member's player always called loadVideo(itemId, 0, false),
hardcoding a resume position of 0. Since a party's Emby stream is one
shared transcode session (PartyStreamService, keyed by partyId alone),
a newcomer's hls.js requesting segments from position 0 against a
session that already progressed well past that forces Emby to
seek/restart the shared transcode - stalling playback for every
member, host included, right as the newcomer joins.
Seed the initial resume position from the host's last-reported
position (already available in party.members) instead, so the first
segment request lands near where the shared session already is.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The album art was sized off min(220px, 60vw) - the viewport dimension
a phone in landscape has plenty of - and stayed pinned near that cap
regardless of how little vertical room was actually left once
everything stacked vertically (art, text, transport, side), running
well past a typical landscape height and needing to scroll to reach
the controls.
Added a dedicated media query for max-width 720px and orientation
landscape rather than chasing every fixed value in the portrait rules:
the art now sits beside the title/artist instead of above them
(flex-direction: row), freeing most of the vertical space the
portrait layout spends stacking them, and its size is capped by vh
instead of vw - the dimension landscape actually constrains. A few
margins shrink alongside it in the same block for the same reason.
Deliberately left the transport buttons fixed-size - a touch target
answers to a finger, not the screen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
imageUrlFors own Audio -> AlbumId fallback was silently never
triggering for a track played directly (not via its album/artist),
because the raw item that decision runs against - CatalogService
getRawItem - never requested AlbumId from Emby. Its default field set
for a single-item GET omits it entirely, so item.AlbumId read
undefined regardless of whether the tracks actual album had one -
falling through to the tracks own id every time, which essentially
never has a Primary image of its own. Every other path that resolves a
tracks image already asks for AlbumId correctly (getAlbumTracks/
getPlaylistItemsRaw), which is why launching a whole album/artist/
playlist was never affected. Fixed the one gap: getRawItem now
requests Fields=AlbumId too.
Flagged directly as probably not the whole images-are-hard-to-find
story - a real Emby library can also legitimately have no Primary
image at all for a given artist/album, which is not a bug this app can
fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two gaps around an already-correct takeover mechanism, not the
mechanism itself. First: Player.ts/MusicBar.ts both wired onClose to a
no-op, so the moment a takeover force-disconnected the old device its
video/hls.js instance (or the persistent music bar) just kept running
forever on a dead connection - both devices looked fully active, since
nothing ever told the old one to stop or navigate away. Second: the
obvious fix (call the same leave path Quitter uses) ran into a worse
bug - POST /leave removes a member by userId alone with no staleness
guard, so the old devices own leave call would have ended the NEW
devices membership too. Fixed both: onClose now tears down local
playback and leaves whenever this routes own explicit teardown has not
already run, and the leave route (plus the client, which now sends its
own deviceId) gained the same staleness guard the socket handlers
already had, via a new PartyService.isStaleDevice.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New mediaSession.ts wraps the standard Media Session API - shared by
Player.ts and MusicBar.ts, which can never both be active at once so
there is no risk of them fighting over this one global. Metadata/
position/playback-state hook into each players own existing single
source of truth (updatePlayPauseBtn/updateProgressBar, setPlayIcon/
updatePositionDisplay) instead of adding parallel call sites. Play/
pause/seek are wired once and read isHost/conn fresh on every
OS-triggered call, so they keep working through a live host handoff;
a non-host play/pause routes through the same requestPause/
requestResume the request toolbar already uses, and seek is gated on
isHost the same way the in-page seek bar already is. Next is handled
separately since a registered nexttrack handler is what makes the OS
show that control at all - its presence tracks whatever the in-page
equivalent already tracks (isHost && hasNextQueued for video, a vote
skip for music). Cleared entirely on leaving a party/page, or just to
idle (metadata/state only) when a listen partys queue runs empty but
the party itself is still open.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The PWA already existed but nothing told a mobile visitor it could be
installed - Chrome own default mini-infobar is easy to miss, and
Safari has no browser-driven prompt at all. New pwaInstall.ts (self-
mounting like toast.ts) captures beforeinstallprompt as early as
possible (a top-level side effect of importing the module from
Shell.ts, live before boot() even starts its async login check, since
that event never replays for a listener that attached too late) and
shows a banner with a real Installer button on Chrome/Edge/Android, or
manual Share-then-home-screen instructions on iOS Safari where no such
event exists at all. Mobile-only, suppressed once already running
standalone, and a close click remembers not to ask again.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
trackList.css forced .trackRow down to 2 columns under 600px and
pinned duration + the icon button both to column 2 - auto-placement
then stacked them into their own rows under the track name instead of
staying on one line. The fixed overhead (index/gaps/padding/an
auto-sized duration and button) comes to roughly 155-165px, and even a
320px-wide phone leaves comfortably more than that for the flexible
name column - .trackName already ellipsizes, so the breakpoint was
solving a problem that did not exist. Removed outright.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
trackProgress is musicBarPanel own first child inside a 3-column grid
(track/transport/side), with no grid-column of its own - auto-placement
dropped it into column 1 of row 1 like any other item, squeezing it to
that columns width and wrapping musicBarPanelSide onto a second row
underneath instead of spanning the full bar with everything else in
one row below, as its own comment already said it should. Fixed with
grid-column: 1 / -1, which pushes every sibling after it into row 2
across the full width with no changes needed to any of them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.libraryHeader and the alphabet index's .letterHeading copied their
z-index: 2 from tiles.css's own pre-existing sticky .searchBar - which
never showed the problem in practice, since a single slim input has
little room to actually overlap a scrolling tile. A tile's own
.tileOverlay action buttons are also z-index: 2 though, and an equal
z-index ties toward whichever renders later in the DOM - a tile, always
after the header. Wrapping the header into a much taller block gave a
scrolling tile far more room to pass underneath before fully clearing
it, which is what actually surfaced the tie. Raised both to z-index: 3,
matching shell/Shell.css's own mobileTopBar.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.musicBarQueue never actually had a position set on desktop despite its
own comment saying it should float above the bar - toggling it visible
just pushed the real controls out of the way instead, growing the
fixed bottom bar upward. Mobile had position: relative with a high
z-index to at least show above the full-screen now-playing panel, but
that left it sized/placed by normal flow, overlapping the very toggle
button used to open it with no other way to close it.
Now: musicBar gets position: relative, desktop musicBarQueue floats
via position: absolute; bottom: 100% without touching the bar's own
layout, and mobile gets a proper position: fixed; inset: 0 overlay.
Also added a dedicated close button plus a click-outside-closes
listener, so closing it never again depends on where the toggle button
happens to render underneath.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Emby orders (and this app already asked it to) by SortName, which
strips leading articles - an item like The Bunker sorts among the Bs
there, but the index was bucketing by the raw display name, throwing a
spurious T heading into the middle of that run. getLibraryItems/
getArtists now also fetch SortName, ItemDto carries it through, and the
index buckets by that instead - the same key Emby actually used to
order the array, not a guess that usually matches it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Groups an already-alphabetical library into per-letter sections (accents
folded, so an item is bucketed under its base letter) with a sticky
heading before each - still one chunked-rendered grid, not a big
synchronous write, so a 1000+-item library stays smooth. The right-edge
rail jumps to a letter on tap or drag (pointer-capture, same shape as
the mobile nav sheet's own drag handle), dims letters with nothing in
them, and tracks the header/music-bar's real height instead of a
guessed offset so it never sits under either.
Stacked on feature/library-sticky-header (Library.css's .libraryHeader,
not yet merged) rather than master, per CLAUDE.md's sequential-PRs rule.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The search bar was already sticky on its own; the title above it
still scrolled away. Wraps both in one sticky .libraryHeader block,
scoped to views/library only, and stacks it below the mobile shell's
own sticky top bar instead of racing it for the same spot.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reported directly: the only way to close the bottom sheet was tapping
the scrim, and the instinctive swipe-it-down gesture fell straight
through to the browser's own pull-to-refresh instead - nothing was
telling the browser this app's own code owned that gesture.
touch-action: none on the scrim and the (now real, not just visual)
grabber handle stops the browser's default touch handling from
kicking in there at all; overscroll-behavior: contain on the sheet
itself stops a drag that hits its own scroll boundary (the library
grid can run taller than the sheet's 75vh cap) from chaining to the
page underneath. The grabber's small 36x4px pill now sits inside a
much bigger invisible touch target that actually drags the sheet
(pointerdown/move/up, 1:1 tracking, snap back under 90px or close past
it) - scoped to the grabber alone, not the whole sheet, so the
library grid's own taps/scroll keep working untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every message this app ever showed the client - the host-handoff
notice, every "couldn't start/join a party" error - went through a
blocking alert(), freezing the tab for what's usually just a heads-up.
New toast.ts is a self-mounting singleton (no per-party state, so it
doesn't need Shell.ts wiring like musicBar/MusicBar does) styled after
Player.css's own .requestBanner, with an 'error' variant that's still
just a plain left accent, not a red banner - even a failed click
doesn't need this app to suddenly shout. All ten alert() call sites
across Player/MusicBar/tiles/Home/Series/Playlist/Artist/Album now go
through it.
Also fixes a real reported bug while in the area: the library/artist
grid's minmax(160px, 1fr) floor left no room for a second column once
a real phone's padding was subtracted, unlike everything else mobile
in this app (the sidebar, the music bar) which already got a
narrow-screen treatment. Switched to a fluid clamp(100px, 28vw, 160px)
floor instead of a fixed breakpoint, confirmed at seven real widths via
an iframe (its own independent viewport for vw units, sidestepping
this sandbox's own unreliable viewport-resize emulation).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The music library reused the movie-poster tile (2:3, hover-revealed
actions) for artists and albums too, since it was already there for
video - functional, but never reads as "this is music" the way real
apps do. Explored as mockups first, then implemented without touching
any of MusicBar's existing sync/cast/HLS logic:
- tiles.ts's tileHtml() now dispatches on Emby type: artists get a
circle with no hover overlay, albums a square - same "whole tile is
the one link" idea, since there's only ever one action either way.
- Artist/album pages gain a real hero header (circular/square art, a
pill-shaped play button) instead of a plain title + text button.
Album's per-track buttons shrink from a wide text button repeated on
every row to a small icon that swaps play/plus with the same two
states as before.
- MusicBar gains a real mobile "now playing" full-screen view (tap the
collapsed mini bar to expand it) instead of only ever being a thin
strip - the screen every music app has that this one was missing.
The existing thin top-edge progress bar didn't change shape at all,
on either breakpoint.
Nothing here invents a feature without a real data source behind it -
no popular tracks, no previous-track, no favorites, none of that
exists server-side.
Caught and fixed one real bug via computed-style verification, not
just reading the CSS back: the new circular play button was silently
losing to .iconBtn's own background/radius at equal specificity,
outcome depending on esbuild's bundle order rather than either rule's
own declared intent.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
