MUTEC – Mobile Apps: Unterschied zwischen den Versionen

(7 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)

Zeile 69:

Geprüft: bewusst alte Sitzungsdatei vor neuer Login-Datei geladen, erfolgreiche automatische Reparatur, frische Aktivierung, fehlgeschlagene Prüfung, abgelaufene Relay-Sitzung, Browser-Isolation. Erneute Übernahme laufender Pong-Partie zweimal ohne neues Ticket/Trailer/Freigabe und Aquarium-Entwurf getestet. Öffentlicher Login mit simulierten Authentifizierungsantworten erreicht Auswahl ohne JavaScriptfehler; keine echte Station oder Besucher-Anmeldung benutzt. Paket/Nachweise outputs/MUTEC-Login-Fix.zip und MUTEC-Login-Fix-Installation.json. Pakete künftiger Erweiterungen müssen gemeinsame Session-/Client-Funktionen beibehalten.

== Arcade-Beitritt: Here comes a new challenger, 18.10.2026 ==

Neues Ziel: mehrere gültige Tickets dürfen unabhängig angemeldet sein. Station 50 / LED-Counter bleibt genau einer normalen Steuersitzung zugeordnet. Weitere Besucher sehen bei belegtem Counter die laufende Anwendung und passende Aktionen statt einer Liste nicht startbarer Apps. Beitritt ist keine zustimmungspflichtige Anfrage mehr.

=== Besucherablauf ===

Bei freiem Counter bleiben die drei Tabs Medien / Education / Games sichtbar. Bei belegtem Counter werden die betreffenden Auswahltabs und App-Kacheln ausgeblendet. Beitretbares Spiel: nur Mitspielen. Ein Klick öffnet die Erklärung, dass der Beitritt die laufende Runde unterbricht; erst Ja, mitspielen sendet den Beitritt. Zurück schließt den Dialog ohne Auswirkung. Bestätigung eröffnet sofort eine akzeptierte Gastrolle und eine neue Zweispieler-Runde; Spieler 1 hat kein Annehmen/Ablehnen mehr. Auf seinem Smartphone und der Anzeige steht Here comes a new challenger. Bis Spieler 2 seine kurze Einführung bzw. Sensorfreigabe abgeschlossen hat, wartet das Spiel. Wenn Gastgeber, Gast und Display bereit/verbunden sind: vollständiger Countdown von drei Sekunden, dann gemeinsamer Start.

Die unterbrochene Einzelrunde wird durch eine neue gemeinsame Runde ersetzt; der Zugang und die Stationsreservierung von Spieler 1 bleiben erhalten. Der Gast kann nur seine Spielrolle steuern, keine Stationsbefehle, App-Wechsel, Neustarts oder Spielenden auslösen. Die Stationshoheit bleibt beim Gastgeber; er kann die App weiterhin selbst verlassen. Ein voller Zweispieler-Platz zeigt die Belegung ohne weiteren Beitrittsbutton. Ein Film oder 3D-Objekt zeigt eine Belegungsinfo; beim Freigeben erscheint automatisch die Auswahl wieder. Im bestehenden gemeinsamen Farbraum ist Gemeinsam malen die passende Aktion (bis 24 Personen). Der separate neue Farben-Spielmodus nutzt wie die vier bisherigen Spiele den Challenger-Beitritt. Vorhandene Aqua-Editor-/Stationsregeln wurden nicht umgebaut.

=== Schnittstellen und Grenzen ===

GET /station/availability prüft das Besucherticket und den aktuellen MegBes-Stationszustand, liefert station=50, Label, App, Belegung und erlaubte Beitritts-/Gemeinschaftsaktion. Keine Ticket-/Steuertoken oder Besucheridentitäten im Ergebnis. Menü fragt sichtbar alle 2,5 Sekunden und bei Rückkehr in den Tab ab. POST /game/challenge akzeptiert ausschließlich feature und die konkrete gameId; dieselbe Zugangskontrolle wie vorher, serielle Reservierung gegen doppelte Gäste. Veraltete Partie oder App-Wechsel werden abgewiesen. Dasselbe Ticket kann seinen noch vorhandenen Gastzugang wieder abrufen, ohne erneut zu unterbrechen. Der alte Anfrage-Endpunkt bleibt für bereits geladene ältere Frontends kompatibel; alle Seiten nach Aktivierung neu laden.

Lobby-Snapshot hat challenger=true für die neue Übernahme. Der erste Gastgeber muss seine Steuerung weiterhin vorbereiten, wenn er noch im Intro war. Gastbereitschaft startet erst mit allen Verbindungen. Abbruch und Timeout geben nur den Gastplatz frei, keine Trailer-/Stationsabmeldung. Erste Gastvorbereitung maximal 90 Sekunden, ungebundener bzw. verlorener Gastzugang weiterhin 15 Sekunden. Nach einmaliger Vorbereitung greift die 90-Sekunden-Frist bei späteren Wiederverbindungen/Revanchen nicht erneut. Ticketwiderruf, Sessionablauf und Gastgeberverlust behalten die bestehenden Schutzregeln. Challenger-Anzeige in der mittleren Bildschirmhälfte, mit horizontaler LED-Vorverzerrung.

