Umbau mit cameraSwitch Dokumentation

doc/09_Bug_reports.md

@@ -1,5 +1,11 @@
 ## Multi-User ##
 
+> ✅ **GELÖST (2026-06-05) durch den Node-MJPEG-Schalter.** Genau die „Schalter"-Idee aus
+> Option 2 wurde umgesetzt: ein FFmpeg pro Gerät, der Server verteilt an alle Browser
+> (Fan-out). Clients halten kein Gerät mehr → HD-Grab pausiert nur kurz die eine Quelle,
+> unabhängig von der Client-Zahl. Details: `05_screenShot_roadmap.md`. (Beschreibung unten
+> = ursprünglicher Bug-Report.)
+
 Wenn zwei (oder mehr) User streamen, dann kann kein High-Res Bild mehr
 gemacht werden. Das Problem: Der Stream bleibt irgendwo aufrecht erhalten.
 
@@ -124,4 +130,23 @@ kein Transcode. Fallback `mjpeg` = Re-Encode mjpeg→mjpeg (~50%, wie go2rtc).
    → als Default `copybsf` verdrahtet, `mjpeg` bleibt als Fallback (`ENCODE_MODE`).
 
 Lehre erneut: **erst die Doku-Fakten anwenden, dann bauen** — und Optimierungen **messen**
-(Punkt 3), nicht vorhersagen.
+(Punkt 3), nicht vorhersagen.
+
+---
+
+## Stream-Freeze (Einzelfall) — offen, niedrige Priorität
+
+**Beobachtet 2026-06-05:** Ein Live-Stream ist **einmal** eingefroren (Bild stand still,
+während die Last normal blieb). Vom User als akzeptabel eingestuft, später anschauen.
+
+**Verdachtsmomente (zu prüfen, wenn es erneut auftritt):**
+- Die multipart-Verbindung des `<img>` brach ab (z. B. ein fehlgeschlagener `res.write`
+  → `cleanup()` meldet den Verbraucher ab), **ohne** dass der Browser von selbst neu
+  verbindet. Der `<img>`-`error`-Handler in `viewer.js` reconnectet nur bei einem echten
+  `error`-Event — ein „eingefrorenes" Bild ohne Fehler-Event fällt durch.
+- Ein einzelnes korruptes JPEG aus dem Kamera-MJPEG (die `APP fields`-Warnung), das der
+  Browser nicht rendert und danach hängt.
+
+**Möglicher Fix (wenn relevant):** clientseitiger Watchdog — Frames/Zeit zählen
+(`img.onload`-Takt); kommt N Sekunden kein neues Bild, `img.src` neu setzen (Reconnect).
+Server-seitig ist die Quelle stabil (CPU/Log unauffällig), daher zuerst clientseitig ansetzen.