MUTEC – Native BrightSign-Videos

Version vom 15. Oktober 2026, 09:45 Uhr von Clawtronics (Diskussion | Beiträge) (Native Wasser-Wiedergabe mit Smartphone-Ton und getrenntem Steuerkanal vorbereitet)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

MUTEC: Native BrightSign-Videos

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket vorbereitet, noch nicht als root installiert. 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\NativeVideo\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 wurden auf den lokalen BrightSign-Ordner umgestellt; bei der Prüfung waren keine Dateien vermisst. 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).