58 lines
2.3 KiB
Markdown
58 lines
2.3 KiB
Markdown
## 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. |