a3ec55812749ae2157dc5bbd3653b0754abb2b85
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
a3ec558127 |
Reaction: der Gleichlauf rechnet ohne Uhrenvergleich
Filipe: „die videos muessen perfekt laufen wenn ich die reaktions
mache."
GEMESSEN, NICHT VERMUTET. mess-reaktion hat einen neuen Abschnitt:
Er liest den Spielstand am ECHTEN <video>-Element in beiden Browsern,
rechnet beide auf denselben Augenblick um und sagt, wie weit Host und
Zuschauerin auseinanderliegen. Die vorhandene Pruefung fragte nur, ob
Start und Stopp ANKOMMEN -- zwei Videos koennen beide laufen und
trotzdem zwanzig Sekunden auseinander sein.
vorher nachher
Im Lauf 0,12 s -0,04 s
Wer dazukommt 6,91 s 0,26 s
Uhr des Geraets 30 s vor -29,97 s 0,26 s
DER SCHLIMMSTE FUND: DIE UHR DES TELEFONS
Der Zuschauer rechnete `Date.now() - stand.gesendet`. `gesendet` kam
vom SERVER, `Date.now()` vom Geraet -- zwei Uhren, die nie jemand
verglichen hat. Wessen Telefon dreissig Sekunden vorgeht, schaute
29,97 s weiter als alle anderen. Kein langsames Netz, kein schwaches
Handy. Oertlich faellt das nie auf: Auf einem Rechner sind beide
Uhren dieselbe.
Jetzt geht ein ALTER hinaus statt einer Uhrzeit -- die Differenz
zweier SERVERzeiten. Der Empfaenger braucht dafuer gar keine Uhr,
nur eine Stoppuhr (`performance.now()`), und die haelt Zeitumstellung
und Aufwachen aus dem Ruhezustand aus.
WEITER
* WER DAZUKOMMT, STEIGT RICHTIG EIN. Der gespeicherte Stand war so
alt wie der letzte Takt des Hosts; neue Spalte `sekunde_am` sagt,
wann er galt.
* DAS TEMPO GEHT IN DIE HOCHRECHNUNG EIN. Bei 2x laeuft die Videouhr
doppelt so schnell -- das fehlte ganz.
* JEDER RECHNET ALLE ZWEI SEKUNDEN SELBST NACH statt nur auf Zuruf.
Wer stockte, hing bis zu fuenf Sekunden hinterher.
* DER VORLAUF NACH EINEM SPRUNG WIRD GEREGELT, nicht geschaetzt --
gemessen wird der Rest, nicht die Ladezeit (siehe unten).
* PUFFERN IST AUCH IN DER TRANSPORTLEISTE KEINE PAUSE. Der
Start-Stopp-Knopf rief beim Puffern `playVideo()` -- wer Pause
drueckte, bekam „weiter". Lampe und Knopfbild flackerten bei jedem
Stocken. Die Lektion vom 29.09. war nur an einer Stelle eingeloest.
* DAS TEMPO MELDET UEBER `hostMelden()` statt ein zweites Mal von
Hand -- es hielt Puffern fuer Stillstand und hielt damit beim
Umschalten alle an.
* EIN VIDEO-RUNDRUF STATT DREI ABSCHRIFTEN. Beim Einbau hatte ich
zuerst nur eine nachgezogen; das Tauschen der beiden Videos haette
still die alte Rechnung weiterverschickt.
DREI EIGENE FEHLER UNTERWEGS, alle im Text festgehalten
1. ZWEI FUNKTIONEN HIESSEN `springen`. Meine „spring AUF die Stelle"
wurde von der vorhandenen „spring UM so viele Sekunden"
ueberschrieben -- lautlos, rueckwirkend fuer die ganze Datei. Ein
Zuschauer bei Sekunde 100, dem „geh auf 101" gesagt wird, waere
bei 201 gelandet. DREI BROWSERLAEUFE HABEN ES NICHT GEFUNDEN:
oertlich blieb der Abstand unter der Sprungschwelle, die Zeile
lief kein einziges Mal. Gefunden hat es erst eine Frage an die
ganze Datei -- die steht jetzt als Pruefung drin und wurde
nachgestellt (rot).
2. DER VORLAUF LERNTE NUR NACH OBEN. Gemessen wurde die Ladezeit
nach einem Sprung; ein Sprung in geladenes Material dauert aber
gar nicht, meldet nichts und lehrt nichts. Ergebnis: -0,95 s
stabil. Jetzt wird das ERGEBNIS geregelt statt der Ursache.
3. DER AUSREISSER VON 39,84 s WAR MEINE EIGENE MESSUNG -- der Block
davor schickt eine erfundene Position. Jetzt wird abgeklungen und
in Messreihenfolge ausgegeben.
GEPRUEFT
pruef-reaktion 421/0 (14 neue, darunter der Riegel gegen die
Rueckkehr der Uhrenrechnung und die Wache gegen doppelte
Funktionsnamen -- beide nachgestellt), mess-reaktion ohne ein
einziges ACHTUNG, pruef-buehne 38/0, pruef-struktur, pruef-
zwischenspeicher 34/0.
Schemaaenderung: ADD COLUMN sekunde_am. Datenbank vorher gesichert
und geprueft (integrity_check ok, 20 Personen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0fbd3f45b3 |
Die Chatkiste steht immer, Beenden raeumt auf -- und eine verspaetete Antwort ueberschreibt nichts Neueres mehr
Filipe, 30.09.2026: „wenn eine sendung beendet wurde soll alles
automatisch verschwinden. also von daten die da stehen von dem video."
Und: „mach dass ich die chat kiste immer sehe bitte und nicht erst
wenn das video läuft."
=====================================================================
1. BEENDET HEISST LEER
=====================================================================
Beim Beenden verschwinden Titel, YouTube-Adresse, Videotitel,
Vorschaubild, Beginn und das zweite Video samt seiner Stelle. Vorher
blieb alles stehen; beim naechsten Aufmachen stand dort der Titel der
letzten Sendung und ein Beginn, der in der Vergangenheit liegt.
ERST DER VERLAUF, DANN DAS LEEREN -- weg vom Schreibtisch heisst
nicht weg aus der Welt. Geprueft: Nach dem Beenden steht die Sendung
weiter in `reaktion_verlauf`, samt Video.
EINE FELDLISTE, NICHT ZWEI. Die Aufzaehlung stand in der
Zuruecksetzen-Route; jetzt brauchen sie zwei Wege. `SENDUNGS_FELDER`
und `PULT_EINSTELLUNGEN` stehen einmal oben. Zwei Abschriften waeren
die, die beim naechsten Spaltenzuwachs auseinanderlaufen -- genau so
sind am 11.09. drei Spalten mit Inhalt verlorengegangen.
Einstellungen (Bildaufteilung, Kameragroesse, Chatmodus) und die
Warteschlange bleiben -- die raeumt weiter nur „Alles zuruecksetzen"
ab. Wer nur vorbereitet und dann zumacht, behaelt seine Eingaben; das
ist eine Entscheidung und steht als Pruefung fest.
DAS FELD „BEGINN" WURDE NIE GELEERT, nur gefuellt:
`if (lage.beginnt_am && document.activeElement !== …)` -- zwei Fragen
in einer Bedingung, und die zweite beantwortete die erste
stillschweigend mit nein. Das betraf auch den vorhandenen
Zuruecksetzen-Knopf.
=====================================================================
2. DIE CHATKISTE STEHT IMMER
=====================================================================
Sie lag in `#teil-live` und ging mit ihm weg. Im Wartebereich stand
dabei woertlich „Der Chat ist schon offen" -- der Satz stimmte sogar,
der Server laesst dort schreiben (201, geprueft); zu sehen war der
Chat trotzdem nicht.
Die drei Haeute und die Schiene liegen jetzt in einem gemeinsamen
`.raum`: links wechseln die Haeute, rechts steht der Chat. Das Raster
wandert mit nach oben statt sich zu verdoppeln -- zwei
`grid-template-columns` fuer dieselbe Frage waren am 28.09. der
Grund, warum die Regieleiste null Pixel bekam.
Wer nicht schreiben darf, liest den Grund im Feld („Der Saal ist zu").
DER UMBAU HAT DREI DINGE VERSCHOBEN, und die Messung hat sie sofort
gefunden: Kino 0 px hoch, Spendenkarte bei x=1458 ausserhalb des
Bildes, „Kamera aus"-Schild kam nicht an. Eine Ursache: Zwei Regeln
(`grid-row: 2` und `grid-area: kino`) zielten auf die drei Haeute,
weil die frueher unmittelbar im Saal lagen. Gefunden hat das nicht
das Nachdenken, sondern eine Messung der ganzen Kette --
`teil-live 0x0 @1440,742` lag NEBEN dem Raum.
=====================================================================
3. „DER SAAL IST ZU" ERREICHTE NIEMANDEN, DER DARIN SASS
=====================================================================
`stand: "zu"` loescht `reaktion_dabei`, und `melden()` suchte seine
Empfaenger erst danach -- in genau dieser geleerten Liste. Die Seiten
der Zuschauer blieben auf „live" stehen.
`melden(art, daten, wer)` nimmt jetzt eine Empfaengerliste; die
Stand-Route bestimmt sie VOR jeder Aenderung.
UND EINE ZUGESPERRTE SEITE VERSTUMMTE FUER IMMER. War der Saal zu,
hielt `anschliessen()` jeden Takt an -- und Rundrufe bekam sie auch
keine, weil sie in keiner Liste mehr stand. Machte der Host wieder
auf, passierte bei allen mit offenem Reiter NICHTS. Nicht in dreissig
Sekunden: nie, bis jemand von Hand neu lud. Gemessen: Server sagt
„vorbereitung", die Seite zeigt „zu", auch nach 40 Sekunden.
Jetzt fragt eine geschlossene Seite alle 15 Sekunden nach -- der
ruhigste Zustand des Hauses, dort kostet das nichts.
=====================================================================
4. WER ZULETZT ANTWORTET, HAT NICHT RECHT
=====================================================================
Eine Abfrage ist Sekundenbruchteile unterwegs. Kommt in dieser Zeit
ein Rundruf an, ist SEIN Stand der neuere -- und trotzdem hat die
verspaetete Antwort ihn ueberschrieben.
Gemessen: Die Regie schaltet die Werbung auf Wechsel, der Rundruf
zeichnet ihn, und einen Augenblick spaeter steht wieder Laufband.
Eine feste Wartezeit in der Messung hatte das zugedeckt; es fiel
erst auf, als ich sie durch eine echte Bedingung ersetzte.
Drei Runden Raten lagen daneben. Gefunden hat es eine Mitschrift der
Aufrufkette:
wechsel:2 @ EventSource
laufband:2 @ zeichnen < standHolen < signalEmpfangen
Eine Folgenummer zaehlt jeden angekommenen Rundruf. Jede Abfrage, die
die Seite VON SICH AUS macht -- nach dem Verbindungsaufbau, im
geschlossenen Saal, bei jedem Verbindungssignal, nach einer
abgelehnten Anwesenheitsmeldung, und der Anwesenheitstakt selbst --
verwirft ihr Ergebnis, wenn inzwischen etwas Neueres da war.
Abfragen nach einer EIGENEN Handlung bleiben hart: Sie bringen Dinge
mit, die kein Rundruf traegt (die Verwaltungslisten der Regie). Die
Unterscheidung steht am Aufruf, nicht in einer Bedingung im Inneren.
=====================================================================
5. UND DIE MESSUNGEN WARTEN NICHT MEHR AUF DIE UHR
=====================================================================
Feste Wartezeiten sind dieselbe Falle wie feste Schwellen: Sie
stimmen, bis daneben etwas langsamer wird, und melden dann einen
Fehler, den es nicht gibt. Zweimal ist mir das in einer Stunde
passiert -- einmal beim Band, einmal bei den Ecken. Der Werbeblock
wartet jetzt fuenfmal auf das Ergebnis, der Gleichlauf viermal; laeuft
eine Frist ab, ist es ein echter Befund.
Die erste Fassung der Gleichlauf-Gegenprobe war selbst falsch -- sie
hielt das Selbstheilen des Systems fuer einen Fehler.
Neu in mess-reaktion: „Die Chatkiste in jedem Zustand" (alle drei,
mit Breite und Sperrgrund) und „Beendet heisst leer (im Pult)" -- dort
gemessen, wo Filipe hinsieht, nicht in der Datenbank.
Neu in pruef-reaktion (+14): das Leeren, die Gegenprobe „vorher war
etwas drin", der Verlauf bleibt, und die Entscheidung „wer nur
vorbereitet hat, behaelt seine Eingaben".
Gemessen: mess-reaktion dreimal hintereinander 0/0, pruef-reaktion
407/0, pruef-css-klassen 37/0, pruef-struktur 44/0, pruef-tippziele
13/0, pruef-haus-seiten 38/0, pruef-haus-trennung 100/0, pruef-buehne
38/0, pruef-push-ziel 38/0, mess-buehne 0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2c3b90d75c |
Benachrichtigungen: die Reaction laedt ein, jedes Haus bekommt sein Gesicht -- und die Videos haengen nicht mehr
Filipe, 29.09.2026: „ich will dass du die benarichtigungen
perfektionierst. dogfather und alle anderen sollen die
benachrichtigungen perfekt von dieser seite hier bekommen."
Und dazu, mit einer Bildschirmaufnahme: „wieso haengen die videos
immer."
=====================================================================
1. WARUM DIE VIDEOS HAENGEN -- zwei Zeilen, eine Rueckkopplung
=====================================================================
Die Aufnahme zeigt den YouTube-Zaehler bei 0:13 von 31:34, vier
Bilder lang unbewegt, in der Mitte der Ladering.
a) `hostMelden()` rechnete `laeuft = getPlayerState() === 1`.
Zustand 3 heisst PUFFERN -- „ich will spielen, mir fehlen
gerade Daten". Der Host meldete in diesem Moment „laeuft
nicht", und zwar sofort, weil `onStateChange` bei jedem
Zustandswechsel meldet.
b) `empfaenger()` fuegt den Host ausdruecklich hinzu, und
`folgen(d)` lief im Ereignisstrom fuer alle -- auch fuer ihn.
Seine eigene Meldung kam zurueck und traf dort auf
if (!stand.laeuft && getPlayerState() === 1) pauseVideo();
Der Host puffert eine halbe Sekunde, laeuft weiter -- und wird vom
Echo seines eigenen Pufferers angehalten. Bei einem 31-Minuten-Video
passiert das in den ersten Sekunden zuverlaessig.
Und alle Zuschauer bekamen bei JEDEM Pufferer des Hosts ein
Pause-Play-Paar. Das ist das Ruckeln, das man fuer die eigene
Leitung haelt.
GEMESSEN, NICHT HERGELEITET (mess-reaktion):
vorher Host=laeuft -> Pufferer gemeldet -> Host=pause
nachher Host=laeuft -> Pufferer gemeldet -> Host=laeuft
Drei neue Messungen, jede mit Gegenprobe:
· ein gemeldeter Pufferer haelt den Host nicht an
· ein ECHTES Anhalten (Knopf gedrueckt) haelt alle an -- sonst
waere das Erste mit kaputtem Gleichlauf bezahlt
· beim Puffern meldet der Server `laeuft=true`; ist der Pufferer
nicht herzustellen, sagt die Messung das (dritter Ausgang)
Beide Behebungen einzeln zurueckgenommen: beide Male rot.
Die erste Fassung der Gegenprobe war selbst falsch -- sie hielt das
Selbstheilen des Systems (der Host meldet alle fuenf Sekunden die
Wahrheit) fuer einen Fehler. Deshalb drueckt sie jetzt den Knopf,
statt eine Meldung zu faelschen.
=====================================================================
2. DIE REACTION LAEDT EIN
=====================================================================
Nachgemessen war `workspace-reaktion.js` STUMM: kein einziges
`benachrichtige`. Beim Einschalten lief `melden("reaktion", ...)`
ueber den Ereignisstrom -- also nur an Leute, die die Seite ohnehin
offen haben. Das Kino machte auf, und die Einladung verliess das Haus
nie. Dasselbe Muster wie bei den Bewerbungen am 23.09.
Neue Art `reaktion_live`, eigene neben `dogfather_live`: Das eine ist
sein Stream auf TikTok, das andere das Kino hier im Haus.
Eingeladen wird, wer ein Geraet hat und NICHT der Agentur gehoert
(`AGENTUR_ROLLEN` -- keine neue Liste). Nicht der, der eingeschaltet
hat. Und nicht zweimal: Eine Bremse von zwei Stunden faengt den
Neustart ab, denn das Merkmal haengt an `gestartet_am` und das wird
bei jedem Wechsel nach live neu gesetzt.
Geprueft Ende zu Ende in pruef-reaktion (+10): Sendung geht auf
Sendung, danach stehen genau fuenf Einladungen in `push_verschickt` --
rechte Hand, linke Hand, Modi, zweimal Community. Nicht der Host,
nicht die Creatorin. Einladung abgeschaltet: sechs Fehlschlaege.
=====================================================================
3. DARF DAS NACHTS KOMMEN? -- drei Antworten statt zwei
=====================================================================
Hier stand `art === "test" || art === "anruf"`, 230 Zeilen von der
Artenliste entfernt. Am 18.09. hat das eine Nacht lang alle Anrufe
verschluckt; behoben wurde damals dieser eine Fall.
GEMESSEN AM LIVE-BESTAND: `dogfather_live` ging an allen sieben
Abenden vom 22. bis 28.09. zwischen 20:28 und 21:06 raus -- jedes Mal
knapp vor der Sperre um 22 Uhr. Geht Filipe einmal um 22:05 live,
bekommt niemand etwas, und niemand erfaehrt warum.
`ruhe` steht jetzt an der ART:
"immer" (Vorgabe) 22-7 gesperrt -- Erinnerungen
"spaet" nur 1-7 -- etwas laeuft GERADE
"nie" nie -- ein Mensch wartet am Hoerer
=====================================================================
4. JEDES HAUS BEKOMMT SEIN GESICHT
=====================================================================
Im Service Worker stand fest `workspace-192.png`. Von acht Menschen
mit angemeldetem Geraet gehoeren fuenf ins Crew-Haus -- die sahen auf
jeder Benachrichtigung das Symbol des Hauses, in dem sie nicht
arbeiten.
Entschieden wird es auf dem SERVER: Im Browser stuende sonst die
verborgene Crew-Adresse in einer Datei ohne Anmeldung (der Befund vom
21.09. bei crew-haus.css) -- und es waere eine zweite Fassung der
Hausteilung. Zweistufig, beide Stufen gibt es schon: die Zielseite,
wenn sie in genau ein Haus gehoert (GEHOERT_ZU_ADRESSE), sonst
`AGENTUR_ROLLEN`.
=====================================================================
5. DAS ABZEICHEN WAR EIN KLOTZ
=====================================================================
`badge` ist das winzige Zeichen in der Statusleiste; Android benutzt
davon NUR den Alphakanal. Dort stand dasselbe `workspace-192.png` --
ein vollflaechiges Quadrat ohne Transparenz, also ein ausgefuellter
Klotz. Es stuerzt nichts ab, deshalb faellt es niemandem auf.
`assets/img/abzeichen-96.png`: der gefuellte Umriss des Huskys, weiss
auf durchsichtig, 3,5 KB. Drei Fassungen gebaut und bei ECHTER Groesse
(24 px) verglichen -- Strichbild zerfaellt, Flaeche traegt.
`server/helfer-png-alpha.mjs` liest den Alphakanal wirklich (PNG
auspacken, Zeilenfilter zuruecknehmen). Eine Pruefung auf „die Datei
gibt es" haette den Klotz nie gefunden -- die Datei gab es ja. Die
Gegenprobe ist der alte Zustand selbst: dieselbe Rechnung meldet auf
`workspace-192.png` „kein Alphakanal, Deckung 100 %".
Das Abzeichen liegt NICHT bei den App-Symbolen -- `pruef-struktur`
verlangt dort zu jedem Namen den vollen Satz und hielt es fuer eine
neue App. Der Waechter hat recht: Ein Abzeichen ist kein App-Symbol.
=====================================================================
Gemessen: mess-reaktion 0, pruef-reaktion 393/0 (+10),
pruef-push-ziel 38/0 (+27), pruef-push 24/0, pruef-push-weg 20/0,
pruef-glocke 36/0, pruef-struktur 44/0, pruef-haus-trennung 100/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a43bc565ec |
Werbeeinblendung fuer die Reaction: Laufband, Wechsel und zwei Bilder in sechs Ecken
Filipe: „ich will dass du auch perfektionierst dass ich einen banner durchlaufen kann, oder erscheinen lassen kann mit werbung drauf ... und ich will auch das dogfather logo oben rechts links unten rechts links genau wie oben unten mittig, so dass ich es wegmachen und hinzufuegen kann." DAS BAND Zwei Arten: „Laufband" zieht die Botschaften von rechts nach links, „Wechsel" blendet sie nacheinander ein. Ein Rabattcode gehoert in den Wechsel -- wer „DOGI10" lesen will, waehrend es wandert, hat es gesehen und nicht behalten. Die Dauer ist einstellbar (8-40 s). Das Band ist Glas, kein Balken: ein Verlauf, unten dicht genug, dass jede Schrift traegt, oben offen. Man sieht das Video weiter. Das Laufband traegt die Folge ZWEIMAL. Wandert es um 50 % seiner Breite, steht die zweite dort, wo die erste war, und der Sprung zurueck ist unsichtbar. Ohne sie entstuende am Ende jedes Durchlaufs eine leere Flaeche -- das sieht aus, als sei die Einblendung abgestuerzt. Wer weniger Bewegung eingestellt hat, bekommt den Wechsel statt des Laufbands -- nicht „aus". Die Werbung soll auch dann wirken. DER RABATTCODE Ein Wort in Grossbuchstaben mit einer Ziffer darin bekommt eine eigene Flaeche in Bernstein: „DOGI10" ja, „VANVAN" nicht. Er ist der einzige Teil der Botschaft, den jemand ABSCHREIBEN soll. Der Text wird NIE als HTML eingesetzt -- die Kennzeichnung baut echte Elemente. Sonst waere ein Eingabefeld im Regiepult ein Weg, fremdes Markup in den Stream zu bringen. DIE ZWEI BILDER Der Husky und der Haekelhase aus der Zusammenarbeit mit VanVan, jeweils an einem von sechs Plaetzen: oben und unten, je links, mittig, rechts -- oder aus. Links und rechts mittig gibt es mit Absicht nicht: dort liegen bei jedem Videodienst die Bedienelemente. Zwei Bilder auf denselben Platz werden abgelehnt (400 ecke_belegt) -- sie laegen uebereinander, und man saehe von beiden nichts. Wer unten steht, weicht dem Band aus, und die Spendentafel rueckt hoch. Beides im Stilblatt ueber `:has`, nicht im Programm: Das Band kennt die Tafel nicht und die Tafel kennt das Band nicht. Der Husky ist schwarz und laege auf dunklem Videobild als Silhouette in der Nacht. Zwei weiche helle Schatten legen eine Kontur darum -- dieselbe Loesung, die jeder Sender fuer sein Wasserzeichen nimmt. IM STREAM, NICHT NUR IM SAAL Beides laeuft in der Buehnenquelle mit, die OBS abfilmt, mit groesserer Schrift (24 statt 18 px) -- ein Stream wird auf einem Handy gesehen, oft in einem Viertel des Bildes. Gemessen: die OFFENE Quelle zieht eine Umschaltung nach, ohne dass die Szene neu geladen werden muss. EINE QUELLE, NICHT DREI `werbungStand()` steht in `reaktion-tabellen.js` und wird von Saal, Regie und Buehne aufgerufen. Erst standen dort drei Abschriften derselben Abfrage; beim Entfernen der Datenbank-Kennung habe ich eine davon geaendert, und die anderen lieferten sie weiter. WAS DIE PRUEFUNGEN DABEI GEFUNDEN HABEN - pruef-buehne: Die Botschaften trugen ihre Datenbank-Kennung in die OBS-Auskunft, die nur mit einem Schluessel geschuetzt ist. Die Feldliste geht jetzt zwei Ebenen tief -- eine abschliessende Liste, die nur die oberste kennt, laesst sich umgehen, indem man ein Feld in ein vorhandenes Objekt legt. - pruef-reaktion: Acht Fehlerwoerter ohne deutschen Satz. Nachgetragen im Hausstil: was nicht geht UND was stattdessen. - pruef-struktur: Die Suche nach totem CSS las `buehne.html` und `tafel.html` nicht -- eine Ausnahme, die fuer eine ganz andere Frage gemacht war (Startbildschirm-Symbol). Sie haette verlangt, `.obs-buehne` zu loeschen, also die Regel, die den Stream traegt. - pruef-tippziele: Erkannte als Anhebung nur `min-height`/`min-width`. Ein `height: 44px` im Fingerblock hebt genauso -- Fehlalarm, und ein Fehlalarm an einer Pruefung, die nach jeder Aenderung laeuft, wird weggeklickt. Zwei Gegenproben dazu. - mess-reaktion: Die Regieleiste am Handy wurde gegen die feste Zahl SIEBEN geprueft und meldete „zeigt nur 8 von 7". Sie zaehlt jetzt selbst. - mess-buehne: Die Konsolenmeldung zeigte dauerhaft vier Fehlschlaege, alle von den Pruefungen selbst bestellt. Jetzt eng gefiltert, benannt, mit Gegenprobe -- und ein UNERWARTETER Fehlschlag in der Quelle, die in den Stream geht, faellt ab sofort durch. Gemessen: mess-reaktion 0, mess-buehne 0, pruef-reaktion 383/0, pruef-buehne 38/0, pruef-tippziele 13/0, pruef-struktur 44/0, pruef-css-klassen 0, pruef-haus-trennung 100/0, pruef-haus-seiten 38/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
99e62eebbe |
Regieplatz, Bildschirm teilen, Zuruecksetzen und der Preis
Vier Sachen aus Filipes Ansagen vom 28.09.2026.
=======================================================================
1. DER REGIEPLATZ
"kann das nicht bissl aufgeteilt sein auf links und rechts und eine
barre unten in der mitte. kannst du das nicht hoch professionell
machen und hochwertig vom aussehen?"
Die Teilung folgt dem, was WANN gebraucht wird:
LINKS Was laeuft. Das liest man.
RECHTS Was eingetragen wird. Das tippt man VOR der Sendung.
UNTEN Der Transport. Den fasst man WAEHREND der Sendung an.
Vorher stand alles in einem Stapel, und wer im Live an den Play-Knopf
wollte, musste an den Eingabefeldern vorbeiscrollen. Der Play-Knopf
ist jetzt rund und 58 px -- der einzige, den man blind treffen muss,
und die Form unterscheidet ihn schon vor dem Hinsehen.
UND EIN FUND, DEN NUR DIE MESSUNG FAND: Nach dem Umbau lag die Leiste
bei y=986 in einem 900 Pixel hohen Fenster. Die Rechnung ging auf
(links, rechts, Leiste darunter) und das Ergebnis war trotzdem
falsch. Jetzt klebt sie (`position: sticky`) -- unten, wie gewollt,
und immer sichtbar. Ihr Grund musste dafuer dicht werden: eine
halbdurchsichtige Leiste, durch die Text scrollt, ist die Flaeche,
auf der man sich im Live verliest.
=======================================================================
2. DEN BILDSCHIRM TEILEN
"waere es nicht einfach eine bildschirm uebertragung zu installieren
und es zu perfektionieren?"
Ja -- der Weg war schon da: Die Kamerabilder laufen als
Direktverbindung von Mensch zu Mensch. Geteilt wird deshalb AN STELLE
der Kamera; `replaceTrack` tauscht die Bildspur in jeder bestehenden
Leitung aus, ohne dass eine einzige neu ausgehandelt werden muss.
Eine zweite Spur daneben waere eine zweite Verhandlung je Zuschauer,
und jede davon kann scheitern.
Vier Dinge, die sonst schiefgegangen waeren:
- Wer waehrenddessen dazukommt, bekommt den Bildschirm und nicht
das Gesicht.
- Das eigene Fenster zeigt, was die anderen sehen -- sonst waere es
die eine Anzeige, der man nicht trauen kann.
- Der Stopp-Knopf des Browsers wird gehoert; sonst bliebe die Seite
auf "teilt" stehen und sendete ein totes Bild.
- Der Kameraknopf wird grau, solange geteilt wird. Er haette keine
Wirkung mehr -- und ein Knopf, der still nichts tut, ist
schlimmer als keiner.
Ein Bildschirm wird ausserdem NICHT zugeschnitten: `cover` ist fuer
ein Gesicht richtig, bei einem Schreibtisch faellt links und rechts
genau das weg, worum es geht.
UND DIE WAHRHEIT STEHT AN DER BEDIENUNG: Netflix, Disney+ und Prime
bleiben beim Teilen schwarz (Widevine schaltet den Videobereich ab --
auf Discord und Zoom ist es genauso), und einen Film weiterzusenden
waere eine oeffentliche Wiedergabe. Wer das erst erfaehrt, nachdem im
Stream zehn Minuten ein schwarzes Rechteck stand, erfaehrt es zu
spaet.
=======================================================================
3. ALLES ZURUECKSETZEN
"brauch ich auch noch einen button wo ich alles easy zuruecksetzen
kann."
"Alles" heisst: der Schreibtisch, nicht das Gedaechtnis. Geleert
werden Titel, Video, zweites Video, Vorschaubild, Beginn,
Warteschlange, Gaesteliste; Anordnung, Kameragroesse, Ecke, Tempo und
Chatmodus gehen auf Vorgabe.
NICHT ANGETASTET werden Spenden, die Dogen der Leute, der Chatverlauf
und die Massnahmen der Moderation. Eine bezahlte Spende aus den
Buechern zu nehmen waere eine Faelschung; eine stillschweigend
aufgehobene Sperre waere eine Entscheidung, die niemand getroffen
hat. Beides steht nebeneinander im Dialog, BEVOR etwas passiert -- ein
"Bist du sicher?" ohne diese Liste ist keine Frage, sondern eine
Huerde.
Im Live ist der Knopf grau und sagt warum. Und die Spalten stehen
einzeln da statt als "alles ausser": Eine Ausnahmeliste waechst still
mit jeder neuen Spalte mit, und dann loescht das Zuruecksetzen
irgendwann etwas, das es nie loeschen sollte.
=======================================================================
4. DER PREIS BEI DEN DOGEN
"da muss ich auch sehen so viel dogen sind so viel euro. damit ich
auch immer weiss was es ist. aber nur ich. die leute sollen nur sehen
was dogen kosten."
Das ist keine Ruecknahme von "nie Geld", sondern ihre Grenze. Die
Regel war richtig fuer alles, was ANZEIGE ist -- Karte, Stream, Chat,
Punktestand -- und falsch fuer die eine Stelle, an der jemand KAUFT.
GENAU ZWEI AUSNAHMEN, und die Pruefung nennt sie beim Namen statt die
Regel aufzuweichen:
knoepfe[].cent fuer alle -- der Preis am Kaufknopf
kurs_cent_je_doge nur fuer die Leitung
DIE ERLAUBNIS STECKT IN DEN DATEN UND NICHT IN EINEM `if`. Ein
Zuschauer hat den Kurs nicht und kann deshalb GAR KEINEN Preis
ausrechnen -- auch nicht, wenn eine spaetere Zeile es versuchte. Eine
Abfrage "darf der das sehen?" in der Oberflaeche waere eine Regel, die
man vergessen kann; eine fehlende Zahl ist eine, die man nicht
vergessen kann.
Eine Zahl statt dreissig Einzelumrechnungen: Wer je Zeile einen Cent
mitschickt, hat dreissig Gelegenheiten, eine zu vergessen.
=======================================================================
FUENF BEFUNDE GEGEN DIE EIGENEN PRUEFUNGEN
1. Eine Pruefung fragte "liegt die Leiste unter beiden Spalten?" --
das tut eine klebende Leiste beim Hochscrollen absichtlich nicht.
Sie stellte die Frage von vorher. Jetzt zaehlt die Reihenfolge im
Dokument, die beim Scrollen wie beim Stillstand gilt.
2. Eine Messung klickte auf einen Namen und wartete 400 ms auf die
UHR -- und verschluckte den Klickfehler still. Derselbe Lauf war
dreimal gruen und beim vierten rot, ohne Codeaenderung. Jetzt wird
auf das Merkmal gewartet, bis zu dreimal, und die Zahl der
Anlaeufe steht im Protokoll.
3. Eine Pruefung loeschte erst selbst den Chat (eine Sendung zu
beenden tut das mit Absicht) und fragte dann, ob er noch da ist.
4. "Die Dogen sind unberuehrt (0 Staende)" -- null bleibt auch dann
null, wenn das Zuruecksetzen sie mitnaehme. Jetzt steht vorher
eine echte Spende da, und die Zahl gehoert in die BEDINGUNG.
5. `knopf-still--haupt` stand seit Wochen im HTML und war in KEINEM
Stilblatt definiert -- eine Klasse, die aussieht, als sei etwas
hervorgehoben, und auf dem Bildschirm ist es das nicht. Gefunden
beim Nachsehen, ob es sie gibt, bevor ich sie ein zweites Mal
benutze.
Und eine neue Pruefung, die es vorher nicht gab: ALLE 118 Kennungen,
die das Programm mit `$('...')` anspricht, werden gegen das HTML
gehalten. Nach einem Umbau, der die halbe Tafel neu sortiert, waere
eine verlorene Kennung KEIN Fehler beim Laden -- `$()` gibt still
`null` zurueck, und der Fehler erscheint erst, wenn jemand mitten in
der Sendung den Knopf drueckt.
pruef-reaktion 365/0 (vorher 321) - pruef-spenden 172/0 (vorher 167) -
pruef-buehne 36/0 - pruef-css-klassen ok - pruef-tippziele 11/0 -
mess-reaktion und mess-buehne ohne Beanstandung
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3fedeea716 |
Kamerafenster: Groesse und Ecke lassen sich stellen
Filipe: "und danach perfektionierst du auch die verschiedenen groessen von kamera und so, perfektionier das alles bitte." Sechs Groessen (0,6x bis 2x) und vier Ecken, beide an der SENDUNG und nicht am Browser: Was Filipe einstellt, sehen alle. Waere es eine Einstellung je Geraet, redete er ueber ein Bild, das bei den Zusehenden anders aussieht -- und im Stream stuende ein drittes. Anordnung, Groesse und Ecke gehen jetzt EINEN Weg (/layout), weil sie zusammen eine einzige Frage beantworten: Wie sieht das Bild aus? Drei getrennte Aufrufe waeren drei Rundrufe, und dazwischen saehen die Zusehenden eine Mischung -- neue Anordnung, alte Ecke. Eine falsche Angabe laesst auch das Gute stehen, statt halb umzustellen. Die Ecke gibt es, weil unten rechts bei TikTok die Knopfreihe liegt, bei YouTube die Fortschrittsleiste, und Untertitel fast immer unten stehen. Eine feste Ecke ist eine, die bei jeder zweiten Plattform im Weg ist. Die OBS-Videoquelle kennt jetzt die Anordnung und blendet sich bei "Nur Kamera" aus -- sonst laege im Stream ein stehengebliebenes YouTube-Bild unter den Kameras, und Filipe saehe es nicht, weil er auf seine Szene schaut und nicht auf die Quelle. VIER BEFUNDE, ALLE VON DEN PRUEFUNGEN UND KEINER VOM AUGE: 1. Die Knoepfe fuer Groesse und Ecke gab es gar nicht. HTML und Stilblatt waren da, das Programm nicht. Gemessen: "0 von 0 Eckknoepfen gesperrt", und der Hinweistext stand noch wortgleich wie im HTML -- zwei leere Kaesten, die aussahen, als sei alles in Ordnung. 2. Bei "Nur Kamera" war der Stapel 493 px breit statt 1072. Der neue Deckel max-width: 46% -- richtig gegen ein zu grosses Fenster bei "Video gross" -- galt still auch dort, wo die Kameras die ganze Flaeche fuellen sollen. 3. Am Handy haette die Groesseneinstellung ueberhaupt nichts bewirkt: Dort stand weiterhin width: clamp(88px, 26vw, 140px) am Fenster selbst. Das ist die dritte Wiederholung derselben Sache an einem Tag (die Saalzeilen, die Tafeln, jetzt die Kamerabreite): Zwei Regeln fuer dieselbe Frage sind die Garantie, dass eine davon irgendwo falsch gewinnt. Breite und Rand gehen jetzt ueber --kam-grund/--kam-rand, --kam wird an genau EINER Stelle gerechnet, und eine Pruefung zaehlt das nach. 4. Die Pruefung schlug auf ihren EIGENEN Kommentar an, der die entfernte Zeile zitiert. Ein Werkzeug, das bei jedem Lauf meckert, wird nach dem zweiten Mal weggeklickt -- samt dem echten Befund darin. Gezaehlt werden jetzt Regeln, nicht Prosa. Gemessen beim Zuschauer und nicht in der Datenbank: 1x -> 208 px, 2x -> 416 px, alle Fenster innerhalb der Leinwand, und jede der vier Ecken am Abstand zu den Kanten nachgewiesen statt an ihrem eigenen Namen. Ein Knopf, der gerade nichts bewirken kann, ist grau, und der Satz darunter sagt warum. pruef-reaktion 320/0 - pruef-buehne 36/0 - pruef-css-klassen ok - pruef-tippziele 11/0 - mess-reaktion ohne Beanstandung Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d2f02ba84e |
Spenden: Stufen gestaltbar, Bild hochladen, Größe je Stufe
Filipes Wunsch: „mach paar fertige und so dass ich auch hochladen
kann. auch so dass ich das anders gestalten kann oder die größe
verändern kann. ... auch spezielle sachen bei speziellen spenden."
WAS ES SCHON GAB, WAS FEHLTE
Drei Stufen ab Werk, fünf gezeichnete Zeichen, Farbe und Dauer je
Stufe — und sogar schon ein Feld für ein eigenes Bild. Es fehlte der
Weg, das alles zu ÄNDERN: Um eine Stufe umzubenennen, hätte jemand in
die Datenbank greifen müssen.
DIE GRÖSSE IST DAS „SPEZIELLE BEI SPEZIELLEN SPENDEN"
Je Stufe, nicht einmal für alle: Eine Rudel-Legende darf größer
dastehen als ein Danke. Eine einzige Größe für alle wäre wieder eine
Preisliste. Umgesetzt als EINE Schriftgröße, alles darin in `em` —
nicht `transform: scale()`, denn die Karte kommt schon mit
`translateX()` herein, und zwei `transform` an derselben Stelle
schließen einander aus; außerdem wird Text beim Skalieren matschig.
Nur nach oben (1 bis 2,5), und das ist eine ehrliche Grenze: Das
kleinste Wort auf der Karte steht bei 11,52 px, die Hausgrenze ist
11,5. Ein Faktor von 0,8 machte daraus 9,2 px. Kleiner geht an der
richtigen Stelle — die OBS-Tafel hat ihren eigenen Regler in der
Adresse, dort ist es eine Videoeinblendung und kein Text zum Lesen.
AUSPROBIEREN, OHNE EINE SPENDE ANZULEGEN
Der naheliegende Weg wäre gewesen: eine Spende eintragen und danach
löschen. Das ist verboten — in ein laufendes System kommen keine
Testdaten, und „gelöscht" heißt bei Geld nicht „war nie da". Die
Probe schreibt deshalb NICHTS und geht nur an den, der drückt; eine
Probe im ganzen Saal wäre eine Spende, die es nicht gab.
DREI FEHLER, DIE DIE PRÜFUNG GEFUNDEN HAT
1. `protokolliere()` wurde an 17 Stellen falsch herum gerufen —
`(personId, aktion, detail, ip)` statt `(aktion, {…})`. JavaScript
beschwert sich nicht: Das zweite Argument war ein Text, und einen
Text zu zerlegen ergibt lauter `undefined`. Auf dem echten Server
nachgemessen: 39 Protokollzeilen mit Aktionen wie „16.0", alle
ohne Person, ohne Detail, ohne IP. Betroffen waren Material,
Hilfe, Bühne, Reaction und Spenden — also jede Änderung an
Dogi-Media und jede Maßnahme im Live-Chat, ausgerechnet das,
wofür es ein Protokoll gibt. Alle 17 berichtigt, und
pruef-struktur wacht jetzt darüber (mit Gegenprobe).
2. Beim Speichern der Leiter bekam jede Stufe eine NEUE Kennung
(DELETE + INSERT). Ein Bild-Hochladen gegen die eben noch gültige
Kennung antwortete mit 404 — im Alltag trifft das jeden, der einen
zweiten Bildschirm offen hat. Jetzt werden vorhandene Zeilen
geändert statt ersetzt; das Bild bleibt von selbst daran hängen.
3. `ab_cent` ist eindeutig. Zwei Stufen ihre Beträge tauschen zu
lassen scheiterte mit „UNIQUE constraint failed", obwohl das
Ergebnis in Ordnung gewesen wäre: Beim Umschreiben stößt die
Leiter auf sich selbst. Jetzt in drei Schritten — löschen,
geparkte Zwischenwerte, endgültige Werte —, und das ist nach
außen nie sichtbar.
UND DREI, DIE IN MEINER MESSUNG STECKTEN
Die Messung hat eine noch laufende Karte aus dem vorigen Abschnitt
erwischt und daraus drei Fehler gemeldet, die keine waren —
darunter „die Probe läuft im ganzen Saal". Sie zählte außerdem die
versteckten Dateifelder als zu kleine Tippziele. Jetzt räumt sie
vorher auf, wartet auf die Karte MIT DER ERWARTETEN GRÖSSE (die
Karten laufen in einer Schlange — einen Knoten zu entfernen beendet
sie nicht) und lässt die Einblendung zur Ruhe kommen, bevor sie misst.
Ein Bildschirmfoto aus der Einblendphase sah aus, als stünde die
Karte links heraus; nachgemessen: links 18 px, ganz im Bild.
GEMESSEN, NICHT ANGENOMMEN
Karte bei Größe 1: Schrift 16 px, Betrag 25,92 px. Bei Größe 2:
32 px und 51,84 px — Faktor exakt 2,00. Hätte eine einzige Regel noch
in `rem` gestanden, wäre die Karte ungleichmäßig gewachsen, und auf
einem Bild sieht beides nur „größer" aus.
AUCH DAS BILD IST GEPRÜFT
Es liegt am Bühnen-Router und nicht am Spenden-Router: Die
Spendentafel in OBS hat keine Anmeldung, und ein 401 als JSON in
einem `<img>` ergibt ein kaputtes Bild ohne jeden Hinweis. Ohne
Schlüssel, aber mit 128 Bit zufälligem Dateinamen — dieselbe
Größenordnung wie der Bühnenschlüssel, und es ist ein Zierbild, das
ohnehin im Stream steht. Kein Ausbruch aus dem Ordner (vier Wege
geprüft, gemessen wird die Wirkung und nicht der Statuscode).
NACHGETRAGEN AUS BLOCK 4
`reaktion_meldungen` fehlte im Löschkonzept — eine bestehende Prüfung
hat es gefunden. 30 Tage nach dem Erledigen; meistens sind sie
ohnehin früher weg, weil der Live-Chat beim Beenden gelöscht wird und
die Meldungen daran hängen. Wer meldet, muss sich darauf verlassen
können, dass daraus keine dauerhafte Liste wird.
GEPRUEFT
pruef-spenden: 95 Prüfungen (vorher 46), 0 Fehler.
pruef-reaktion 260, pruef-buehne 36, pruef-aufbewahrung 45,
pruef-struktur, pruef-meldungen, pruef-css-klassen, pruef-tippziele,
pruef-deutsche-texte, pruef-auskunft alle grün.
mess-reaktion und mess-buehne: Rückgabewert 0, kein ACHTUNG.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
74c74a08ab |
Reaction: Geschwindigkeit, zwei neue Anordnungen, zweites Video
Filipes Wunsch: „auch bei den videos sachen wie pause geschwindigkeit. meine kamera größer machen video kleiner. nur mein bild, nur das video, möglichkeit zwischen allem zu wechseln so wie ich will, auch gerne so dass ich vielleicht noch ein zweites nebenbei vorbereiten kann so dass ich hin und her switchen kann." GESCHWINDIGKEIT Sechs Stufen von 0,5× bis 2× (0,25× fehlt mit Absicht — bei einem Viertel klingt Sprache wie ein defektes Band). Sie gilt für ALLE: Wer sie nur bei sich umstellte, redete über eine Stelle, die die anderen noch nicht gesehen haben. Die OBS-Bühne zieht sie mit nach — ohne das liefe der Stream nach fünf Minuten auf 1,5× zweieinhalb Minuten hinter dem Saal her. Und der Zuschauer SIEHT sie: ein kleines Schild „1,5× Geschwindigkeit" auf der Leinwand, nur wenn es nicht 1× ist. Ohne das hält jeder Zweite seine Leitung für kaputt. Zwei Fallen, die dabei zugemacht wurden: Der Fünf-Sekunden-Takt des Hosts schreibt das Tempo NICHT mit (sonst drehte ein Takt mit altem Wert die Einstellung zurück), und nach jedem Videowechsel wird es neu gesetzt (YouTube stellt beim Laden auf 1 zurück). Gesetzt wird nur, was `getAvailablePlaybackRates()` hergibt — einen unmöglichen Wert ignoriert der Player schweigend, und dann stünde der Knopf auf 1,5 und es liefe 1,0. ZWEI ANORDNUNGEN MEHR „Nur Video" und „Nur Kamera" sind kein weiteres Größenverhältnis, sondern ein Weglassen — und genau das braucht OBS: Dort liegt die Kamera ohnehin als eigene Quelle, die Bühnenseite soll sie nicht doppelt zeigen. `display: none` und nicht `opacity: 0`: ein unsichtbarer YouTube-Rahmen spielt weiter und hält den Ton. Tasten 1–5, wie vorher 1–3. DAS ZWEITE VIDEO — und warum es nicht die Warteschlange ist Die Schlange ist eine Reihenfolge: eins nach dem anderen, das Gespielte ist weg. Filipe will etwas anderes — zwei Videos NEBENEINANDER, hin und her, und jedes merkt sich seine Stelle. Mit der Schlange nachgebaut wäre es eine Schlange, aus der man nie wieder herauskommt. Der Umschalter steht nur da, wenn es etwas zum Umschalten GIBT; ein Knopf, der „kein zweites Video" antwortet, ist im Live eine Falle. Getauscht wird in EINEM Schreibvorgang (BEGIN IMMEDIATE) — ein Abbruch dazwischen hätte dasselbe Video auf beiden Seiten und die gemerkte Stelle des anderen verloren. Und die Stelle kommt vom Host und nicht aus der Datenbank: dort steht der Stand vom letzten Takt, bis zu fünf Sekunden alt. Was daneben bereitliegt, sieht nur, wer sendet — es ist die Rückhand, und die verrät man nicht vorher (`zweit` ist aus `oeffentlich()` ausgenommen). DER FEHLER, DEN DIE MESSUNG GEFUNDEN HAT Bei „Nur Kamera" war der Kamerabehälter 2175 px breit in einer 1072 px breiten Leinwand — von zwei Gästen stand nur einer im Bild, der zweite lag hinter `overflow: hidden`. Auf dem Bildschirmfoto sah das aus wie eine Anordnung für einen, und niemand hätte gefragt, wo der zweite geblieben ist. Zwei Ursachen: Die Leinwand ist ein Raster mit einer Spalte nach Inhaltsbreite — ein zu breites Kind im Fluss zieht die Spalte mit, und `width: 100%` bezog sich danach auf die gewachsene Spalte. Die Begrenzung wuchs also mit dem, was sie begrenzen sollte; `max-width: calc(50% - 8px)` rechnete gegen denselben Wert und war wirkungslos. Jetzt `position: absolute; inset: 0` (kann das Raster nicht mehr aufziehen) und `flex: 1 1 0; min-width: 0` an den Fenstern — eine Regel, die nicht rechnet, kann sich nicht verrechnen. Die Messung prüft seitdem bei JEDER Anordnung, ob alle Kamerafenster innerhalb der Leinwand liegen. GEMESSEN, NICHT ANGENOMMEN Dass in der Datenbank 1.5 steht, sagt nichts darüber, ob das Video schneller läuft. Die Messung liest deshalb die Uhr der Regie zweimal ab und rechnet nach: 1× → 1,00 Sekunden je Sekunde, 2× → 2,00. Der Umschalter ebenso: hin, zurück, und die Uhr steht wieder bei 79 s statt bei 0. GEPRUEFT pruef-reaktion: 260 Prüfungen (vorher 216), 0 Fehler. pruef-buehne 36, pruef-struktur, pruef-meldungen, pruef-tippziele, pruef-css-klassen alle grün. mess-reaktion: Rückgabewert 0, kein einziges ACHTUNG. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a02cf5c026 |
Reaction: Rollen sichtbar, Moderation im Live-Chat
Filipes Wunsch: „die modis, linke hand und rechte hand soll im chat extra aussehen und auch sachen wie stummschaltungen, sperrungen, meldunge und alles mögliche im chat machen können falls sich jemand nicht benimmt." WER SPRICHT Jeder Beitrag aus dem Team trägt jetzt ein Abzeichen: „Dogi", „Team" (beide Hände) und „Modi". Ein WORT und nicht nur eine Farbe — rund acht Prozent der Männer unterscheiden Rot und Grün schlecht, und hier hängt an der Unterscheidung etwas. Gedeckte Töne auf schwacher Fläche, 11,52 px (die Hausgrenze ist 11,5), weil daneben ein Video läuft. Die Wörter sagen den RANG nicht: Filipe steht nie über seinem Team. Eine Prüfung schlägt an, wenn dort „Chef", „Boss" oder „Leitung" stünde. WAS DIE MODERATION KANN Am Namen öffnet sich ein Menü mit vier Wegen: Beitrag wegnehmen, 10 Minuten stumm, aus der Sendung — und der Verweis in den Treff, wo längere Maßnahmen hingehören (mit Begründungspflicht und Frist in Tagen). Die Reaction baut kein zweites Sperrsystem daneben: Wer im Treff eine Pause hat, schreibt hier auch nicht. Neu ist nur, was der Treff nicht hat — MINUTEN. Höchstens eine Stunde; wer länger etwas braucht, nimmt den Treff. Nicht gegen das Team: Wer einen Modi stummschalten könnte, hätte einen Weg, die Moderation selbst auszuschalten, mitten in der Sendung. MELDEN DARF JEDER Die Moderation sieht nicht alles, wer mitliest schon. Zweimal melden zählt einmal (sonst füllt einer allein die Liste). Bei der Moderation erscheint im Kopf der Schiene „1 Meldung" — nur wenn etwas offen ist; eine Zahl, die immer dasteht und meistens null ist, wird nach drei Tagen nicht mehr gelesen. VIER FEHLER, DIE DABEI AUFGEFALLEN SIND 1. `oeffentlich()` nahm `meldungen` und `massnahmen` NICHT aus dem Rundruf. Der Rundruf wird aus dem Stand dessen gebaut, der gerade etwas getan hat — bei einer Moderationshandlung wären der gemeldete Text, der Name des Gemeldeten und der Name des MELDERS an jeden im Saal gegangen. Wer meldet, muss sich darauf verlassen können, dass das niemand sieht. 2. `meldung.js` hatte zwei Schlüssel doppelt: `geschlossen` und `nur_leitung`. Der spätere gewinnt stillschweigend — in der Hilfe stand dadurch „Der Saal ist zu". Ein Wort, ein Satz; eine Prüfung hält das jetzt fest. 3. Wer stummgeschaltet war, bekam bei OFFENEM Chat „Der Chat ist gerade zu" — der Aufrufer reimte sich den Grund aus der Chat-Stufe zusammen. Jetzt gibt `schreibGrund()` den echten Grund zurück. 4. Wer rausgenommen wurde, merkte nichts: Das Video lief weiter, nur die Anwesenheitsmeldung schlug still fehl. Jetzt hält alles an und es steht ein Satz da, der sagt, dass es nur für heute gilt. UND EINER, DEN NUR DAS BILDSCHIRMFOTO GEFUNDEN HAT Das Menü lag messbar komplett im Fenster (x=1099..1315 von 1440, y=652..840 von 900) und war trotzdem abgeschnitten: Die Chatliste rollt, und ein rollender Vorfahre beschneidet sein Kind. „Im Fenster" und „sichtbar" sind zwei verschiedene Fragen, und ich hatte die falsche gemessen. Das Menü hängt jetzt fest am Fenster und klappt nach oben oder links, wo kein Platz ist. Die Messung fasst seitdem mit `elementFromPoint` an jeden Knopf an, statt Rechtecke zu vergleichen. GEPRUEFT pruef-reaktion: 216 Prüfungen (vorher 156), 0 Fehler — zwei neue Abschnitte. mess-reaktion misst die Moderation jetzt im echten Browser: Abzeichen, Überlauf der Schiene, Menü, Stummschaltung beim Betroffenen, Meldung bis zur Moderation, Rauswurf. Dazu grün: pruef-meldungen, pruef-struktur, pruef-css-klassen, pruef-tippziele, pruef-deutsche-texte, pruef-hilfe. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
079cf8c74f |
Drei Quellen fuer OBS und TikTok Studio -- ohne Anmeldung, mit Schluessel
Filipe: "ich will das alles auch so perfekt dass ich es ganz einfach
und easy mit obs oder mit tiktok studio verbinden kann. also so dass
man dan nur die kamera und das video sieht."
WARUM OHNE ANMELDUNG -- nachgesehen, nicht angenommen
OBS speichert die Anmeldung einer Browser-Quelle NICHT zuverlaessig;
im OBS-Forum stehen dazu Meldungen bis in die aktuelle Fassung 31.
Eine Quelle, bei der man sich nach jedem Programmstart neu anmelden
muss, ist mitten in einer Sendung unbrauchbar.
Deshalb ein SCHLUESSEL in der Adresse -- derselbe Weg, den jedes
Alert-Werkzeug im Netz geht. 32 Byte aus dem Zufall des Systems,
verglichen wird zeitgleich (`timingSafeEqual`): Ein gewoehnlicher
Vergleich bricht beim ersten falschen Zeichen ab, und aus den
Bruchteilen einer Millisekunde laesst sich ein Schluessel Zeichen
fuer Zeichen erraten.
DREI QUELLEN, WEIL DREI DINGE VERSCHIEDEN SIND
buehne.html Das laufende YouTube-Video, auf die Sekunde genau wie
bei allen anderen. Stumm (der Ton kommt aus dem
Mischpult) und ohne jede Bedienung -- was hier zu
sehen ist, geht in den Stream.
DIE EIGENE KAMERA IST ABSICHTLICH NICHT DRIN. Sie ist
in OBS direkt als Geraet verfuegbar, in besserer
Qualitaet und frei in Groesse und Lage -- genau das,
was Filipe will ("meine kamera groesser machen video
kleiner"). Den Umweg ueber den Browser zu nehmen
hiesse, Qualitaet gegen nichts einzutauschen und die
Groesse festzulegen statt sie freizugeben.
tafel.html Nur die Spendenkarten, auf DURCHSICHTIGEM Grund.
Groesse und Lage stehen in der Adresse (`&g=1.6`,
`&pos=or`): Wer in OBS eine Quelle einrichtet, hat die
Adresse ohnehin vor sich -- ein Wert, den man
stattdessen im Regiepult suchen muesste, waere ein
Fensterwechsel mitten im Einrichten. Alles rechnet in
`rem`, ein Wert nimmt Schrift, Bild und Polsterung
gleichmaessig mit.
Buehnenmodus `reaktion.html?nur=buehne` -- dieselbe Seite, nur ohne
alles Bedienbare. Fuer den Fall, dass GAESTE im Bild
sind: Deren Kameras kommen ueber eine
Direktverbindung an, und die braucht eine angemeldete
Seite. Diese eine wird als Fenster aufgenommen.
ES IST DIESELBE SEITE UND NICHT EINE ZWEITE. Eine
eigene muesste Video, Kameras, Verbindungsaufbau und
Nachfuehrung noch einmal enthalten -- und beim
naechsten Umbau saehe eine von beiden anders aus.
WAS HERAUSKOMMT, IST DIE EIGENTLICHE FRAGE
Wer den Schluessel hat, sieht genau das, was ohnehin im Stream
steht: Video, Stand, Sekunde, Titel -- und die Spendenkarten. Kein
Chat, keine Namen von Zusehenden, keine Zahlen ueber das Haus. Die
Pruefung zaehlt die Felder der Auskunft EINZELN auf und weist jedes
verbotene namentlich nach; eine Auskunft, die "ungefaehr das
Richtige" enthaelt, ist bei einem Weg ohne Anmeldung keine.
Ein neuer Schluessel macht die alten Adressen sofort tot -- und
schliesst die laufenden Quellen. Sonst liefe eine mit dem alten
weiter, obwohl er zurueckgezogen ist, und man haelt sich fuer
sicher, ohne es zu sein.
SIE MUESSEN TAGE LAUFEN, OHNE DASS JEMAND HINSIEHT
Das ist der Unterschied zu einer Seite im Browser: Wer eine Seite
offen hat, merkt, wenn sie haengt. Eine Quelle in OBS laeuft im
Hintergrund, und ein Stillstand faellt erst auf, wenn die erste
Spende nicht erscheint -- mitten in der Sendung. Deshalb ein
Lebenszeichen alle 25 Sekunden, eine eigene Wache (70 Sekunden ohne
alles = neu verbinden) und ein sofortiger Neuaufbau, wenn der
Rechner aus dem Ruhezustand kommt.
Und: Ein Fehler wird angezeigt, aber nur der, der etwas bedeutet --
ein falscher Schluessel. Alles andere bleibt still, weil jede
Flaeche hier im Stream zu sehen waere.
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN
1. Die Quellen kamen mit 401 zurueck, obwohl die Seiten laengst
geladen waren: `aufgabenRouter` haengt eine Schranke ueber ALLE
Pfade unter /workspace/api. Genau dafuer stehen `sicherungRouter`
und der Weg fuers Profilbild schon davor -- die Buehne ist der
dritte Fall derselben Art und steht jetzt dort.
2. `waitUntil: "networkidle"` auf einer Seite mit Ereignisstrom. Der
Strom endet absichtlich nie; die Messung wartete auf einen
Zustand, der nicht eintreten kann, und brach nach 30 Sekunden ab.
Dieselbe Falle wie am 06.09. beim Regressionslauf.
ZWEI PRUEFUNGEN WURDEN DABEI GENAUER
`pruef-struktur` verlangte von den zwei OBS-Quellen ein Symbol fuer
den Startbildschirm, ein Manifest und eine Leistenfarbe. Sie
laufen in einem Programmfenster und werden nie installiert -- sie
fallen aus dieser Frage heraus, benannt und mit Grund.
Die Namensstreit-Regel zaehlte jede Klasse, die irgendwo in einem
Selektor vorkommt. Damit galt auch
`body[data-nur="buehne"] .kopfleiste { display: none }` als eigene
Klasse -- dabei ist das das Gegenteil: eine absichtliche
Bezugnahme, um sie im Buehnenmodus wegzunehmen. Gezaehlt wird
jetzt nur, was am ANFANG einer Regel steht, also als eigenes
Bauteil gemeint ist. Mit Gegenprobe in beide Richtungen -- sonst
haette ich eine Regel nur so lange geschaerft, bis sie schweigt.
GEMESSEN
mess-buehne (neu) Ein Browserfenster OHNE jeden Keks: beide
Quellen arbeiten, 0 Kekse, Grund durchsichtig
(rgba(0,0,0,0)), Karte laeuft an (25 EUR,
Rudel-Legende, 348x178). Falscher Schluessel: kein
Inhalt, Grund im Bild. Neuer Schluessel: alter 404,
neuer 200. Buehnenmodus: Kopf, Chat, Pult und
Schild weg, Leinwand da, Saal 720 von 720.
pruef-buehne (neu) 36 Punkte, 0 Fehler
pruef-reaktion 156 (war 154), spenden 46, haus-trennung 100,
haus-seiten 38, struktur 35, css-klassen 33,
verborgen 25, rechtetafel 19, portnummern 15,
ports 8 -- alle 0 Fehler.
|
||
|
DogFatherGit
|
28b492527e |
Kamera und Chat -- die zwei fehlenden Host-Steuerungen
Filipes Notiz nennt acht: "Host-Steuerung fuer Kamera, Mikrofon,
Video, Gaeste, Lautstaerke, Chat, Layout und Start/Ende."
Nachgezaehlt war sechsmal etwas da und zweimal nichts.
KAMERA
Es gab keinen Weg, das eigene Bild abzuschalten. Wer kurz aufstehen,
trinken oder etwas holen wollte, musste die Sendung verlassen oder
sich dabei filmen lassen.
Jetzt liegt eine SENDERLEISTE ueber dem Bild -- Kamera, Mikro und ein
Pegel. Sie gehoert jedem, der sendet, Host wie Gast: Ein Gast, der
sein eigenes Bild nicht abschalten kann, muesste den Host darum
bitten, und das ist keine Bedienung, sondern eine Bitte.
DAS BILD WIRD AM GERAET ABGESCHALTET (`track.enabled = false`), nicht
am Server: Die Verbindung bleibt stehen, der Ton laeuft weiter, und
beim Wiedereinschalten ist das Bild sofort da. Der Server erfaehrt es
nur, damit bei den ANDEREN "Kamera aus" im Fenster steht. Ohne diese
Beschriftung sind ein abgeschaltetes und ein kaputtes Bild dasselbe
schwarze Rechteck -- und dann fragt jemand im Chat, ob die Technik
hakt.
Erst das Geraet, dann die Ansage. Andersherum stuende bei allen
"Kamera aus", waehrend noch ein Bild fliesst; man glaubte sich
unsichtbar. Geht die Ansage nicht durch, wird das Geraet
zurueckgesetzt -- ein Knopf, der halb wirkt, ist schlimmer als einer,
der gar nicht wirkt.
Das Mikro laeuft denselben Weg. Erst wollte ich es rein oertlich
lassen; das waere dieselbe stille Falle gewesen: Wer sich selbst
stummschaltet und trotzdem redet, saehe bei allen anderen ein ganz
normales Fenster.
CHAT
Es gab Moderation -- Beitraege wegnehmen -- aber keine Steuerung des
Chats selbst. Einen Beitrag zu loeschen, nachdem er stand, ist etwas
anderes, als ihn gar nicht erst zuzulassen.
Drei Stufen: OFFEN, TEAM (wer moderiert, darf -- wer aufraeumen soll,
muss dabei reden koennen) und ZU (nur die zwei, die fuehren). Zwei
Stufen waeren zu wenig: "zu" ist in einer Sendung fast immer zu viel,
dann sitzen alle vor einem stummen Fenster. Die mittlere ist die, die
man wirklich braucht.
Die Schalter stehen im Kopf der Chatschiene, nicht im Regiepult: Man
moderiert, wo man liest. Ein Umweg ueber ein Register waere in dem
Moment, in dem es laut wird, genau ein Umweg zu viel.
EIN GESPERRTES FELD SAGT, WARUM. "Gerade schreibt nur das Team" statt
eines Feldes, das sich nicht beschreiben laesst und schweigt --
sonst schreibt jemand in den Hauschat, dass die Reaction hakt. Und
die Stufe gilt AM SERVER: Ein ausgegrautes Feld haelt niemanden auf,
der die Schnittstelle kennt. Beide Antworten kommen aus derselben
Funktion; zwei Rechnungen waeren zwei Gelegenheiten, dass ein Feld da
ist und mit 403 antwortet.
EIN FUND NEBENBEI: "MEIN MIKRO" WAR EIN PLACEBO
Gemessen: `staende.mikro` wird nirgends gelesen. Der Schieber liess
sich bewegen, die Zahl daneben aenderte sich -- und es passierte
nichts. Das ist schlimmer als ein fehlender Regler: Man glaubt, man
haette leiser gestellt.
Technisch ist das auch richtig. Die eigene Lautstaerke laesst sich
nicht am Regler aendern; man muesste den Ton umrechnen und die Spur
in jeder Verbindung austauschen. Was man beim eigenen Mikro braucht,
ist AN oder AUS -- und ein Pegel, der zeigt, dass es ankommt. Genau
das steht jetzt dort, als vierte Spalte im Pult, mit demselben
Zustand wie die Senderleiste. Die drei anderen Regler bleiben Regler:
Sie steuern, was ICH hoere, und das geht am Empfaenger.
UND EINER IN MEINER EIGENEN ARBEIT
`kasten.append(el("div","pegel")).append(el("i"))` -- `Node.append()`
gibt `undefined` zurueck, nicht das angehaengte Element. Ein
TypeError beim Aufbau des Pults, den `node --check` nicht sieht.
Beim Verkuerzen nicht nachgesehen, was die Methode zurueckgibt.
Dazu: Die Pegel-Takte liefen in `pultAufbauen()`. Das Pult hat nur,
wer die Sendung fuehrt -- ein Gast haette seinen Pegel nie gesehen,
und genau er braucht ihn am dringendsten.
GEMESSEN
mess-reaktion Der Host schaltet ab, und bei der Zuschauerin steht
"Kamera aus" bei DogFather, Bild verdeckt.
Stufe "Team": Feld gesperrt mit Grund, und der
Server lehnt denselben Versuch mit 403 ab.
pruef-reaktion 154 Punkte, 0 Fehler (vorher 132), neuer Abschnitt
13 mit 22 Punkten und Gegenprobe (es geht auch
wieder auf -- eine Sperre, die man nicht loesen
kann, ist keine Stufe, sondern ein Ende)
dazu gruen handy 180, css-klassen 33, struktur 35,
tippziele 11, aufbewahrung 45, meldungen 8
Der neue Abschnitt baut sich seine Buehne selbst. Abschnitt 9 beendet
die Sendung; sich auf den Stand eines frueheren Abschnitts zu
verlassen ist die Kopplung, die spaeter jemand aus Versehen
zerreisst.
SCHEMA: drei Spalten (reaktion_dabei.kamera_aus, .mikro_aus,
reaktion.chat_modus), alle per ALTER TABLE. Auf einer Kopie der
echten Datenbank durchgespielt: 20 Personen, keine Tabelle verliert
eine Spalte.
|
||
|
DogFatherGit
|
711a5470ab |
Die Regie wird eine Regie -- und das Video lief bei niemandem
Filipe: "perfektionier das auch mit den videoos. pefektionier auch das
aussehen und das layout von der regie. ich will dass du das viel
hochwertiger und profissioneller machst."
DAS VIDEO LIEF BEI NIEMANDEM -- AUCH NICHT BEIM HOST
Gemessen ueber ein neues Merkmal am Rahmen: `onStateChange` ist nie
ausgeloest worden, bei keinem der drei Browser. Zwei Ursachen, die
sich gegenseitig verdeckt haben:
Ein Player mit Ton darf ohne Handlung des Menschen nicht losgehen.
Ohne `mute: 1` greift `playVideo()` nicht -- und ein Zuschauer hat
keine Bedienung (mit Absicht), haette also NIE eine Moeglichkeit
gehabt, es zu starten. Eine Stunde Standbild.
`onReady` tat `if (host) takt(); else folgen();`. Der Host hat damit
nur GEMELDET, wo er steht, und nie selbst begonnen. Er meldete
"laeuft nicht", und alle anderen folgten ihm brav ins Stehen.
Die Messung bricht ab jetzt ab, wenn der Player nicht bei beiden
laeuft. Ein gruener Haken ueber einem Standbild ist wertlos.
DIE WARTESCHLANGE
Vorher gab es genau EIN Videofeld. Wer zwei Sachen hintereinander
schauen wollte, tippte mitten in der Sendung eine YouTube-Adresse ein
-- vor Publikum, mit laufender Kamera, ein Tippfehler von einem
schwarzen Rechteck entfernt. Jetzt wird vorher eingeraeumt und im Live
nur weitergeschaltet: anhaengen, schieben, "Jetzt", "Naechstes".
Die Titel kommen von YouTube selbst (oEmbed, kein Schluessel, kein
Kontingent) und werden EINMAL geholt und hingelegt. Klappt der Abruf
nicht, steht dort die Kennung -- kein erfundener Name. Die Grenze ist
ueber die Umgebung veraenderbar, damit die Pruefung den vollen Fall in
Sekunden erreicht statt dreissig Videos anzuhaengen.
DIE REGIE
Vorher fuenf Kaesten untereinander in einem Bereich, der hoechstens
die halbe Bildschirmhoehe hat -- man sah fuenf halbe Dinge. Die drei
grossen Knoepfe lagen ganz unten, hinter acht Feldern und vier
Reglern. Wer mitten in der Sendung "Beenden" drueckt, drueckt es, weil
etwas passiert ist; das darf nicht hinter einer Bewegung liegen.
Eine Leiste, die IMMER steht: Lampe, Laufzeit, Zuschauer, wie viele
davon Bild bekommen, Gaeste, gemessener Upload -- und rechts die
drei Knoepfe.
Register statt Stapel: Sendung, Warteschlange, Ton, Gaeste, Bild.
Eine Videospur mit echter Bedienung: Pause, +/-10 s, Positionsband,
Restzeit, "Naechstes". Vorher musste man ins YouTube-Bild fassen --
und was dort passiert, passiert nur bei einem selbst.
PEGEL an den Reglern, aus einer echten Messung (AnalyserNode). Sie
beantworten die Frage, die man sich sonst erst nach der Sendung
stellt: "War mein Mikro ueberhaupt an?" Ein Regler auf 100 sagt
darueber nichts. Beim YouTube-Regler steht dabei, dass dort nichts
zu messen ist -- Ton aus einem fremden Rahmen laesst sich nicht
abgreifen, und ein erfundener Ausschlag waere schlimmer als keiner.
Der Upload wird an der Verbindung gemessen (`getStats`), nicht aus
"zwoelf mal 350 kbit/s" gerechnet.
Tastaturkuerzel -- und die Legende steht darunter. Ein Kuerzel, das
niemand kennt, ist keins.
VIER FEHLER, DIE NUR DIE MESSUNG GEZEIGT HAT
1. `.tafel` WAR SCHON VERGEBEN. Die Anmeldeseite hat diese Klasse und
setzt sie `position: absolute`; reaktion.html laedt beide
Stilvorlagen. Die Register-Tafel trug damit NICHTS zur Hoehe bei
(114 px Raster, 294 px Inhalt) und malte quer ueber Register und
Kuerzel -- 197 Pixel, um die die Seite ueberlief. Auf dem Bild sah
es aus wie ein Anzeigefehler; es war ein Namensstreit. Dritter
Fall dieser Art nach .knopf-still und .schalter, deshalb steht er
ab jetzt in einer Pruefung: keine Klasse aus reaktion.css darf in
gate/start/module/haus.css vorkommen.
2. `node:sqlite` kennt kein `.transaction()`. Von Hand geklammert.
3. Das Schild war auf dem Handy 10,24 px gross -- unter der
Hausgrenze von 11,5 px. Gefunden von `pruef-handy`, das die
GEZEICHNETE Groesse misst; die Stilvorlagen-Pruefung haette die
Zeile in der Medienabfrage durchgelassen.
4. Die Messung klickte blind auf den Griff des Pults ("umschalten")
und machte es damit ZU, seit es aufgeklappt startet. Sie stellt
den Zustand jetzt her, statt ihn umzuschalten.
UND DIE HARTNAECKIGSTE: DAS BILD DES GASTES KAM BEIM HOST NICHT AN
Erst in einem von drei Laeufen, dann in drei von drei -- und zwar
SCHLIMMER, nachdem ich einen Wachhund dagegen gebaut hatte. Vier
Ursachen, hintereinander gemessen statt geraten:
a) `kameraHolen()` wurde beim Host FUENFMAL betreten. Die Wache
`if (meinStrom) return` wirkt erst, wenn die Kamera DA ist --
solange die erste Anfrage laeuft, geht jede weitere als zweite
Anfrage an dasselbe Geraet. Eine blieb liegen, und mit ihr der
Anruf, der darauf wartete. Der Platz in `ruftGerade` blieb
belegt, und damit kam nie wieder eine Leitung zustande. Jetzt
bekommen alle dasselbe Versprechen zurueck.
b) Der Wachhund riss Leitungen ab, die gerade verhandelt wurden --
zwischen "Leitung angelegt" und "Angebot abgeschickt" liegen
drei await.
c) "Ruf mich an" brach dasselbe ab: Der Bittende weiss nicht, dass
es schon laeuft, und fragt alle drei Sekunden weiter.
d) Meine Reparatur von (b) und (c) war "signalingState !== stable
heisst: in Arbeit" -- ohne Uhr. Damit war eine Leitung, deren
Antwort nie ankommt, vor BEIDEN Aufraeumwegen sicher, dauerhaft.
Der Zuschauer bekam daraufhin gar nichts mehr; ich hatte den
Fehler nur von einer Seite auf die andere geschoben. "Wird
verhandelt" ist ein Zustand MIT DAUER und steht jetzt an genau
einer Stelle.
Dazu ein eigener Fehler beim Aufraeumen: Mit der Messspur ist
`ruftGerade` mit herausgefallen. Vier Laeufe ohne jedes Bild -- und
`node --check` sieht das nicht, eine fehlende Variable ist
syntaktisch tadellos.
GEMESSEN
mess-reaktion fuenf Laeufe hintereinander ohne Beanstandung;
beide Kameras 640 px bei Host UND Zuschauerin,
Video laeuft bei beiden, Upload 0,9 Mbit/s,
Warteschlange 2 Zeilen mit Vorschaubildern,
kein Ueberlauf (4 px statt 197)
pruef-reaktion 132 Punkte, 0 Fehler (vorher 88)
pruef-handy 180 Punkte, 0 Fehler
dazu gruen css-klassen 33, struktur 35, tippziele 11,
meldungen 8, kamera-richtlinie 10
SCHEMA: neue Tabelle `reaktion_liste`, neue Spalte
`reaktion.video_titel` (ALTER TABLE, keine Abschrift der Spalten).
|
||
|
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. |
||
|
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.
|