2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGit	85101176d2	Zwei fuehren die Sendung: DogFather und die rechte Hand ... Filipe, 28.09.2026: „die rolle dogfather und vanvan sollen alles sehen und bereit machen auch vorher. nur die zwei sollen alles sehen, vorbereiten und einschakten koennen." DREI DINGE AENDERN SICH, UND ZWAR GENAU DIESE DREI 1. VORBEREITEN UND EINSCHALTEN duerfen jetzt beide -- einstellen, Vorbereitung, auf Sendung, beenden, Gaeste holen und entfernen, stummschalten, Anordnung, Video steuern. Beide dasselbe; es gibt hier keinen Ersten und keinen Zweiten. Das ist eine AUFGABE und kein Rang: Wer die Sendung fuehrt, bedient die Technik. 2. „ALLES SEHEN" heisst die Namensliste derer, die zusehen. Die bekamen bisher auch die linke Hand und die Modis, weil sie moderieren duerfen. Das war eine Vermischung zweier Dinge, die nichts miteinander zu tun haben: Wer einen Beitrag wegnehmen darf, muss deshalb nicht wissen, wer im Saal sitzt. Ab jetzt bekommt die Liste nur, wer auf der Buehne steht. Die Moderation bleibt unveraendert bei DogFather, beiden Haenden und den Modis -- einen Beitrag wegzunehmen ist weder „alles sehen" noch „vorbereiten" noch „einschalten", sondern dasselbe, was sie im Treff ohnehin tun. 3. WER AUF SENDUNG DRUECKT, IST IM BILD. Vorher stand als Host, wer zuletzt etwas eingestellt hatte. Mit zwei Leuten, die vorbereiten duerfen, waere das eine Falle: VanVan richtet am Nachmittag alles ein, Filipe drueckt abends auf Sendung -- und im Bild stuende VanVans Name, waehrend Filipe redet. Beim Einstellen wird `host_id` deshalb nur noch gefuellt, wenn dort noch niemand steht (damit die Ankuendigung „Als Naechstes" jemanden nennen kann). Wer die Sendung FUEHRT, entscheidet sich beim Einschalten. GEPRUEFT IN BEIDE RICHTUNGEN Nur zu messen, wer darf, hiesse: Die Tuer laesst sich spaeter weit aufmachen, ohne dass etwas rot wird. pruef-reaktion misst deshalb auch, wer ausdruecklich NICHT darf -- und dass es genau zwei sind: genau zwei fuehren die Sendung: admin, hand die rechte Hand darf einstellen / vorbereiten / Anordnung linke, modi, gast: duerfen nicht einstellen (403) ein Modi holt niemanden dazu (403) wer eingeschaltet hat, fuehrt die Sendung (Filipe) drueckt die rechte Hand, fuehrt sie (VanVan) die rechte Hand sieht, WER dabei ist -- sie fuehrt mit linke, modi: moderieren, bekommen die Namensliste aber nicht admin/hand: sehen Regiepult -- linke/modi/gast: nicht Das Regiepult haengt an `ich.host` und an nichts sonst. Ein zweiter Ort, an dem der Browser dieselbe Frage noch einmal beantwortet, waere der, der spaeter abweicht -- und dann stuenden Knoepfe da, die mit 403 antworten. pruef-reaktion 74 -> 88 Punkte, 0 Fehler. Dazu gruen: meldungen 8, rechtetafel 19, verborgen 25, modi-verborgen 85.	2026-09-28 02:01:32 +02:00
DogFatherGit	5d89d108f9	Die Reaction: zusammen schauen, live, mit Kamera und Chat ... Filipes Kurznotiz vom 28.09.2026, von links nach rechts: Kachel sichtbar -> geschlossen -> Vorbereitung -> Wartebereich/ Chat -> Countdown -> LIVE -> Reaction + Gaeste + Chat + PayPal -> Ende DREI STAENDE, NICHT SIEBEN „Wartebereich" und „Countdown" sind keine eigenen Zustaende, sondern das, was „Vorbereitung" auf dem Bildschirm TUT. Drei Staende, die sich gegenseitig ausschliessen, sind pruefbar; sieben, von denen sich vier ueberlappen, sind es nicht. DAS VIDEO LAEUFT NICHT UEBER DIESEN SERVER Naheliegend waere: Der Host spielt ab, alle sehen seinen Bildschirm. Das waere aus zwei Gruenden falsch. Rechtlich ist ein weitergesendetes YouTube-Video eine oeffentliche Wiedergabe -- genau die Sache, fuer die Kanaele gesperrt werden. Und technisch kostet es Bandbreite und Qualitaet. Jeder Zuschauer laedt das Video deshalb SELBST. Uebertragen wird nur der Spielstand: Kennung, laeuft/pausiert, Sekunde. Das sind ein paar Byte, jeder sieht es in voller Qualitaet, und alle sind auf derselben Sekunde. Nachgefuehrt wird erst ab anderthalb Sekunden Abweichung -- ein Player, dem man jede Sekunde eine neue Position gibt, ruckelt sichtbar. DIE KAMERAS LAUFEN DIREKT VON MENSCH ZU MENSCH Ueber denselben Weg wie die Anrufe im Haus (seit 18.09.), nur mit mehr Empfaengern. Das hat eine Grenze, und sie ist gerechnet, nicht geraten: Bei 360p und rund 350 kbit/s sind zwoelf Zuschauer etwa 4 Mbit/s Upload beim Host. Darueber schaltet die Sendung von selbst auf Ton um -- wer keine Kamera mehr bekommt, hoert alles, sieht das Video und kann schreiben. Ehrlicher als eine Verbindung, die stockt, und sichtbar im Regiepult. Heute sind es elf Menschen im ganzen Haus (gemessen: 1 admin, 1 hand, 1 linke, 4 modi, 4 gast). Die Grenze ist weit weg -- sie steht trotzdem drin, weil sie sonst erst auffaellt, wenn es zu spaet ist. DIE SEITE IST ANDERS GEBAUT ALS JEDE ANDERE IM HAUS Ueberall sonst: Kacheln, Karten, Listen -- man liest, entscheidet, geht wieder. Hier sitzt man. Eine Stunde, mit anderen, auf EINE Sache schauend. Deshalb kein Raster, sondern ein SAAL: grosse Flaeche fuer das Video, Kamerabilder als schwebende Fenster darueber, der Chat als Schiene daneben. Die Seite scrollt nicht -- ein Video, das beim Tippen im Chat nach oben rutscht, ist der schnellste Weg, dass jemand aufhoert zu schreiben. Fuer den Host ein REGIEPULT: vier senkrechte Regler nebeneinander wie an einem Mischpult, darueber die Sendung, daneben Gaeste und Anordnung, unten drei grosse Knoepfe. Es SCHIEBT den Saal, es deckt ihn nicht zu. Die Kachel traegt ihren Zustand als Farbe: grau geschlossen, bernstein in Vorbereitung, rot auf Sendung. Keine Ton-Nummer -- der Farbraum ist bei 46 voll, und sie braucht auch keine. PAYPAL: EINE QUELLE Der Knopf nimmt den Weg, der auf der Unterstuetzen-Seite hinterlegt ist -- derselbe Eintrag, dieselbe Pflege. Ist dort nichts eingetragen oder steht er auf unsichtbar, erscheint hier kein Knopf. Eine geratene Adresse ist an dieser Stelle die gefaehrlichste aller Abkuerzungen. ======================================================================= ACHT FEHLER, DIE OHNE MESSUNG LIVE GEGANGEN WAEREN ======================================================================= 1. `data-live` WAR SCHON VERGEBEN. Die Draussen-Kachel bekommt es, sobald Filipe auf Twitch sendet. Meine Regel haette ihr waehrend jedes Streams die Farbe genommen -- genau dann, wenn sie wichtig ist. Heisst jetzt `data-sendung`, und pruef-reaktion haelt beides auseinander. 2. DIE INHALTSRICHTLINIE HAETTE YOUTUBE LAUTLOS GESPERRT. Die Datei warnt an genau dieser Stelle selbst davor: Am 27.08.2026 hat `frame-src 'none'` den Musik-Knopf stillgelegt -- der Knopf reagierte, das Feld ging auf, und wo die Player sein sollten, blieb es leer. Hier waere das Ergebnis eine schwarze Leinwand vor Publikum gewesen. youtube-nocookie.com fuer den Rahmen (setzt keine Werbekennungen), www.youtube.com fuer die Einbett-API, i.ytimg.com fuer die Vorschaubilder. 3. KAMERA UND MIKROFON WAREN GESPERRT. Dieselbe Falle, vor der index.js selbst warnt -- und die am 18.09. schon einmal zugeschlagen hat. Die Ausnahme ist jetzt eine benannte MENGE statt eines zweiten Sonderfalls, und pruef-kamera-richtlinie.mjs haelt sie GEGEN DEN QUELLTEXT: Welche Seite laedt ein Skript, das getUserMedia aufruft? Genau die muss drinstehen -- und keine andere. Eine Liste, die abgeleitet wird, kann nicht veralten. 4. ZWEI ANRUFE AN DIESELBE PERSON. Zwischen `await kameraHolen()` und dem Anlegen der Verbindung laeuft alles andere weiter; jeder Takt sagte wieder „den kenne ich noch nicht". Der Empfaenger antwortete auf beide Angebote, und die zweite Antwort traf eine Verbindung, die laengst stand. 5. DAS ANGEBOT GING HINAUS, BEVOR DER EMPFAENGER ZUHOEREN KONNTE. Gemessen: [spur] an [3] reaktion_signal | offen: [2,1] ... [spur] Strom auf fuer 3 Lenny Die Anmeldung ist ein gewoehnlicher Abruf und sofort durch, der Ereignisstrom eine stehende Verbindung. Der Host erfaehrt vom Neuankoemmling also zuverlaessig, BEVOR der zuhoeren kann. Die Richtung ist jetzt umgedreht: Wer bereit ist, BITTET um den Anruf -- er ist der Einzige, der das sicher weiss. Dazu ein eigener, schneller Takt (2,5 s) und eine Ruecknahme, wenn ein Angebot bei niemandem ankommt. 6. EIN VIDEO MIT TON STARTET NICHT VON ALLEIN. `videoWidth` war 640, das Bild kam also an -- und das Fenster blieb schwarz. Kein Fehler, keine Meldung, es passiert einfach nichts. Die Kameras starten jetzt stumm (stumm darf losgehen), ein Knopf schaltet den Ton frei, und die erste Beruehrung der Seite tut es ohnehin. 7. DIE LADE AM HANDY GING NICHT AUF. Gemessen: ein 390x775 grosser Saal mit 219 px Video und 556 px Leere darunter. Statt den Knopf zu reparieren, ist die Lade weg -- unter Kopfleiste und Video bleiben auf einem Telefon rund 550 px, das ist mehr Chat, als eine Lade je zeigen wuerde. Ein Zustand weniger ist besser als ein Zustand, der funktioniert. 8. `sendBeacon` KANN NUR POST. Beim Schliessen des Fensters wird ein gewoehnlicher Abruf abgebrochen; mein DELETE waere nie angekommen, und jeder haette zwei Minuten lang als anwesend gegolten. Dazu drei Funde der Hauspruefungen, alle von mir verursacht: 17 Schriftgroessen unter der Lesbarkeitsgrenze von 11,5 px, elf Maschinenworte ohne deutschen Satz, und ein Aufbewahrungseintrag ohne Rechtsgrundlage. ======================================================================= GEMESSEN pruef-reaktion 74 Punkte, 0 Fehler (11 Abschnitte) pruef-kamera-richtlinie 10 Punkte, 0 Fehler (neu, abgeleitet) mess-reaktion beide Kameras kommen an, 640 px, laufen -- beim Zuschauer UND beim Host. Diese Messung hat einen Rueckgabewert: Alles andere kann gruen sein, und trotzdem sitzt jeder vor einem schwarzen Rechteck. pruef-handy 180 (vorher 177), pruef-notizen 79, pruef-aufbewahrung 45, pruef-meldungen 8, pruef-css-klassen 33, pruef-struktur 35, pruef-crew-adresse 161, pruef-haus-trennung 100, pruef-start-ansicht 160 -- alle 0 Fehler.	2026-09-28 01:52:22 +02:00