MUTEC – Native BrightSign-Videos

MUTEC: Native BrightSign-Videos

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket am 15.10.2026 erfolgreich als root installiert; 65 Tests bestanden. BrightAuthor-Projektkopie erstellt, noch nicht am XT1144 getestet/veröffentlicht.

Aktivieren

Bei freier Station 50 als root auf dem VPS:

```bash bash /home/clawtronics/mutec-native-video-update/apply-native-video-update.sh ```

Das Paket prüft 65 Tests und den aktuellen Stand aller 20 Quelldateien. Es sichert und ersetzt drei Relay-Dateien, ergänzt einen eigenen privaten `NATIVE_DISPLAY_KEY` in der vorhandenen Umgebungsdatei und startet den Dienst neu. Bei einem Fehler werden Dateien und Umgebung zurückgesetzt. MegBes-external/internal, der bestehende DISPLAY_KEY, Bestenlisten und der Ticketablauf-Wächter bleiben erhalten. Die neue Funktion ist über `nativevideo: true` in der öffentlichen capabilities-Antwort erkennbar.

Anschließend diese Projektkopie mit BrightAuthor Classic öffnen und auf Station 50 veröffentlichen:

`C:\tinetronics Claw\R&D\MUTEC\BrightSign\MUTEC2026 Counter XT1144 - Native Wasser.bpf`

Das Originalprojekt wurde nicht geändert. Die Kopie ist auf XT1144 eingestellt, enthält das Plugin `mutecNative` und die zusätzliche Szene `Native Wasser`. Alle vorhandenen Medienpfade bleiben wie im Original auf dem Produktionslaufwerk H erhalten. Die drei neuen Dateien direkt im Counter-Hauptverzeichnis auf dem Produktivrechner ablegen, neben Main und Header. Die Pruefung gegen die lokale Spiegelung fand keine fehlenden Medien. Die eigene Datei `MUTEC-Native-Wasser.mp4` wurde ohne erneute Videokodierung aus Wasser erzeugt, ohne Audiospur. Sie hat dieselbe Bildgröße 1376 × 430 und dieselbe Dauer von 97 Sekunden. Die vorhandene Zonenanordnung und Ausgabeauflösung bleiben erhalten.

Das Plugin enthält einen privaten, ausschließlich für diesen nativen Anzeigekanal gültigen Geräteschlüssel. Die Datei bleibt im lokalen BrightAuthor-Projekt und wird mit auf den Player veröffentlicht; sie gehört nicht auf den öffentlichen Webserver. Der Schlüssel ist bereits passend im Serverpaket hinterlegt und muss nicht vom Besucher eingegeben werden.

Die BrightSignOS-Version ist noch unbekannt. Die WebSocket-Brücke setzt einen modernen HTML-Renderer voraus; sie ist für die Sprachfunktionen von Chromium 87 (BrightSignOS 8.5) vorbereitet, einschließlich randomUUID-Ersatz. Ein tatsächlicher Kompatibilitätstest auf dem XT1144 ist erforderlich. Der Installer aktualisiert keine Player-Firmware.

Smartphone-Auswahlseite neu laden. Neuer Eintrag: **Wasser · BrightSign**. Electron ist für dieses Angebot nicht beteiligt und braucht keinen neuen Reiter.

Ablauf

1. Mit MegBes-Ticket anmelden und Wasser · BrightSign wählen. Exklusive Reservierung von Station 50, Befehl `50-nativewater`. 2. Die eigene BrightAuthor-Szene spielt die lokale MP4 über den nativen Decoder. Das Plugin hält die Wiedergabe für die Smartphone-Freigabe an. 3. Zwei Infokarten auf dem Smartphone bestätigen, Ton aktivieren und starten. Deutsch/Englisch, Pause, Zeitleiste, ±10 Sekunden und Kapitel Start stehen zur Verfügung. 4. Zur Auswahl sendet wie bei den anderen exklusiven Angeboten `50-Trailer` und gibt die Sitzung frei. Filmende bleibt bis zur Rückkehr bzw. zum Ticketablauf an diese Sitzung gebunden.