=== Prüfung und Installation ===

194 Tests lokal und auf Linux/VPS bestanden, basierend auf den tatsächlich laufenden Servermodulen einschließlich des neuen Farben-Spiels. Geprüft für Pong, Pöng, Flight, Ortssuche und Farben-Spiel: sofortige Annahme nach Bestätigung, kein Gastgeber-Veto, verpflichtende Vorbereitung, vollständiger Countdown, zwei gleichzeitige Gäste, Wiederholung, voller Platz, Abbruch/Timeout, Wiederverbindung, falsches/abgelaufenes Ticket, falsche Partie und fehlende Stationsrechte. HTTP-Status und Challenge-Endpunkt authentifiziert geprüft. Browser mit echtem isoliertem Relay: Pong/Pöng einschließlich laufendem Solo, Bestätigungsabbruch ohne Unterbrechung, Smartphone-/Display-Meldung, Gastintro, Countdown, dritter Besucher, Gastausstieg und freier Auswahl. Zusätzlich Video, Objects und gemeinsamer Farbraum; öffentliche Website mit simulierten Statusdaten geprüft. Keine echte Station gesteuert.

52 Frontend-Dateien gesichert und öffentlich bytegleich hochgeladen. Aktivierung ist über challengerArcade in capabilities abgesichert: solange das Relay nicht aktualisiert ist, gilt weiterhin der bisherige Ablauf. Serverpaket auf /home/clawtronics/mutec-challenger-update bereit; als root bei freier Station 50 ausführen: bash /home/clawtronics/mutec-challenger-update/apply-challenger-update.sh. Installer prüft Paket, Tests und SHA-Ausgangsstand aller Servermodule vor Änderungen, sichert die ersetzten Dateien und hat Rollback. Ersetzt nur server.js, pong-guests.js, game-lobby.js und den neuen Test. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, vorhandene Farben-Spielmodule und synced sources/ bleiben erhalten. Root-Aktivierung bei Dokumentation noch ausstehend. Danach Smartphone-Seiten und Electron-Webseiten neu laden; physischer Messestandtest noch erforderlich.

Artefakte im bisherigen Codex-Arbeitsordner outputs/: MUTEC-Challenger-server.tar.gz, zugehörige SHA-Datei, apply-challenger-update.sh, MUTEC-Challenger-VPS-Test.txt, MUTEC-Challenger-Frontend.zip, MUTEC-Challenger-Installation.json und MUTEC-Challenger-Browserpruefung.json. Geprüfter Relay-Quellstand im Arbeitsordner work/challenger-stage/realtime; nicht blind aus älteren Frontendpaketen gemeinsame Session-/Client-Dateien überschreiben.

== Arcade-Beitritt aktiviert, 18.10.2026 ==

Root-Installation erfolgreich abgeschlossen: 194 Tests bestanden, Relay und Ablauf-Wächter aktiv. Health meldet challengerArcade=true; auch die öffentliche capabilities-Schnittstelle mit dem erlaubten Website-Origin wurde nach der Installation mit challengerArcade=true geprüft. Der zuvor als ausstehend dokumentierte Arcade-Ablauf ist damit aktiviert. Serversicherung: /var/backups/mutec-realtime/challenger-20261018T204434Z-3580490. Smartphone-Seiten und Electron-Webseiten neu laden. Physischer Test mit zwei Mobilgeräten am Counter bleibt noch durchzuführen.

== Museumsguide ==

Seit 20.10.2026 unter Education: Dummy-Ausstellung mit Sprach-/Untertitelwahl, vierstelligen Stationscodes, Originaltexten und Audios aus BAYAM/GKP, Bildergalerie und Umfragen. Auch bei belegtem Counter verfuegbar. Station-JSONs bleiben kompatibel; importierte IPs bleiben bis zur ausdruecklichen Zuordnung im Demo-Modus. Details: [[MUTEC – Museumsguide]].

== Messages und YouTube wieder im Medien-Tab ==

Stand 21.10.2026: Die ursprünglichen iFrames formmessage.php (Messages) und form.php (YouTube) stehen wieder direkt unter den Filmbeiträgen im Tab Medien. Ticket-Anmeldung bleibt erforderlich; erst Senden reserviert die exklusive media-Sitzung. Reines Öffnen der Medienauswahl reserviert den Counter nicht. Beide Formulare teilen dieselbe Sitzung; fremde Belegungen erlauben kein Senden.

Bestehende Signale bleiben erhalten: 50-message für Nachrichten, 166-youtube und 50-youtube für den YouTube-Link. „Wiedergabe beenden“ startet den Trailer und gibt die Station frei. Reload und erneuter Ticket-Scan im selben Browserprofil führen zur Medienauswahl mit derselben media-Sitzung zurück. Andere Anwendungen behalten den bisherigen Ablauf.

