Asked for directly: Emby's admin "now playing" dashboard should see
this app's streams the same way it sees a real web/mobile/TV client's.
This is exactly the follow-up "Sync watch-party progress back to Emby"
already anticipated and deliberately deferred at the time ("wiring
clean start/stop into every transition... is real complexity for a
secondary payoff") - that section also explains why this app abandoned
Emby's session-shaped PlayingItems endpoints entirely in favor of
direct UserData writes. Given that history (two separate rounds of a
wrong-but-schema-plausible request shape for that other, now-abandoned
endpoint family), this one was built checking the real API first
rather than assuming.
Confirmed against the real server's own /openapi.json that the actual
session-lifecycle family is POST /Sessions/Playing (start),
/Sessions/Playing/Progress, and /Sessions/Playing/Stopped - distinct
from PlayingItems. None of the three schemas declare a required list
at all, which - given the neighboring history - was read as "don't
trust that": ItemId/MediaSourceId/PlaySessionId/PositionTicks are sent
on every call anyway, matching what a real client obviously would,
rather than risking a repeat of "technically matches the schema, still
400s".
One real Emby session per PARTY MEMBER, not one per party - a faithful
copy of how a real client behaves, and the actual point of "let admin
see who's watching what" would be lost by collapsing everyone onto one
shared entry. New server/src/services/EmbySessionService.ts mirrors
PlaystateService's own best-effort shape (every failure caught and
logged, never thrown) but stays its own class - PlaystateService's own
opening comment is specifically about why it doesn't use a
session-shaped endpoint, so folding this into it would muddy that
exact distinction.
Getting a MediaSourceId/PlaySessionId per member needed a new
CatalogService.negotiatePlaybackSession - a fresh PlaybackInfo
negotiation under that specific member's own account, since Emby scopes
PlaybackInfo per user and PartyStreamService's existing shared
negotiation is never guaranteed valid for reporting under everyone
else's account too. Returns null on any failure rather than throwing -
this only ever feeds an admin-dashboard nicety, never something that
should disrupt real playback.
Driven entirely from index.ts's existing periodic sweep rather than new
hooks scattered across every queue-advance/track-skip call site -
that sweep already visits every connected member on every ~20s tick,
already positioned to notice a member's current item no longer matches
their cached session and react (stop the old one if any, negotiate
fresh ids, start the new one; same item as last tick just sends
Progress with the cached ids). PartyMember gained the nullable
embySession field this tracks. Explicit stop calls also happen at
PartyService.leave() (alongside the existing CastTokenService
.revokeForMember) and removeIdleParties (a backstop for a disconnect
that never triggered a clean leave).
Verified: full typecheck/test/build (134/134 server tests - new
coverage for negotiatePlaybackSession's null-on-any-failure contract,
every EmbySessionService method's exact request shape, that a non-ok
response/thrown error is swallowed not propagated, and that leave()
calls stop with a member's real cached session info but only when they
actually had one open). Not verified: an actual live write against the
real server - deliberately not attempted, since that would mean using
a real account's Emby token for a genuine state-changing call, beyond
the read-only diagnostic use this session's shared API key was ever
meant for. So while the request shape is checked against the real
schema and the per-member logic is unit-tested in full, whether Emby's
dashboard actually displays these sessions the way a native client's
would - correct device/client labeling in particular, since this app
never sends the X-Emby-Authorization Device/Client/Version header a
real client would, only X-Emby-Token - is genuinely unconfirmed. Worth
watching the real dashboard the first time a party runs after this ships.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
86 lines
4.1 KiB
TypeScript
86 lines
4.1 KiB
TypeScript
'use strict';
|
|
|
|
/**
|
|
* Minimal server-side logging - plain stdout lines, no logging library.
|
|
* This app runs as a single Docker container watched via `docker logs`/
|
|
* journalctl (see README's Deploying section), not behind a log
|
|
* aggregator, so a consistent prefix + timestamp is what actually makes
|
|
* these greppable in practice, not structured JSON nobody's parsing.
|
|
*
|
|
* Static methods rather than a singleton instance: there's no state here
|
|
* at all (unlike PartyService/MusicQueueService, which really do own
|
|
* something) - a class is just a namespace for these two, kept as a class
|
|
* for consistency with the rest of server/src/services' shape.
|
|
*/
|
|
export class Logger {
|
|
/**
|
|
* Party business-lifecycle events - created/joined/left/destroyed, host
|
|
* handoff, queue advance, playstate transitions, pause/skip requests.
|
|
* Deliberately covers only that, not connection-level noise like every
|
|
* Socket.IO reconnect or the 3s playstate heartbeat re-sending the same
|
|
* state (see SocketGateway, which only calls this on an actual
|
|
* play/pause transition, not every heartbeat tick).
|
|
*/
|
|
static party(message: string): void {
|
|
console.log(`[watchparty:party] ${new Date().toISOString()} ${message}`);
|
|
}
|
|
|
|
/**
|
|
* The streaming route specifically (CatalogService's /master.m3u8
|
|
* handler) - a different concern from the party lifecycle above (it's
|
|
* about one HTTP request, not party state). Deliberately logs only the
|
|
* individual override values it cares about, never the full resolved
|
|
* URL or params blob - Emby's own TranscodingUrl can carry an api_key,
|
|
* and that has no business ending up in a log file.
|
|
*/
|
|
static stream(message: string): void {
|
|
console.log(`[watchparty:stream] ${new Date().toISOString()} ${message}`);
|
|
}
|
|
|
|
/** `"name(id)"` - the same shape in every party lifecycle log line. */
|
|
static who(userId: string, userName: string): string {
|
|
return `${userName}(${userId})`;
|
|
}
|
|
|
|
/**
|
|
* Emby answering anything but success, to any proxied call - see
|
|
* EmbyClient.fetch, the one place every Emby request goes through.
|
|
* Added after several rounds of chasing a real error message through
|
|
* browser devtools and Emby's own live log view (see docs/architecture.md's
|
|
* player-track-selection section): Emby often sends back a real,
|
|
* detailed text body on a failure, which neither of those reliably
|
|
* surfaced - this puts it directly in `docker logs` instead, from now on.
|
|
*/
|
|
static emby(message: string): void {
|
|
console.log(`[watchparty:emby] ${new Date().toISOString()} ${message}`);
|
|
}
|
|
|
|
/**
|
|
* TranscodeService's own ffmpeg processes (start/end, and any stderr
|
|
* captured from a process that exits before producing its first
|
|
* segment) - see docs/architecture.md's "Self-hosted ffmpeg" section.
|
|
* Same reasoning as `emby` above: a failure needs to be visible in
|
|
* `docker logs` immediately, not just a stuck spinner in the browser.
|
|
*/
|
|
static transcode(message: string): void {
|
|
console.log(`[watchparty:transcode] ${new Date().toISOString()} ${message}`);
|
|
}
|
|
|
|
/** Every per-member background write this app makes to Emby under
|
|
* someone's own account - the party watch-state sync (index.ts's
|
|
* periodic sweep, and PartyService.advanceQueue/MusicQueueService
|
|
* .playNext's own item-transition calls - see PlaystateService), and
|
|
* the parallel Sessions-API lifecycle reported alongside it (see
|
|
* EmbySessionService). Logs every outgoing request (method + path,
|
|
* and the POST body for the UserData write) and its outcome, not
|
|
* just failures: this is a best-effort background sync with nothing
|
|
* else watching it, so `docker logs | grep watchparty:playstate`
|
|
* needs to be enough on its own to see exactly what was sent and
|
|
* whether Emby accepted it, without cross-referencing `emby` above.
|
|
* Safe to log in full here (unlike `stream` above) - the real
|
|
* embyToken travels as a header, never logged, and both services'
|
|
* own tests confirm it never leaks into these lines. */
|
|
static playstate(message: string): void {
|
|
console.log(`[watchparty:playstate] ${new Date().toISOString()} ${message}`);
|
|
}
|
|
}
|