Synchronisation und Abgrenzung

Eine transparente 16 × 16-Pixel-HTML-Brücke auf dem BrightSign hält die Verbindung zum vorhandenen WebSocket-Relay; sie spielt selbst kein Video. Sie bleibt sichtbar, um Hintergrund-Timer-Drosselung zu vermeiden. Sie nutzt weder Node.js noch abgeschaltete HTTPS-/Web-Sicherheitsprüfungen. BrightAuthor und das Plugin kommunizieren lokal über BSMessagePort/PostJSMessage.

Das Plugin greift ausschließlich auf den nativen Player der Zone Video or Images zu, wenn dessen tatsächliche Quelle die eigene native Wasser-Datei aus dem Asset-Pool ist. Die separate, stumme Datei hat einen anderen Inhalt/Hash als die bestehende Wasser-Datei. Dadurch werden die bisherige Medienauswahl und der HDMI-Eingang nicht mitgesteuert.

Alle 250 ms werden echte Position und Dauer abgefragt. Spulbefehle werden erst bestätigt, wenn die abgefragte Position das Ziel bis auf 200 ms erreicht hat; nach fünf Sekunden wird stattdessen ein Fehler gemeldet. Rückmeldungen sind an Sitzung und konkrete Abfrage gebunden; alte Messungen werden verworfen. Der Smartphone-Ton übernimmt die bestehende Uhrabgleich-/Driftkorrektur: größere Abweichungen durch Positionssprung, kleinere über maximal ±2 % Abspielgeschwindigkeit. Die lokale Einstellung zur Audioverzögerung berücksichtigt den LED-Prozessor und Kopfhörer.

Bei fehlendem Smartphone-Heartbeat bzw. fehlender Audio-Bereitschaft pausiert der Film. Ein unabhängiger BrightScript-Timer pausiert auch bei ausgefallener WebSocket-/HTML-Brücke nach spätestens ungefähr 1,8 Sekunden. Verbindungsverlust setzt die Startabsicht zurück; eine erneute Freigabe ist nötig. Fehlen dem Smartphone frische Positionsmeldungen, pausiert sein Ton. Ticketablauf und Stationsfreigabe verwenden die vorhandene Infrastruktur.

Native und Electron-Videoanzeigen haben getrennte Verbindungen und Schlüssel. Native Besucher dürfen nur `50-nativewater`, keine Electron-Befehle und keine anderen Filme aufrufen. Der vorhandene HTML-Videokanal bleibt bestehen.

Vor Ort prüfen

- Nach Veröffentlichung: Das bisherige Trailer-/HDMI-/Aquarium-Verhalten bleibt benutzbar. - Wasser starten, Pause, mehrere Sprünge vor/zurück und an die Enden, Fortsetzung sowie Sprachwechsel testen. - Den Tonversatz mit Kopfhörern am echten Counter abstimmen. Mobilfunk, LED-Verarbeitung und Bluetooth erlauben ohne Messung kein Versprechen bildgenauer Synchronität. - Smartphone-Verbindung kurz trennen: Film muss pausieren. Danach bewusst erneut starten. - Zur Auswahl und Ticketablauf testen: Trailer/IDLE muss die Station wieder freigeben. - Nach Filmende muss die Smartphone-Seite Film beendet anzeigen.

Geprüft: 65 automatisierte Servertests auf dem VPS; Syntaxanalyse des BrightScript-Plugins ohne Fehler; Browserablauf mit simulierten nativen Rückmeldungen; alle sieben öffentlichen Frontend-Dateien per SHA-256 bestätigt. Noch offen: BrightAuthor-Öffnen/Veröffentlichen, reale BrightSign-API-Rückmeldungen und die wahrnehmbare Synchronisation am LED-Counter.

