Emby Server plugin: watch party feature (session sync via Emby's remote-control commands) + companion web control panel
Find a file
Nicolas 4b2d4822ef
All checks were successful
Publier l'image Docker / publish (push) Successful in 14s
Fix language/subtitle selection: force our pick onto Emby's negotiation
Bug report: picking an audio language or subtitle track in the player's
settings menu had no effect. First real-world bug reachable only once
streaming itself was already confirmed working end to end (this is that
confirmation, per docs/architecture.md).

Root cause, reasoned from how Emby's API actually works (no way to verify
directly - see below): real Emby web clients negotiate track selection via
a POST /Items/{id}/PlaybackInfo body with a DeviceProfile; this app only
ever sent AudioStreamIndex/SubtitleStreamIndex as bare GET query params,
which PlaybackInfo's negotiation likely doesn't apply the same way -  so
the TranscodingUrl it returned just reflected Emby's own default track,
regardless of what was actually requested. Separately, even a correctly
selected subtitle has a second silent-failure path: Emby can deliver text
subtitles burned into the video (SubtitleMethod=Encode) or as their own
selectable HLS rendition (SubtitleMethod=Hls) - this player's hls.js setup
never wires up subtitleTrack/subtitleTracks, so a Hls-method subtitle would
sit in the manifest unused.

server/src/index.js: new applyPlaybackOverrides forces
AudioStreamIndex/SubtitleStreamIndex/MaxStreamingBitrate onto whichever URL
the /master.m3u8 route ends up with - Emby's own TranscodingUrl, or the
hand-built fallback (which, before this fix, dropped these three params
entirely - a second, independent way the same symptom could happen).
Picking a subtitle also forces SubtitleMethod=Encode; picking "Aucun"
deletes both SubtitleStreamIndex and SubtitleMethod rather than just not
adding one, so it also cancels a subtitle Emby's negotiation had defaulted
to on its own. The negotiation call no longer needs to be trusted to apply
these params - it only needs to return a playable MediaSource, since every
control this app's UI exposes gets forced afterward regardless.

Verified as far as possible without real Emby access:
applyPlaybackOverrides is pure URLSearchParams manipulation, unit-tested in
isolation (adding a subtitle, removing one Emby had defaulted to,
re-sending an unchanged selection across an audio-only change, quality
override, the no-selection-yet initial load) - all pass. Confirmed
client-side too, by mocking Hls to capture what loadSource was actually
called with: initial load sends the default track's index, each dropdown
change re-sends a full reload with exactly the accumulated params expected.
What's not verified is the real Emby round trip - that needs a live
retest, which this environment has no credentials to do.

docs/architecture.md has the full writeup, and its "Assumptions to verify"
section got a broader pass while in there: several items long-flagged as
"not yet exercised against the real server" are now implicitly confirmed
by everything that's worked in real usage so far (response field names,
auth headers, playlist rewriting, basic HLS playback) - narrowed the list
down to what's genuinely still unconfirmed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 00:35:22 +02:00
.forgejo/workflows Add Forgejo Actions pipeline to build/publish the Docker image 2026-09-13 20:59:55 +02:00
.github/workflows Scaffold Emby Watch Party plugin 2026-09-13 14:02:43 +02:00
client Move presence overlay to the top, orange badge for pause requests, series detail page 2026-09-14 00:22:07 +02:00
docs Fix language/subtitle selection: force our pick onto Emby's negotiation 2026-09-14 00:35:22 +02:00
server Fix language/subtitle selection: force our pick onto Emby's negotiation 2026-09-14 00:35:22 +02:00
src/WatchParty Fix the real crash: partyPage.html was missing data-controller 2026-09-13 20:17:14 +02:00
.gitignore Untrack .claude/ (local tooling config, not project source) 2026-09-13 20:53:31 +02:00
docker-compose.yml Pivot to a standalone app - Emby plugin hit a hard wall 2026-09-13 20:48:55 +02:00
LICENSE Scaffold Emby Watch Party plugin 2026-09-13 14:02:43 +02:00
README.md Presence overlay (avatars) + "request pause" in the player 2026-09-14 00:05:40 +02:00

Watch Party for Emby

A standalone web app for watching the same title, in sync, with other users of the same Emby server. It reads your Emby catalog and streams your Emby media, but it's its own app with its own player — not an Emby plugin.

See docs/architecture.md for the full design, including why this replaced an earlier Emby-plugin attempt (still in src/WatchParty/ for reference — see below).

