Zum Inhalt springen

MUTEC – Native Video-Labortest

Aus MegBes Wiki

MUTEC: Isolierter nativer Video-Labortest

[Bearbeiten]

Stand 16.10.2026. Der Nutzer berichtet Abstuerze mit dem bisherigen mutecNative-Plugin und ist zur Originalpraesentation MUTEC2026 Counter XT1144.bpf zurueckgekehrt. Die konkrete Ursache ist nicht bewiesen. Die bestaetigte Player-Version ist BrightSignOS 8.5.53.2.

Zweck

[Bearbeiten]

Native Wiedergabe und elementare Steuerung zuerst ohne BrightAuthor-Plugin, HTML-Renderer, WebSocket, MegBes oder Smartphone-Audio pruefen. Die frueheren Server-/Browsertests belegen die Nachrichtenlogik, keine Stabilitaet des BrightSign-Runtimes.

Bereitgestellte Dateien

[Bearbeiten]

Lokal: C:\tinetronics Claw\R&D\MUTEC\BrightSign\Native-Labortest. Archiv im Codex-Arbeitsordner: outputs/MUTEC-Native-Labortest.zip.

  • 01-Nur-Film: Eigenstaendiges autorun.brs mit genau einem roVideoPlayer und originaler Wasser.mp4; Dauerschleife, keine Netzwerksteuerung.
  • 02-Film-mit-Steuerung: Eigener roVideoPlayer, pausierter Start, feste lokale MP4, Start/Pause/Spulen und echte Positionsabfrage ueber separaten UDP-Port 41050.
  • PC-Steuerung: Lokale Browseroberflaeche mit Python-Standardbibliothek; nur Loopback-Port 18150, Standardziel 192.168.14.50. Kein MegBes-Port, keine beliebigen Zielbefehle. Python 3 und LAN-Erreichbarkeit erforderlich.
  • Anleitung.md beschreibt den SD-Test und die Auswertung.

Es handelt sich um eigenstaendige SD-Testprogramme, keine BPF-Projekte. Ausschliesslich eine separate Test-SD bei freier Station verwenden; die Produktions-SD unveraendert aufbewahren. Zum Kartentausch Player ausschalten. Zuerst den Inhalt von 01-Nur-Film ins SD-Hauptverzeichnis kopieren und drei Durchlaeufe beobachten. Erst nach stabilem Test 1 die autorun.brs aus Test 2 einsetzen und die PC-Steuerung starten. Spruenge werden angenommen und danach anhand der gemessenen Position bestaetigt; die Oberflaeche zeigt diesen Unterschied.

Diagnose und naechste Schritte

[Bearbeiten]

Scheitert bereits Test 1, native Wiedergabe, MP4, SD und Firmware/Decoder untersuchen. Scheitert nur Test 2, den letzten elementaren Player-Aufruf untersuchen. Sind beide stabil, als getrennten Schritt eine minimale BrightAuthor-Praesentation pruefen; danach erst die WebSocket-Anbindung und Smartphone-Audio ergaenzen.

Moegliche spaetere Architektur: WebSocket-Gateway auf dem vorhandenen PC, einfacher lokaler Steuer-/Positionskanal zum BrightSign. Der Film bleibt nativ auf dem BrightSign, ein zusaetzlicher HTML-Renderer fuer WebSocket auf dem Player entfaellt. Noch nicht implementiert.

Pruefung

[Bearbeiten]

Beide Skripte syntaktisch geprueft. Die echte BrightScript-Befehlsfunktion wurde mit Player-Attrappen ausgefuehrt. Drei Python-Tests pruefen Eingaben, UDP-Antwortzuordnung und Timeout. Browser/HTTP/UDP-Test mit Loopback-Attrappe bestanden, einschliesslich abgeschlossener Spruenge und erneuter Bedienbarkeit. Originalfilm in beiden Paketen bytegleich; Original-BPF unveraendert. Keine Aenderung an Produktionspraesentation, H-Pfaden, VPS oder Frontend. Hardwaretests sind offen. Kein Firmwareupdate durchgefuehrt oder vorausgesetzt.

BrightSign: roVideoPlayer und BrightSign: roDatagramSocket.