Two different items both failed the same way when picking a subtitle -
without knowing whether the second one was also a PGS (image/bitmap)
track like the first confirmed one, that result was ambiguous: still the
same known issue, or something new? Rather than keep digging through
server logs per item, this app can just know the answer itself - Emby's
PlaybackInfo response already includes each subtitle stream's Codec.
- server/src/services/CatalogService.ts: getPlaybackOptions reads it and
reports supportsBurnIn: false for image-based subtitle codecs
(hdmv_pgs_subtitle/dvd_subtitle/dvb_subtitle - IMAGE_SUBTITLE_CODECS).
This app forces SubtitleMethod=Encode whenever a subtitle is picked
(applyPlaybackOverrides), asking ffmpeg's `subtitles` filter (libass)
to burn it in - libass renders text via a font, it has no path for
compositing a pre-rendered bitmap at all, confirmed against a real
server (see docs/architecture.md's Round 4/5).
- server/src/types.ts, client/src/types.ts: PlaybackTrackOption gains
supportsBurnIn (subtitle tracks only, undefined for audio).
- client/src/views/player/Player.ts: the subtitle <select> now disables
these options with a "(image, non disponible)" label instead of
letting anyone pick a track that's guaranteed to break playback -
listed so it's clear why, not silently missing.
- server/test/catalogService.test.ts: new case covering subrip/ass
(supportsBurnIn: true) vs hdmv_pgs_subtitle (false) from the same
MediaStreams response.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reported: the time shown for an ongoing party is the movie's elapsed
time. True, but only by coincidence - the label was actually just
Date.now() - party.createdUtc, which climbs at wall-clock speed
regardless of whether the movie is actually playing. Pause it for five
minutes and the home page keeps counting through the pause the player
itself has frozen.
- server/src/types.ts, client/src/types.ts: LobbyPartyDto gains
positionTicks/isPaused/positionUpdatedUtc - the host's own tracked
playback state (same values SocketGateway already maintains for their
party's own room), null for music parties, where there's no single
"elapsed" across a rotating queue of tracks.
- server/src/realtime/SocketGateway.ts: lobbySnapshot() fills these from
the host's member record for video parties. Two new broadcastLobby()
trigger points to keep it reasonably fresh: an actual pause/play
transition (not every 3s heartbeat resend - same guard already used
for that transition's log line) and advancing the queue (advanceQueue
already reset every member's position for the new item; nothing had
ever pushed that to the lobby before, so a card's title/poster/position
could sit stale until an unrelated join/leave refreshed it).
- client/src/views/home/Home.ts: updateElapsedLabels() now computes a
live, pause-aware position for a video party (frozen while paused,
ticking from position+timestamp while playing) instead of always
falling back to createdUtc - which is still exactly what a music party
(or a party missing these fields) uses.
- server/test/socketGateway.test.ts: two new cases - the lobby snapshot's
video-vs-music shape, and that a transition/next() refreshes it while
an unchanged heartbeat resend doesn't.
Verified against the real bundled client with a faked "parties" push:
a paused party's label held still across a real wait; a playing one, and
a music party on the unchanged createdUtc path, both kept ticking up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- server/test/*.test.ts: formalizes this project's many ad-hoc scratchpad
test scripts into a committed suite, one file per service
(musicQueueService, partyService, socketGateway, catalogService), using
Node's built-in node:test + node:assert/strict - zero new dependencies.
Runs straight against TypeScript source via `tsx --test` (npm test), no
compile step.
- server/tsconfig.test.json: extends the base config, overrides rootDir to
"." and adds test/**/*.ts to include, so `npm run typecheck` covers the
test files too without pulling them into dist/ (npm run build still
uses the unmodified base tsconfig, scoped to src/ only).
- server/package.json: typecheck now runs against tsconfig.test.json; new
test script.
- .forgejo/workflows/publish-docker.yml: new `test` job (node:20-alpine
container - the publish job's docker:27-cli has no Node) running server
typecheck+test and client typecheck+build; publish now depends on it via
needs: test. Removed the stale "no test suite yet" comment.
- README.md, docs/architecture.md: documented the test suite, how to run
it locally, and the new CI job/gating.
Verified locally: server typecheck, server test (25/25 passing), server
build, client typecheck, and client build all pass individually - the
same commands the new CI job runs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