How it works

  1. Sign in with your Emby account (just username/password — the server address is fixed server-side, see Deploying below).
  2. A sidebar lists your Emby libraries; the home page shows every ongoing watch party live (host, how long it's been running, member count) plus a "recently added" row per library, Emby-style. No join codes — if a party is running, it's already on the list, updating in real time.
  3. Pick a movie/episode tile and hit "Lancer une watch party" (or drill into a Series' seasons/episodes first) — you become the host — or hit "Rejoindre" on any party already listed on the home page.
  4. The host's play/pause/seek drives everyone else's player automatically; starting from an episode queues the rest of the series so the host can just hit "Épisode suivant" instead of restarting a party each time. If the host leaves, the party hands off to another member automatically (their player unlocks live, no reload needed) — only closing once everyone's gone.
  5. Everyone present shows up as a small avatar overlay on the video (their initials, on the player itself). If you're not the host, clicking your own avatar asks the host to pause — everyone sees the request, including the host, without needing chat.

Everything — catalog, images, video, sync — flows through this app's own backend, which proxies whatever it needs from Emby server-side. The browser never talks to Emby directly and never holds an Emby access token; it only ever has a session cookie for this app.

Music isn't part of this yet — it needs its own player and a collaborative playlist, different enough to be its own pass. The sidebar already lists a Music library if you have one; the page just says so for now.

Status

Login, and the rendering/navigation logic for the sidebar/home/library/series pages, have been exercised end to end (login against the real Emby server with intentionally-wrong credentials; the pages against mocked API responses). See docs/architecture.md for exactly what that does and doesn't confirm — the real Emby response shapes this now depends on (library CollectionType, seasons/episodes, PlaybackInfo's media streams) and actual HLS playback are still unverified.

Project layout

server/           Node.js backend: proxies ALL Emby access (auth, catalog,
                  images, HLS streaming) and coordinates party/room state +
                  realtime sync. The browser only ever talks to this.
  src/index.js       Express app + REST endpoints
  src/embyAuth.js    server-side login against Emby + session cookies
  src/embyProxy.js   generic Emby request/response proxying (incl. HLS)
  src/socketHandler.js  Socket.IO protocol (see comments in the file)
  src/partyManager.js  in-memory room state

client/           Static frontend (plain JS, ES modules, no build step).
                  Talks only to server/ - never to Emby directly.
  js/shell.js        persistent sidebar + #mainContent the router swaps
  js/tiles.js        poster-tile rendering shared by home.js and library.js
  js/embyApi.js      calls our own /api/* routes (auth, catalog, playback options)
  js/party.js        our own backend's party REST + Socket.IO client
  js/views/          one file per screen: login, home, library, series, player

src/WatchParty/   The earlier Emby-plugin attempt. Builds fine and installs,
                  but Emby has no supported extension point for a player
                  button, and even menu integration required reverse-
                  engineering undocumented internals - see
                  docs/architecture.md for the full story. Kept for
                  reference; not the active direction.

docs/architecture.md   full design doc for the standalone app

Running locally

cd server
npm install
EMBY_SERVER_URL=https://your-emby-server npm start

Then open http://localhost:3000.

Deploying

Build the Docker image from the repo root (it needs both server/ and client/):

docker build -f server/Dockerfile -t watchparty .
docker run -d --name watchparty -p 3000:3000 -e EMBY_SERVER_URL=https://theater.media.kyuno.fr watchparty

Then put it behind your existing reverse proxy like everything else (theater.media.kyuno.fr, git.dev.kyuno.fr, ...), e.g. watchparty.kyuno.fr → http://<container>:3000.

Roadmap

  • Design + scaffold the standalone app
  • Proxy all Emby access server-side; Emby-themed UI (sidebar, carousels)
  • TV show navigation (Series → Seasons → Episodes) + episode auto-queue
  • Player language/subtitle/quality pickers
  • Socket.IO instead of raw WebSockets; fixed two real memory leaks (dead-connection cleanup server-side, view teardown on navigation client-side) — see docs/architecture.md
  • Live "watch parties en cours" list (host, elapsed time, member count), live host handoff, no join codes
  • Presence overlay (avatars) + "request pause" in the player
  • Try a full party end-to-end with two real accounts (still the main gap)
  • Music: dedicated player, artist/album browsing, collaborative playlist
  • Tune transcoding target / support direct play when possible

No chat, no OIDC — deliberately out of scope (Emby-only auth was the explicit choice; see docs/architecture.md).

License

MIT — see LICENSE.