appRobotWebcam/doc/09_Bug_reports.md

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.