Every attempt to see Emby's actual error message by hand failed the same
way: hls.js's own error reporting only ever exposes the generic HTTP
reason phrase, never the real response body, and Emby's own live log
view didn't reliably surface the exception's headline message either -
across several different items and failure modes this session. Emby's
own access log confirmed a real, several-KB text body really was being
sent every time (Content-Type: text/plain, Content-Length: 5190) - it
just never survived being reported back through either of those paths.
Fixed at the root: EmbyClient.fetch - the one function every Emby call in
this app goes through (fetchJson's JSON API calls and proxyResponse's
streaming/image proxy alike) - now logs Emby's status and full response
body itself straight to docker logs whenever a call fails.
- server/src/emby/EmbyClient.ts: new private logErrorResponse, called
from fetch() only when !res.ok. Reads the body via .clone() so the real
caller still gets an untouched, fully readable response (a body can
only be consumed once, and this had to not break either of the two very
different ways this app's callers read one - fetchJson's .json(),
proxyResponse's .text()/pipe). pathAndQuery is logged with api_key
redacted - this can be called with Emby's own TranscodingUrl verbatim,
which can carry one (same concern as CatalogService's logStreamRequest).
- server/src/Logger.ts: new emby() method, same shape as party()/stream().
- server/test/embyClient.test.ts (new): body/status logged and readable
by the real caller afterward, api_key redaction, and silence on a
successful response (only failures are worth logging, same discipline
as this app's existing logging).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
