## Multi-User ##

Wenn zwei (oder mehr) User streamen, dann kann kein High-Res Bild mehr
gemacht werden. Das Problem: Der Stream bleibt irgendwo aufrecht erhalten.


Fix-Vorschlag Option 1: Alle Browser erhalten bei einem High-Res Request
die Anweisung, den Stream abzumelden.

Fix-Vorschlag Option 2: Der Stream wird umgeleitet zu einer Zwischenstelle "Schalter" und erst von dort aus an die Browser verteilt. Dann wird die
"unterbrechung" bzw. "umleitung" des Streams serverseitig erledigt.




## BugReport 106% ##

Anmelden abmelden funktioniert. Es bleibt bei 35% Prozessor-Last

Anmelden Screenshot funktioniert. Es bleibt bei 35% Prozessor-Last

Anmelden Screenshot neu anmelden > Es gibt 108% Prozessor-Last und ein Stream friert ein.


Wenn ich den Container restarte, funktioniert es. 

siehe auch doc/04_Delay_roadmap.md sowie doc/05_screenshot_roadmap.md

### Root Cause (2026-06-05)

**Race condition:** `cam_hires` und `cam` belegen kurz gleichzeitig dasselbe `/dev/videoN`.

```
1. stopStream(cam0)     → 0 Consumer → go2rtc stoppt cam0-FFmpeg → /dev/video0 frei
2. Server: frame.jpeg   → go2rtc startet cam0_hires-FFmpeg auf /dev/video0 (1280×960)
3. Response fertig      → go2rtc sendet SIGTERM an cam0_hires-FFmpeg
4. Server antwortet Client (OHNE auf FFmpeg-Exit zu warten!) ← Fehler
5. Client sleep(600ms) → startStream(cam0) → go2rtc startet cam0-FFmpeg auf /dev/video0
   ⚠ cam0_hires-FFmpeg hält /dev/video0 noch offen → 2 FFmpeg auf 1 Device → 108%
```

Der Konflikt in Schritt 5 versetzt `cam0_hires` in einen Fehlerzustand in go2rtc.
Beim nächsten Reconnect ("neu anmelden") startet go2rtc's Retry `cam0_hires` erneut —
gleichzeitig mit `cam0` → wieder 108% + Stream friert ein.

### Fix (umgesetzt in src/snapshotService.js)

Server wartet nach dem frame.jpeg-Fetch, bis `cam_hires`-Producer in go2rtc wirklich
gestoppt ist (`pRunning=false`, `nConsumers=0`), plus 400ms Puffer für den FFmpeg-Exit.
Erst dann geht die Antwort zum Client → `/dev/videoN` ist garantiert frei wenn
`startStream(cam)` startet.

### Noch offen: Multi-User (siehe Abschnitt oben)

Das Multi-User-Problem bleibt. Bei ≥2 aktiven Clients kann `/hires` nicht starten,
weil der `/hires`-Endpoint wartet bis `cam` 0 Consumer hat (max 8s), aber ein
zweiter Browser die Consumer-Zahl nie auf 0 sinken lässt → Timeout → 503.
Fix-Optionen: siehe Multi-User-Abschnitt oben.