Technische Referenzen: [roVideoPlayer](https://docs.brightsign.biz/develop/rovideoplayer), [roHtmlWidget](https://docs.brightsign.biz/develop/rohtmlwidget), [offizielles HTMLZoneMessage-Beispiel](https://github.com/brightsign/BrightAuthor-Plugins/tree/master/HTMLZoneMessage).

Serverinstallation bestaetigt

15.10.2026: Alle 65 Tests und Ausgangsstandpruefungen bestanden. Oeffentliche API meldet nativevideo=true. Relay und Ticketablauf-Waechter aktiv. Sicherung: /var/backups/mutec-realtime/native-20261015T095543Z-4083237. Geraeteschluessel eingerichtet, bestehender DISPLAY_KEY und MegBes-Programme unveraendert. Veroeffentlichung der BrightAuthor-Projektkopie und realer Synchronisationstest am XT1144 noch nicht bestaetigt.

Erster Hardwaretest und Pfaderkennung

15.10.2026: Erster Test zeigt vorzeitig laufenden Film und fehlende Positionsrueckmeldung. Das bereitgestellte Player-Protokoll bestaetigt BrightSignOS 8.5.53.2 und die eigene 97-Sekunden-Datei. Der Player protokolliert absolute Linux-Pfade unter /storage/sd/pool/, die bisherige Normalisierung beruecksichtigte nur sd:/ und file:-Praefixe. Plugin v2 normalisiert auch diesen Pfad und akzeptiert geboxte String-/Zahlenwerte. Initialisierung und erste Dateierkennung werden ohne Schluessel im Player-Log protokolliert. Lokale Projektkopie aktualisiert, Syntaxanalyse bestanden. Erneute BrightAuthor-Veroeffentlichung und Hardwarebestaetigung stehen aus; kein neues Serverupdate erforderlich.

Produktionspfade erhalten

Auf Nutzerwunsch bleiben alle bestehenden Medienpfade exakt aus dem Originalprojekt erhalten (Laufwerk H, Tinetronics Local). Auch zukuenftige Generierungen veraendern diese Pfade nicht. Projektkopie, Plugin und native MP4 werden direkt auf H im vorhandenen Counter-Hauptverzeichnis erwartet. Die drei Dateien aus dem lokalen BrightSign-Hauptverzeichnis einmalig dorthin uebernehmen; kein Unterordner NativeVideo. Keine manuelle Pfadkorrektur im XML notwendig. Die lokalen C-Pfade dienen nur der Dateipruefung und werden nicht mehr in die Projektkopie geschrieben.

Diagnose und Befehlsuebergabe vom 16.10.2026

Ein neues Player-Protokoll liegt noch nicht vor. Der Player ist erreichbar, die Diagnose ist per Digest-Anmeldung geschuetzt. Plugin v3 meldet HTML-Ladezustand, JavaScript-/WebSocket-Verbindung, Uhrabgleich, Sitzungszuordnung und Erkennung der nativen Datei in getrennten Schritten; es protokolliert selbst keine Schluessel oder Nachrichteninhalte. Die BPF und H-Pfade bleiben unveraendert. Der Web-Teil wurde veroeffentlicht und oeffentlich geprueft. Steuerbefehle werden nun in einer begrenzten Warteschlange gehalten statt bei noch offener Bestaetigung verworfen; bei Trennung/Sitzungswechsel wird die Warteschlange geloescht. Ausfuehrbarer BrightScript-Test mit Player-Attrappen besteht fuer Pfaderkennung, Intro-Pause, Start, Spulen, Audio-Bereitschaft und Quellenabgrenzung. Browsertest mit simulierten nativen Rueckmeldungen besteht, einschliesslich unmittelbar aufeinanderfolgendem Spulen/Pause. Fuer den echten Player nur mutecNative.brs im Counter-Hauptverzeichnis ersetzen und die bestehende Projektkopie neu veroeffentlichen. Kein Serverupdate noetig. Hardwareursache und Synchronisation noch nicht bestaetigt.