Fix host stream freeze when a guest joins an in-progress party #26

Merged

kyuno merged 1 commit from fix/guest-join-freezes-host-stream into master

2026-09-23 20:34:13 +02:00

kyuno commented

2026-09-23 18:54:25 +02:00

Owner

Bug

Quand une personne rejoignait une watch party en cours, le flux de l'hôte freezait.

Cause

Le player d'un membre qui vient de monter appelait toujours loadVideo(itemId, 0, false), avec une position de reprise codée en dur à 0 (Player.ts:1263 avant correctif).

Or une party n'a qu'une seule session de transcodage Emby, partagée par tous les membres (PartyStreamService, indexée par party.id uniquement — voir docs/architecture.md, section "One shared Emby stream per party"). Quand le nouvel arrivant demande des segments à la position 0 alors que la session partagée a déjà bien avancé, Emby traite ça comme un seek arrière et relance le transcodage depuis 0 — ce qui coupe le flux que l'hôte est en train de consommer sur cette même session.

Correctif

Le point de montage du player initialise désormais la position de reprise à partir de la dernière position connue de l'hôte (party.members, déjà envoyée à chaque montage) au lieu de 0. La première requête de segment atterrit donc près d'où en est réellement la session partagée, au lieu de forcer un rembobinage complet.

Test

npm run typecheck (client) : OK
npm run build (client) : OK
Pas de test manuel multi-client (nécessite un vrai serveur Emby + plusieurs sessions) — à valider en conditions réelles.

🤖 Generated with Claude Code

## Bug Quand une personne rejoignait une watch party en cours, le flux de l'hôte freezait. ## Cause Le player d'un membre qui vient de monter appelait toujours `loadVideo(itemId, 0, false)`, avec une position de reprise codée en dur à `0` ([Player.ts:1263](client/src/views/player/Player.ts:1263) avant correctif). Or une party n'a qu'**une seule session de transcodage Emby, partagée par tous les membres** (`PartyStreamService`, indexée par `party.id` uniquement — voir `docs/architecture.md`, section "One shared Emby stream per party"). Quand le nouvel arrivant demande des segments à la position 0 alors que la session partagée a déjà bien avancé, Emby traite ça comme un seek arrière et relance le transcodage depuis 0 — ce qui coupe le flux que l'hôte est en train de consommer sur cette même session. ## Correctif Le point de montage du player initialise désormais la position de reprise à partir de la dernière position connue de l'hôte (`party.members`, déjà envoyée à chaque montage) au lieu de `0`. La première requête de segment atterrit donc près d'où en est réellement la session partagée, au lieu de forcer un rembobinage complet. ## Test - `npm run typecheck` (client) : OK - `npm run build` (client) : OK - Pas de test manuel multi-client (nécessite un vrai serveur Emby + plusieurs sessions) — à valider en conditions réelles. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-23 18:54:25 +02:00

Fix host stream freeze when a guest joins an in-progress party

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

7fbf22419d

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>