Sieben Dateien vorab lokal und vom Webserver gesichert, installiert und geprüft. Isolierte Prüfungen für beide Formulare, Befehle, gemeinsame Reservierung, Belegungssperre, Trailer, Reload/Tab-Übernahme sowie bestehender Pong-/Login-Ablauf. PHP-Syntax und reale Ablehnung nicht authentifizierter POSTs geprüft; öffentlicher Browsertest mit simuliertem Speichern und simulierten Befehlen, ohne Counter-Umschaltung. Kein Relay-Update und keine Änderungen an sources/.

== YouTube als steuerbarer Medienbeitrag ==

Stand 21.10.2026: YouTube ist jetzt ein eigener Medien-Button wie Wasser und Drotschmann. Der bisherige YouTube-iFrame im Hauptmenü entfällt; Messages bleibt erhalten. Nach Öffnen zeigt die bestehende Filmsteuerung ein zusätzliches YouTube-URL-Feld. Play/Pause, Fortschrittsregler, ±10 Sekunden und Lautstärke steuern den Counter. Der YouTube-Ton läuft auf Wunsch am Counter. Beim Wechsel zu lokalen Filmen bleiben Smartphone-Ton, Sprachspuren und Kapitel erhalten.

Die offizielle YouTube IFrame Player API wird im vorhandenen Electron-Reiter video eingesetzt (166-video / 50-maps). Kein neuer Reiter, kein neuer Schlüssel, kein Relay- oder Electron-Programmupdate. Der aktuelle VPS-Validator wurde auf Kompatibilität geprüft. youtube.js akzeptiert nur bekannte YouTube-Hostnamen und gültige einzelne Video-IDs. WebSocket nutzt unverändert video.command / video.listener / video.status; begrenzte Medienkennungen youtube_<Video-ID>_v<Lautstärke 0–100> übertragen Videoauswahl und Lautstärke. Eine Lautstärkeänderung desselben Videos erhält Abspielposition und Play/Pause. Roh-URLs oder beliebige Netzwerkziele werden nicht übertragen.

Referrer-Policy strict-origin-when-cross-origin und origin sind gesetzt. Keine Stream-Extraktion, keine separate YouTube-Audiospur und keine verdeckenden MUTEC-Overlays über dem YouTube-Player. Einbettungs-/Netzwerk-/Autoplay-Fehler werden angezeigt. YouTube-eigene Freigaben, Werbung und Verfügbarkeit gelten weiterhin; Live-Streams ohne bekannte Dauer haben keinen normalen Fortschrittsregler. Exklusive Ticket-Sitzung, Sperre bei fremder Belegung, Tab-Übernahme und Trailer-Rückkehr bleiben erhalten.

Zwölf Dateien vorab lokal und auf dem Webserver gesichert und installiert. Geprüft mit echter lokaler WebSocket-Verbindung und simuliertem YouTube-Player: Medienauswahl, URL-Prüfung, Play/Pause/Seek, Counter-Ton/Lautstärke ohne Sprung, laufende Wasser-Wiedergabe mit Smartphone-Ton, Fehler/Wiederaufnahme, Tab-Übernahme, Trailer und Mobilansichten. Bestehender Pong-/Login-Ablauf geprüft. Echte YouTube-API sowohl lokal als auch über die veröffentlichte HTTPS-Herkunft erfolgreich mit Video-Metadaten geprüft; öffentlicher Bedienoberflächentest mit simulierten Stationsbefehlen. Physischer Hör-/Bildtest am LED-Counter steht nach Neuladen/Neustart von Electron aus. views.json ist bereits passend eingerichtet. sources/ unverändert.

