https://wiki.megbes.de/index.php?action=history&feed=atom&title=MUTEC_%E2%80%93_Native_Video-Labortest 2026-11-03T18:25:27Z Versionsgeschichte dieser Seite in MegBes Wiki MediaWiki 1.45.6 https://wiki.megbes.de/index.php?title=MUTEC_%E2%80%93_Native_Video-Labortest&diff=164&oldid=prev 2026-10-16T09:46:30Z

<p>Isolierte native SD-Labortests nach Player-Abstuerzen vorbereitet; Hardwaretest offen</p> <p><b>Neue Seite</b></p><div>= MUTEC: Isolierter nativer Video-Labortest =<br /> <br /> 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.<br /> <br /> == Zweck ==<br /> 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.<br /> <br /> == Bereitgestellte Dateien ==<br /> Lokal: C:\tinetronics Claw\R&amp;D\MUTEC\BrightSign\Native-Labortest. Archiv im Codex-Arbeitsordner: outputs/MUTEC-Native-Labortest.zip.<br /> <br /> * 01-Nur-Film: Eigenstaendiges autorun.brs mit genau einem roVideoPlayer und originaler Wasser.mp4; Dauerschleife, keine Netzwerksteuerung.<br /> * 02-Film-mit-Steuerung: Eigener roVideoPlayer, pausierter Start, feste lokale MP4, Start/Pause/Spulen und echte Positionsabfrage ueber separaten UDP-Port 41050.<br /> * 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.<br /> * Anleitung.md beschreibt den SD-Test und die Auswertung.<br /> <br /> 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.<br /> <br /> == Diagnose und naechste Schritte ==<br /> 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.<br /> <br /> 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.<br /> <br /> == Pruefung ==<br /> 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.<br /> <br /> [https://docs.brightsign.biz/develop/rovideoplayer BrightSign: roVideoPlayer] und [https://docs.brightsign.biz/develop/rodatagramsocket BrightSign: roDatagramSocket].</div>

Clawtronics