MiiO OBS Lese-Diagnose - 2026-09-17
==================================

1. Dieses ZIP vollstaendig entpacken. Die portable Node-Laufzeit der vorhandenen
   MiiO-Installation muss unter %LOCALAPPDATA%\MiiO-OBS vorhanden sein.
2. Auf genau dem OBS-VPC im normalen Streaming-Benutzer anmelden.
3. Start-MiiO-Diagnostics.cmd starten. Lokalen OBS-Port eingeben (alt 4444,
   neu meist 4455). Keine Raum-URL und keinen YouTube-Schluessel eingeben.
4. Etwa 20 Minuten laufen lassen (maximal 30 Minuten moeglich). OBS wird nur gelesen.
   Fuer einen beaufsichtigten Trennungs-Test nach der ersten Beobachtung nur
   die Remote-Verbindung trennen, NICHT Windows abmelden, danach in dieselbe
   bestehende Windows-Sitzung zurueckkehren. Die Diagnose muss weiterlaufen.
5. Bericht unter %LOCALAPPDATA%\MiiO-OBS\diagnostics\<Zeitpunkt> aufbewahren.
   report.json enthaelt OBS-Beobachtungen; samples.jsonl bleibt auch bei einem
   vorzeitigen Abbruch erhalten. windows-before.json und windows-after.json
   zeigen ausgewaehlte lokale Metadaten. Fehlende Daten bleiben unbekannt.

Es werden keine Quellen, Token, Streams, Browserdaten, Aufgaben, Energie- oder
Citrix-Richtlinien veraendert. Es wird kein kuenstlicher Heartbeat gesendet und
kein Bericht hochgeladen. Keine Stream-Schluessel, Task-Argumente, Benutzer-
identitaeten oder vollstaendigen Raum-URLs werden gespeichert.
Pro Beobachtung erfolgt parallel eine HEAD-Anfrage an die feste Adresse
https://mio.sfcon.app/obs-overlay-runtime.js mit Kennung
MiiO-Workstation-Diagnostics/14. Ohne Zugangsdaten, Query, Token oder Heartbeat;
maximal 3 Sekunden, keine Weiterleitungen. Nur Status, Dauer und Ergebnis werden
gespeichert. Dies prueft den Netzwerkweg von Node, NICHT den Browser in OBS.

Getrennt lesen: Programmszene, Vorschau, OBS-Streamstatus, Quellenzustand und
Cockpit-Kontakt sind unterschiedliche Nachweise. Ein laufender OBS-Stream ist
noch kein Nachweis eines empfangenen YouTube-Bilds. Bei altem OBS WebSocket 4
bleiben Reconnect-Status und manche Quellenangaben unbekannt. Browser-Netzwerk-
anfragen und CEF-JavaScript-Fehler werden nicht erfasst und bleiben unbekannt.
20 Minuten koennen Kontaktluecken um 11 Minuten sichtbar machen; ein 90-Sekunden-
Kurzcheck kann diesen Zyklus nicht bestaetigen oder ausschliessen.

Aufgaben werden nur unter \Streaming\ erfasst. Nichtzero LastTaskResult kann
auch einen Zustand statt einen Fehler beschreiben und muss interpretiert werden.
Task-Aktionen und deren Argumente lokal ansehen, niemals mit Schluesseln teilen.
Session- und Energieereignisse stammen aus lokalen Protokollen; sie sind kein
vollstaendiger Nachweis aller Citrix-Richtlinien oder aller Sitzungen.

Optional in PowerShell (keine Token als Argumente):
  .\Start-MiiO-Diagnostics.ps1 -Port 4444 -Seconds 1200
  .\Start-MiiO-Diagnostics.ps1 -Port 4444 -Seconds 90
  .\Start-MiiO-Diagnostics.ps1 -Port 4444 -Seconds 0

Mit bekanntem Kurstermin, Datum/Zeitzone anpassen:
  .\Start-MiiO-Diagnostics.ps1 -Port 4444 -Seconds 1200 -CourseStart '2026-09-17T16:20:00+02:00' -CourseEnd '2026-09-17T16:50:00+02:00'
Der Bericht zeigt dann die Vorbereitung ab minus 3 Minuten und den Vorspann ab
minus 1 Minute. Das Sendungsende bleibt ohne gepruefte Abspanndauer unbekannt.
Nur wenn der konkrete Cockpit-Plan z.B. 240 Sekunden Abspann vorsieht, zusaetzlich
-OutroSeconds 240 angeben (0 bis 300). Niemals pauschal 5 Minuten annehmen:
kurze Kursabstaende und zusammenhaengende Streams brauchen ihren exakten Plan.
Task-Abdeckung wird nicht behauptet. Vor dem Vorspann muss die tatsaechliche
Uebertragung stabil laufen. Start-/Stop-Aufgaben nur nach lokalem Vergleich mit
genau diesem Kurs, dem Cockpit-Werbefenster und dem naechsten Kurs korrigieren.

Abbruch: Fenster schliessen. Es bleibt kein Dienst/Autostart/Watchdog zurueck.
Ruecknahme: Diagnoseordner loeschen; der normale OBS-Betrieb bleibt unberuehrt.
Dieses Paket muss zuerst auf einem vorhandenen OBS-26/WebSocket-4-Rechner und
bei Bedarf auf OBS/WebSocket-5 vor Ort geprueft werden. Lokale automatisierte
Tests ersetzen keine echte Windows-/Citrix- und Empfangsabnahme.