[https://www.tinetronics.de/mutec/video/README-YouTube.md Technische Anleitung] · [https://developers.google.com/youtube/iframe_api_reference Offizielle YouTube-API] · [https://developers.google.com/youtube/terms/required-minimum-functionality Einbettung und Client-Identifikation]

== YouTube: automatischer Start ohne Lautstärkeregler ==

Update 21.10.2026: Der Lautstärkeregler ist für YouTube entfernt; der Ton bleibt am Counter. Lokale Filme behalten Smartphone-Ton und dessen Lautstärkeregler.

„Video laden“ sendet die Videoauswahl; erst die Bestätigung des Counters löst unmittelbar Play aus. Kein zweiter Start-Klick und keine geschätzte Ladeverzögerung. Zeitposition und Wiedergabestatus kommen weiter vom Counter. Fehler und Verbindungsverlust verwerfen den vorgemerkten automatischen Start. Neue YouTube-Links verwenden den festen Player-Ausgangswert 100 Prozent. Die physische Audioanlage bestimmt die gewünschte Lautstärke vor Ort.

Drei Frontend-/Dokumentationsdateien vorab gesichert und veröffentlicht. Geprüft über echte lokale WebSocket-Verbindung mit simuliertem YouTube-Player: automatischer Start, versteckter Regler, Play/Pause/Seek, laufendes Wasser mit Smartphone-Ton und Regler, URL- und Einbettungsfehler mit Wiederaufnahme, Tab-Übernahme, Trailer und schmale Mobilansichten. Kein Relay-/Electron-Update. Smartphone-Seite neu laden.

== Automatische Auswahl und Trailer bei Inaktivitaet ==

Stand 21.10.2026: Frontend aktualisiert, Relay-Paket vorbereitet und auf VPS getestet; die Server-Aktivierung erfolgt noch durch root mit <code>bash /home/clawtronics/mutec-idle-update/apply-idle-update.sh</code> bei freier Station 50.

Abgelaufene Steuersitzungen führen automatisch zur Auswahl, sowohl bei API-Fehler als auch WebSocket-Code 4001. Ein weiterhin gültiges MegBes-Ticket bleibt erhalten. Ist das Ticket selbst ungültig, gilt weiter die normale Ticket-Prüfung/Dankeseite. Reine Netzfehler werden nicht als Sitzungsablauf behandelt; doppelte Steuerverbindungen geben keine fremde Sitzung frei. Gäste mit eigener angemeldeter Ticket-Sitzung kehren ebenfalls zur Auswahl zurück, anonyme Gäste behalten die Dankeseite. Eine alte automatische Rückkehr kann einen zwischenzeitlich neu gescannten Tab nicht übernehmen.

Smartphone-Seiten verlängern die Sitzung im Hintergrund nicht mehr. Beim Wiederanzeigen wird geprüft. Die vorhandene Steuersitzungsfrist beträgt ca. 45 Sekunden; nach Relay-Update startet auch deren automatischer Ablauf 50-Trailer vor der Freigabe. Bei Fehler wird Steuerung sofort gesperrt und die Trailer/Freigabe zur Wiederholung vorgemerkt. Vor jedem erneuten Trailer werden gültiges Ticket und die eigene REMOTE-Belegung geprüft; IDLE oder fremde Belegungen werden nicht umgeschaltet. Der vorhandene interne Ticketablauf-Wächter bleibt für tatsächlich abgelaufene Tickets unverändert zuständig.

Neue Serverfristen: 60 Sekunden ohne Bedienung nach Spiel-/Filmende, sonst 120 Sekunden ohne Eingabe. Unveränderte Steuer-Keepalives, Statusmeldungen und Sensorrauschen zählen nicht als Bedienung. Tatsächliche Tasten-/Touch-/Texteingaben werden bei Erneuerung gemeldet; zulässige geänderte Steuerdaten beider Spieler zählen ebenfalls. Spiel-Endebildschirme werden nicht durch weiterlaufende Steuerimpulse künstlich aktiv gehalten. Ein laufender Film mit aktiver Smartphone-Verbindung und frischer Display-Rückmeldung bleibt erhalten. Gemeinsam genutztes Farbenspektakel kehrt erst beim letzten Teilnehmer zum Trailer zurück. Aquarium-Editoren reservieren weiterhin keinen Counter und schalten fremde Anwendungen nicht um.

204 Servertests lokal und auf dem VPS bestanden, einschließlich Rückkehr, Fehler/Wiederholung, fremder Besitzer, IDLE, ungültiger Tickets, gemeinsamem Farbraum, Schluss-/Eingabefristen, Filmwiedergabe und Gastrechten. Browserprüfungen: automatischer Rückweg ohne Fehlbox, Ticket erhalten, Hintergrund ohne Erneuerung, einmalige Aktivitätsmeldung statt Heartbeats, alte Seite/Media-Sitzung und gleichzeitiger Ablauf/Tab-Scan. Bestehender Pong-/Login-Ablauf geprüft.

Frontend-Sicherung und Paket: outputs/MUTEC-Inaktivitaet-Frontend-Sicherung-20261021 und MUTEC-Inaktivitaet-Frontend.zip. Serverpaket: MUTEC-Inaktivitaet-server.tar.gz mit Prüfsumme und apply-idle-update.sh. Installer prüft den aktuellen Code-Ausgangsstand, sichert geänderte Dateien, führt alle Tests aus und startet nur den Relay neu. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, sources/ und Ticketablauf-Wächter bleiben erhalten. Nach Aktivierung liefert /health idleReturn:true; Smartphone-Seiten neu laden.

== Inaktivitaets-Update aktiviert, 21.10.2026 ==

Root-Installation vom Betreiber bestätigt: 204 Tests bestanden, keine Fehler; /health meldet idleReturn:true. Relay und Ticketablauf-Wächter sind active. Sicherung: /var/backups/mutec-realtime/idle-20261021T161249Z-2398303. Die zuvor als vorbereitet dokumentierte Trailer-Automatik ist damit aktiviert. Smartphone-Seiten neu laden, damit die neue Hintergrund-/Ablaufbehandlung verwendet wird.

Die Testliste umfasst aktuelle Funktionen sowie weiterhin vorhandene ältere Schnittstellen (z. B. QR-/Anfrage-Beitritt). Testnamen beschreiben nicht zwingend die aktuelle Benutzeroberfläche. Solange solche Schnittstellen unterstützt werden, bleiben ihre Rechte-/Ablaufprüfungen sinnvoll. Bereinigung erst zusammen mit gezielter Entfernung ungenutzter Schnittstellen. Künftige Installationsausgaben sollen Zusammenfassung und Fehler anzeigen und die vollständigen Testergebnisse in einem Detailprotokoll ablegen.

@@ Zeile 69: / Zeile 69: @@
 Geprüft: bewusst alte Sitzungsdatei vor neuer Login-Datei geladen, erfolgreiche automatische Reparatur, frische Aktivierung, fehlgeschlagene Prüfung, abgelaufene Relay-Sitzung, Browser-Isolation. Erneute Übernahme laufender Pong-Partie zweimal ohne neues Ticket/Trailer/Freigabe und Aquarium-Entwurf getestet. Öffentlicher Login mit simulierten Authentifizierungsantworten erreicht Auswahl ohne JavaScriptfehler; keine echte Station oder Besucher-Anmeldung benutzt. Paket/Nachweise outputs/MUTEC-Login-Fix.zip und MUTEC-Login-Fix-Installation.json. Pakete künftiger Erweiterungen müssen gemeinsame Session-/Client-Funktionen beibehalten.
+== Arcade-Beitritt: Here comes a new challenger, 18.10.2026 ==
+Neues Ziel: mehrere gültige Tickets dürfen unabhängig angemeldet sein. Station 50 / LED-Counter bleibt genau einer normalen Steuersitzung zugeordnet. Weitere Besucher sehen bei belegtem Counter die laufende Anwendung und passende Aktionen statt einer Liste nicht startbarer Apps. Beitritt ist keine zustimmungspflichtige Anfrage mehr.
+=== Besucherablauf ===
+Bei freiem Counter bleiben die drei Tabs Medien / Education / Games sichtbar. Bei belegtem Counter werden die betreffenden Auswahltabs und App-Kacheln ausgeblendet. Beitretbares Spiel: nur Mitspielen. Ein Klick öffnet die Erklärung, dass der Beitritt die laufende Runde unterbricht; erst Ja, mitspielen sendet den Beitritt. Zurück schließt den Dialog ohne Auswirkung. Bestätigung eröffnet sofort eine akzeptierte Gastrolle und eine neue Zweispieler-Runde; Spieler 1 hat kein Annehmen/Ablehnen mehr. Auf seinem Smartphone und der Anzeige steht Here comes a new challenger. Bis Spieler 2 seine kurze Einführung bzw. Sensorfreigabe abgeschlossen hat, wartet das Spiel. Wenn Gastgeber, Gast und Display bereit/verbunden sind: vollständiger Countdown von drei Sekunden, dann gemeinsamer Start.
+Die unterbrochene Einzelrunde wird durch eine neue gemeinsame Runde ersetzt; der Zugang und die Stationsreservierung von Spieler 1 bleiben erhalten. Der Gast kann nur seine Spielrolle steuern, keine Stationsbefehle, App-Wechsel, Neustarts oder Spielenden auslösen. Die Stationshoheit bleibt beim Gastgeber; er kann die App weiterhin selbst verlassen. Ein voller Zweispieler-Platz zeigt die Belegung ohne weiteren Beitrittsbutton. Ein Film oder 3D-Objekt zeigt eine Belegungsinfo; beim Freigeben erscheint automatisch die Auswahl wieder. Im bestehenden gemeinsamen Farbraum ist Gemeinsam malen die passende Aktion (bis 24 Personen). Der separate neue Farben-Spielmodus nutzt wie die vier bisherigen Spiele den Challenger-Beitritt. Vorhandene Aqua-Editor-/Stationsregeln wurden nicht umgebaut.
+=== Schnittstellen und Grenzen ===
+GET /station/availability prüft das Besucherticket und den aktuellen MegBes-Stationszustand, liefert station=50, Label, App, Belegung und erlaubte Beitritts-/Gemeinschaftsaktion. Keine Ticket-/Steuertoken oder Besucheridentitäten im Ergebnis. Menü fragt sichtbar alle 2,5 Sekunden und bei Rückkehr in den Tab ab. POST /game/challenge akzeptiert ausschließlich feature und die konkrete gameId; dieselbe Zugangskontrolle wie vorher, serielle Reservierung gegen doppelte Gäste. Veraltete Partie oder App-Wechsel werden abgewiesen. Dasselbe Ticket kann seinen noch vorhandenen Gastzugang wieder abrufen, ohne erneut zu unterbrechen. Der alte Anfrage-Endpunkt bleibt für bereits geladene ältere Frontends kompatibel; alle Seiten nach Aktivierung neu laden.
+Lobby-Snapshot hat challenger=true für die neue Übernahme. Der erste Gastgeber muss seine Steuerung weiterhin vorbereiten, wenn er noch im Intro war. Gastbereitschaft startet erst mit allen Verbindungen. Abbruch und Timeout geben nur den Gastplatz frei, keine Trailer-/Stationsabmeldung. Erste Gastvorbereitung maximal 90 Sekunden, ungebundener bzw. verlorener Gastzugang weiterhin 15 Sekunden. Nach einmaliger Vorbereitung greift die 90-Sekunden-Frist bei späteren Wiederverbindungen/Revanchen nicht erneut. Ticketwiderruf, Sessionablauf und Gastgeberverlust behalten die bestehenden Schutzregeln. Challenger-Anzeige in der mittleren Bildschirmhälfte, mit horizontaler LED-Vorverzerrung.
+=== Prüfung und Installation ===
+Tests lokal und auf Linux/VPS bestanden, basierend auf den tatsächlich laufenden Servermodulen einschließlich des neuen Farben-Spiels. Geprüft für Pong, Pöng, Flight, Ortssuche und Farben-Spiel: sofortige Annahme nach Bestätigung, kein Gastgeber-Veto, verpflichtende Vorbereitung, vollständiger Countdown, zwei gleichzeitige Gäste, Wiederholung, voller Platz, Abbruch/Timeout, Wiederverbindung, falsches/abgelaufenes Ticket, falsche Partie und fehlende Stationsrechte. HTTP-Status und Challenge-Endpunkt authentifiziert geprüft. Browser mit echtem isoliertem Relay: Pong/Pöng einschließlich laufendem Solo, Bestätigungsabbruch ohne Unterbrechung, Smartphone-/Display-Meldung, Gastintro, Countdown, dritter Besucher, Gastausstieg und freier Auswahl. Zusätzlich Video, Objects und gemeinsamer Farbraum; öffentliche Website mit simulierten Statusdaten geprüft. Keine echte Station gesteuert.
+Frontend-Dateien gesichert und öffentlich bytegleich hochgeladen. Aktivierung ist über challengerArcade in capabilities abgesichert: solange das Relay nicht aktualisiert ist, gilt weiterhin der bisherige Ablauf. Serverpaket auf /home/clawtronics/mutec-challenger-update bereit; als root bei freier Station 50 ausführen: bash /home/clawtronics/mutec-challenger-update/apply-challenger-update.sh. Installer prüft Paket, Tests und SHA-Ausgangsstand aller Servermodule vor Änderungen, sichert die ersetzten Dateien und hat Rollback. Ersetzt nur server.js, pong-guests.js, game-lobby.js und den neuen Test. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, vorhandene Farben-Spielmodule und synced sources/ bleiben erhalten. Root-Aktivierung bei Dokumentation noch ausstehend. Danach Smartphone-Seiten und Electron-Webseiten neu laden; physischer Messestandtest noch erforderlich.
+Artefakte im bisherigen Codex-Arbeitsordner outputs/: MUTEC-Challenger-server.tar.gz, zugehörige SHA-Datei, apply-challenger-update.sh, MUTEC-Challenger-VPS-Test.txt, MUTEC-Challenger-Frontend.zip, MUTEC-Challenger-Installation.json und MUTEC-Challenger-Browserpruefung.json. Geprüfter Relay-Quellstand im Arbeitsordner work/challenger-stage/realtime; nicht blind aus älteren Frontendpaketen gemeinsame Session-/Client-Dateien überschreiben.
+== Arcade-Beitritt aktiviert, 18.10.2026 ==
+Root-Installation erfolgreich abgeschlossen: 194 Tests bestanden, Relay und Ablauf-Wächter aktiv. Health meldet challengerArcade=true; auch die öffentliche capabilities-Schnittstelle mit dem erlaubten Website-Origin wurde nach der Installation mit challengerArcade=true geprüft. Der zuvor als ausstehend dokumentierte Arcade-Ablauf ist damit aktiviert. Serversicherung: /var/backups/mutec-realtime/challenger-20261018T204434Z-3580490. Smartphone-Seiten und Electron-Webseiten neu laden. Physischer Test mit zwei Mobilgeräten am Counter bleibt noch durchzuführen.
+== Museumsguide ==
+Seit 20.10.2026 unter Education: Dummy-Ausstellung mit Sprach-/Untertitelwahl, vierstelligen Stationscodes, Originaltexten und Audios aus BAYAM/GKP, Bildergalerie und Umfragen. Auch bei belegtem Counter verfuegbar. Station-JSONs bleiben kompatibel; importierte IPs bleiben bis zur ausdruecklichen Zuordnung im Demo-Modus. Details: [[MUTEC – Museumsguide]].
+== Messages und YouTube wieder im Medien-Tab ==
+Stand 21.10.2026: Die ursprünglichen iFrames formmessage.php (Messages) und form.php (YouTube) stehen wieder direkt unter den Filmbeiträgen im Tab Medien. Ticket-Anmeldung bleibt erforderlich; erst Senden reserviert die exklusive media-Sitzung. Reines Öffnen der Medienauswahl reserviert den Counter nicht. Beide Formulare teilen dieselbe Sitzung; fremde Belegungen erlauben kein Senden.
+Bestehende Signale bleiben erhalten: 50-message für Nachrichten, 166-youtube und 50-youtube für den YouTube-Link. „Wiedergabe beenden“ startet den Trailer und gibt die Station frei. Reload und erneuter Ticket-Scan im selben Browserprofil führen zur Medienauswahl mit derselben media-Sitzung zurück. Andere Anwendungen behalten den bisherigen Ablauf.
+Sieben Dateien vorab lokal und vom Webserver gesichert, installiert und geprüft. Isolierte Prüfungen für beide Formulare, Befehle, gemeinsame Reservierung, Belegungssperre, Trailer, Reload/Tab-Übernahme sowie bestehender Pong-/Login-Ablauf. PHP-Syntax und reale Ablehnung nicht authentifizierter POSTs geprüft; öffentlicher Browsertest mit simuliertem Speichern und simulierten Befehlen, ohne Counter-Umschaltung. Kein Relay-Update und keine Änderungen an sources/.
+== YouTube als steuerbarer Medienbeitrag ==
+Stand 21.10.2026: YouTube ist jetzt ein eigener Medien-Button wie Wasser und Drotschmann. Der bisherige YouTube-iFrame im Hauptmenü entfällt; Messages bleibt erhalten. Nach Öffnen zeigt die bestehende Filmsteuerung ein zusätzliches YouTube-URL-Feld. Play/Pause, Fortschrittsregler, ±10 Sekunden und Lautstärke steuern den Counter. Der YouTube-Ton läuft auf Wunsch am Counter. Beim Wechsel zu lokalen Filmen bleiben Smartphone-Ton, Sprachspuren und Kapitel erhalten.
+Die offizielle YouTube IFrame Player API wird im vorhandenen Electron-Reiter video eingesetzt (166-video / 50-maps). Kein neuer Reiter, kein neuer Schlüssel, kein Relay- oder Electron-Programmupdate. Der aktuelle VPS-Validator wurde auf Kompatibilität geprüft. youtube.js akzeptiert nur bekannte YouTube-Hostnamen und gültige einzelne Video-IDs. WebSocket nutzt unverändert video.command / video.listener / video.status; begrenzte Medienkennungen youtube_<Video-ID>_v<Lautstärke 0–100> übertragen Videoauswahl und Lautstärke. Eine Lautstärkeänderung desselben Videos erhält Abspielposition und Play/Pause. Roh-URLs oder beliebige Netzwerkziele werden nicht übertragen.
+Referrer-Policy strict-origin-when-cross-origin und origin sind gesetzt. Keine Stream-Extraktion, keine separate YouTube-Audiospur und keine verdeckenden MUTEC-Overlays über dem YouTube-Player. Einbettungs-/Netzwerk-/Autoplay-Fehler werden angezeigt. YouTube-eigene Freigaben, Werbung und Verfügbarkeit gelten weiterhin; Live-Streams ohne bekannte Dauer haben keinen normalen Fortschrittsregler. Exklusive Ticket-Sitzung, Sperre bei fremder Belegung, Tab-Übernahme und Trailer-Rückkehr bleiben erhalten.
+Zwölf Dateien vorab lokal und auf dem Webserver gesichert und installiert. Geprüft mit echter lokaler WebSocket-Verbindung und simuliertem YouTube-Player: Medienauswahl, URL-Prüfung, Play/Pause/Seek, Counter-Ton/Lautstärke ohne Sprung, laufende Wasser-Wiedergabe mit Smartphone-Ton, Fehler/Wiederaufnahme, Tab-Übernahme, Trailer und Mobilansichten. Bestehender Pong-/Login-Ablauf geprüft. Echte YouTube-API sowohl lokal als auch über die veröffentlichte HTTPS-Herkunft erfolgreich mit Video-Metadaten geprüft; öffentlicher Bedienoberflächentest mit simulierten Stationsbefehlen. Physischer Hör-/Bildtest am LED-Counter steht nach Neuladen/Neustart von Electron aus. views.json ist bereits passend eingerichtet. sources/ unverändert.
+[https://www.tinetronics.de/mutec/video/README-YouTube.md Technische Anleitung] · [https://developers.google.com/youtube/iframe_api_reference Offizielle YouTube-API] · [https://developers.google.com/youtube/terms/required-minimum-functionality Einbettung und Client-Identifikation]
+== YouTube: automatischer Start ohne Lautstärkeregler ==
+Update 21.10.2026: Der Lautstärkeregler ist für YouTube entfernt; der Ton bleibt am Counter. Lokale Filme behalten Smartphone-Ton und dessen Lautstärkeregler.
+„Video laden“ sendet die Videoauswahl; erst die Bestätigung des Counters löst unmittelbar Play aus. Kein zweiter Start-Klick und keine geschätzte Ladeverzögerung. Zeitposition und Wiedergabestatus kommen weiter vom Counter. Fehler und Verbindungsverlust verwerfen den vorgemerkten automatischen Start. Neue YouTube-Links verwenden den festen Player-Ausgangswert 100 Prozent. Die physische Audioanlage bestimmt die gewünschte Lautstärke vor Ort.
+Drei Frontend-/Dokumentationsdateien vorab gesichert und veröffentlicht. Geprüft über echte lokale WebSocket-Verbindung mit simuliertem YouTube-Player: automatischer Start, versteckter Regler, Play/Pause/Seek, laufendes Wasser mit Smartphone-Ton und Regler, URL- und Einbettungsfehler mit Wiederaufnahme, Tab-Übernahme, Trailer und schmale Mobilansichten. Kein Relay-/Electron-Update. Smartphone-Seite neu laden.
+== Automatische Auswahl und Trailer bei Inaktivitaet ==
+Stand 21.10.2026: Frontend aktualisiert, Relay-Paket vorbereitet und auf VPS getestet; die Server-Aktivierung erfolgt noch durch root mit <code>bash /home/clawtronics/mutec-idle-update/apply-idle-update.sh</code> bei freier Station 50.
+Abgelaufene Steuersitzungen führen automatisch zur Auswahl, sowohl bei API-Fehler als auch WebSocket-Code 4001. Ein weiterhin gültiges MegBes-Ticket bleibt erhalten. Ist das Ticket selbst ungültig, gilt weiter die normale Ticket-Prüfung/Dankeseite. Reine Netzfehler werden nicht als Sitzungsablauf behandelt; doppelte Steuerverbindungen geben keine fremde Sitzung frei. Gäste mit eigener angemeldeter Ticket-Sitzung kehren ebenfalls zur Auswahl zurück, anonyme Gäste behalten die Dankeseite. Eine alte automatische Rückkehr kann einen zwischenzeitlich neu gescannten Tab nicht übernehmen.
+Smartphone-Seiten verlängern die Sitzung im Hintergrund nicht mehr. Beim Wiederanzeigen wird geprüft. Die vorhandene Steuersitzungsfrist beträgt ca. 45 Sekunden; nach Relay-Update startet auch deren automatischer Ablauf 50-Trailer vor der Freigabe. Bei Fehler wird Steuerung sofort gesperrt und die Trailer/Freigabe zur Wiederholung vorgemerkt. Vor jedem erneuten Trailer werden gültiges Ticket und die eigene REMOTE-Belegung geprüft; IDLE oder fremde Belegungen werden nicht umgeschaltet. Der vorhandene interne Ticketablauf-Wächter bleibt für tatsächlich abgelaufene Tickets unverändert zuständig.
+Neue Serverfristen: 60 Sekunden ohne Bedienung nach Spiel-/Filmende, sonst 120 Sekunden ohne Eingabe. Unveränderte Steuer-Keepalives, Statusmeldungen und Sensorrauschen zählen nicht als Bedienung. Tatsächliche Tasten-/Touch-/Texteingaben werden bei Erneuerung gemeldet; zulässige geänderte Steuerdaten beider Spieler zählen ebenfalls. Spiel-Endebildschirme werden nicht durch weiterlaufende Steuerimpulse künstlich aktiv gehalten. Ein laufender Film mit aktiver Smartphone-Verbindung und frischer Display-Rückmeldung bleibt erhalten. Gemeinsam genutztes Farbenspektakel kehrt erst beim letzten Teilnehmer zum Trailer zurück. Aquarium-Editoren reservieren weiterhin keinen Counter und schalten fremde Anwendungen nicht um.
+Servertests lokal und auf dem VPS bestanden, einschließlich Rückkehr, Fehler/Wiederholung, fremder Besitzer, IDLE, ungültiger Tickets, gemeinsamem Farbraum, Schluss-/Eingabefristen, Filmwiedergabe und Gastrechten. Browserprüfungen: automatischer Rückweg ohne Fehlbox, Ticket erhalten, Hintergrund ohne Erneuerung, einmalige Aktivitätsmeldung statt Heartbeats, alte Seite/Media-Sitzung und gleichzeitiger Ablauf/Tab-Scan. Bestehender Pong-/Login-Ablauf geprüft.
+Frontend-Sicherung und Paket: outputs/MUTEC-Inaktivitaet-Frontend-Sicherung-20261021 und MUTEC-Inaktivitaet-Frontend.zip. Serverpaket: MUTEC-Inaktivitaet-server.tar.gz mit Prüfsumme und apply-idle-update.sh. Installer prüft den aktuellen Code-Ausgangsstand, sichert geänderte Dateien, führt alle Tests aus und startet nur den Relay neu. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, sources/ und Ticketablauf-Wächter bleiben erhalten. Nach Aktivierung liefert /health idleReturn:true; Smartphone-Seiten neu laden.
+== Inaktivitaets-Update aktiviert, 21.10.2026 ==
+Root-Installation vom Betreiber bestätigt: 204 Tests bestanden, keine Fehler; /health meldet idleReturn:true. Relay und Ticketablauf-Wächter sind active. Sicherung: /var/backups/mutec-realtime/idle-20261021T161249Z-2398303. Die zuvor als vorbereitet dokumentierte Trailer-Automatik ist damit aktiviert. Smartphone-Seiten neu laden, damit die neue Hintergrund-/Ablaufbehandlung verwendet wird.
+Die Testliste umfasst aktuelle Funktionen sowie weiterhin vorhandene ältere Schnittstellen (z. B. QR-/Anfrage-Beitritt). Testnamen beschreiben nicht zwingend die aktuelle Benutzeroberfläche. Solange solche Schnittstellen unterstützt werden, bleiben ihre Rechte-/Ablaufprüfungen sinnvoll. Bereinigung erst zusammen mit gezielter Entfernung ungenutzter Schnittstellen. Künftige Installationsausgaben sollen Zusammenfassung und Fehler anzeigen und die vollständigen Testergebnisse in einem Detailprotokoll ablegen.