Claude: ScreenShot v2

doc/04_Delay_roadmap.md

@@ -395,16 +395,51 @@ Zwei Bugs gefunden und sofort behoben:
    ersten, schwarzen Frame. Fix: erste 15 Frames verwerfen
    (`-vf select=gte(n,15)`), dann einen greifen. Kostet ~1 s mehr Blackout.
 
+> **Hinweis:** Der hier beschriebene externe-FFmpeg-Grab (DELETE → eigener FFmpeg →
+> PUT) wurde im zweiten Test verworfen — siehe nächster Abschnitt. Der PUT-Param-Fix
+> (Bug 1) bleibt gültig (gleiche `name`+`src`-Konvention nutzt jetzt PATCH).
+
+### Zweiter Test (2026-06-04): externer Grab scheitert → Architektur-Pivot
+
+**Befund:** Live-Video stabil ✓. Aber `/hires` liefert `FFmpeg exit 1, kein Frame
+erhalten` (curl: leeres 1KB-Bild). Video bleibt dabei durchgehend stabil.
+
+**Diagnose (belegt):** Das *Ausbleiben des Blackouts* ist der Beweis. Der externe-Grab-
+Ansatz müsste das Video kurz schwarz schalten (DELETE stoppt den go2rtc-Producer).
+Es bleibt aber stabil → go2rtc gibt das Gerät **nie frei**: Der offene Live-Viewer
+reconnectet nach dem DELETE sofort, go2rtc startet den Producer per on-demand neu und
+greift `/dev/video0` zurück, bevor der externe FFmpeg es öffnen kann → „device busy"
+→ exit 1. **Eine USB-Kamera lässt sich nur einmal öffnen** — zwei Prozesse (go2rtc +
+eigener FFmpeg) können nicht gleichzeitig zugreifen, und der Live-Viewer lässt go2rtc
+immer gewinnen. Der Zwei-Prozess-Ansatz ist damit grundsätzlich falsch.
+
+**Lösung (umgesetzt): go2rtc-interner Hi-Res-Grab — kein zweiter Prozess.**
+go2rtc behält die Geräte-Hoheit. Node schaltet nur kurz dessen Quelle um:
+
+```
+1. PATCH /api/streams?name=cam0&src=<1280×960-Quelle>   → go2rtc-Producer auf Hi-Res
+2. ~1,2s warten (Producer-Start + Kamera-Belichtung)
+3. GET /api/frame.jpeg?src=cam0  → Frame holen; nur akzeptieren wenn JPEG ≥1000px
+   breit (sonst ist es noch der alte 640er); bis zu 6× alle 500ms retryen
+4. PATCH /api/streams?name=cam0&src=<640×480-Quelle>    → zurück auf Live (immer, finally)
+```
+
+Nur **ein** Prozess (go2rtc) öffnet je das Gerät → keine Konkurrenz mehr möglich.
+Der Live-Viewer dieser einen Kamera glitcht ~3–4s (Producer-Restart + kurz 1280er
+Bild, vom Browser per CSS skaliert) — der vom Nutzer ausdrücklich akzeptierte „Blackout".
+Die zweite Kamera ist nicht betroffen. Umgesetzt in `src/snapshotService.js`
+(externer FFmpeg + `captureOneFrame` entfernt).
+
 ### Offene Punkte (ToDo)
 
-- **go2rtc-CPU ~53% bei 2 aktiven Live-Streams.** Besser als H.264-Transcode (~127%),
+- **go2rtc-CPU ~50% bei 2 aktiven Live-Streams.** Besser als H.264-Transcode (~127%),
   aber kein echtes Null. go2rtc re-encodiert MJPEG→MJPEG (kein `-c:v copy`) statt
-  reinem Durchreichen. Das sind ~0,5 CPU-Kerne für 2 Kameras → stabil und unkritisch
-  auf dieser Maschine. **Optionaler Hebel falls je nötig:** prüfen ob go2rtc-Quelle
-  auf echtes Copy/Passthrough umstellbar ist. Risiko: Stabilität des laufenden,
-  funktionierenden Streams — daher nur anfassen wenn CPU real zum Problem wird.
-- **Geräte-Race bei Hi-Res mit gleichzeitig offenem Live-Tab.** Ist ein Live-Consumer
-  aktiv, kann go2rtc das Gerät nach dem DELETE per on-demand-Reconnect sofort wieder
-  greifen und mit dem Hi-Res-Grab kollidieren. Warmup + Frame-Verwerfen fängt das
-  meist ab. Falls doch leere Bilder auftreten: kurzer Retry im Grab, oder Live-Tab
-  vor dem Hi-Res-Klick kurz pausieren.
+  reinem Durchreichen. ~0,5 CPU-Kerne für 2 Kameras → stabil und unkritisch auf dieser
+  Maschine. **Optionaler Hebel falls je nötig:** prüfen ob go2rtc-Quelle auf echtes
+  Copy/Passthrough umstellbar ist. Risiko: Stabilität des laufenden Streams — nur
+  anfassen wenn CPU real zum Problem wird.
+- **Cleanup (unkritisch):** Der webcam-Container braucht jetzt **kein** `ffmpeg` und
+  **keine** `devices`/`group_add: video` mehr (kein externer Grab). Kann beim nächsten
+  bewussten Aufräumen aus `docker-compose.yaml` raus — aktuell harmlos (nur ungenutzt).
+- **Falls der PATCH-Restart je hakt** (frame.jpeg bleibt zu klein/640): Warmup-Zeit
+  oder Retry-Anzahl in `snapshotService.js` erhöhen (`HIRES_WARMUP_MS`, `HIRES_TRIES`).