Files
dogfather-universe/server/reaktion-tabellen.js
T
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).
2026-09-28 03:45:15 +02:00

227 lines
10 KiB
JavaScript

/* =====================================================================
DIE REACTION — die Tabellen (28.09.2026)
Filipe hat eine Kurznotiz geschickt: eine Reaction-Kachel, die
fuer alle sichtbar ist, normalerweise geschlossen; bei
Vorbereitung ein Vorschaubild und ein Countdown; ein paar Minuten
vorher geht der Wartebereich auf, damit die Leute schon
dasitzen und schreiben koennen; beim Start laufen YouTube-Video
und Host-Kamera gleichzeitig; ein bis zwei Gaeste mit Kamera und
Mikrofon; getrennte Lautstaerken; ein Live-Chat mit Moderation;
und ein Weg, den Host zu unterstuetzen.
---------------------------------------------------------------------
EINE SENDUNG, NICHT VIELE
Es gibt genau EINE Reaction-Zeile. Sie wird nicht angelegt und
geloescht, sie wechselt ihren Stand: zu -> vorbereitung -> live ->
zu. Der Grund ist nicht Bequemlichkeit, sondern Wahrheit: Eine
Kachel, die „offen" oder „geschlossen" anzeigt, muss auf EINE
Zeile zeigen koennen. Bei einer Liste von Sendungen waere die
erste Frage jedes Mal „welche denn?", und die Antwort darauf haette
jede der sieben Stellen einzeln gegeben, die den Stand anzeigen.
Was vorbei ist, wandert nach `reaktion_verlauf`. Damit bleibt die
Geschichte erhalten, ohne dass die Gegenwart mehrdeutig wird.
---------------------------------------------------------------------
WARUM DAS VIDEO NICHT UEBER DEN SERVER LAEUFT
Naheliegend waere: der Host spielt das YouTube-Video ab, und alle
sehen seinen Bildschirm. Das waere aus zwei Gruenden falsch.
Erstens rechtlich: Ein YouTube-Video an Dritte weiterzusenden ist
eine oeffentliche Wiedergabe und damit genau die Sache, fuer die
Kanaele gesperrt werden. Jeder Zuschauer laedt das Video deshalb
SELBST von YouTube -- so wie bei jeder Watch-Party.
Zweitens technisch: Ein weitergesendetes Video kostet Bandbreite
und Qualitaet. Uebertragen wird stattdessen nur, WO das Video
gerade steht (Kennung, laeuft/pausiert, Sekunde). Das sind ein paar
Byte, und jeder sieht es in voller Qualitaet.
---------------------------------------------------------------------
DIE KAMERAS LAUFEN DIREKT VON MENSCH ZU MENSCH
Der Anrufteil des Hauses (workspace-anruf.js, assets/js/anruf.js)
macht das seit dem 18.09. und hat STUN/TURN eingerichtet. Die
Reaction benutzt denselben Weg, nur mit mehr Empfaengern: Der Host
baut zu jedem Zuschauer eine eigene Verbindung auf.
DAS HAT EINE GRENZE, UND SIE IST GEMESSEN, NICHT GERATEN. Jede
Verbindung kostet den Host Upload. Bei 360p und rund 350 kbit/s
sind zwoelf Zuschauer etwa 4 Mbit/s -- das traegt eine normale
Leitung. Darueber schaltet die Sendung von selbst auf Ton um: Wer
keine Kamera mehr bekommt, hoert alles, sieht das Video und kann
schreiben. Das ist ehrlicher als eine Verbindung, die stockt, und
es ist sichtbar: Die Zahl steht im Regiepult.
Heute sind es elf Menschen im ganzen Haus (gemessen am 28.09.2026:
1 admin, 1 hand, 1 linke, 4 modi, 4 gast). Die Grenze ist also
weit weg -- sie steht trotzdem hier, weil sie sonst erst auffaellt,
wenn es zu spaet ist.
===================================================================== */
/** Wie lange ein beendeter Verlaufseintrag aufgehoben wird. */
export const VERLAUF_TAGE = 180;
/** Hoechstens so viele Zuschauer bekommen Kamerabild. Darueber: nur Ton. */
export const SICHT_PLAETZE = Number(process.env.REAKTION_SICHT_PLAETZE || 12);
/** Hoechstens so viele Gaeste gleichzeitig (Filipes Notiz: 1-2). */
export const GAESTE_MAX = 2;
/** Ein Chatbeitrag in der Reaction. */
export const TEXT_MAX = 400;
/** So viele Beitraege je Minute und Person. */
export const SCHREIB_BREMSE = 20;
/** Die Staende, die es gibt -- und nur diese. */
export const STAENDE = ["zu", "vorbereitung", "live"];
/** Die Anordnungen des Bildes. */
export const LAYOUTS = ["kino", "gleich", "kamera"];
/** Hoechstens so viele Videos duerfen in der Warteschlange stehen.
*
* Die Zahl ist keine technische Grenze, sondern eine Ansage: Wer
* dreissig Videos einraeumt, plant keinen Abend mehr, sondern legt
* ein Archiv an -- und dafuer ist die Liste nicht gebaut. Sie waere
* danach zu lang, um sie im Pult zu ueberblicken. */
/* Ueber die Umgebung veraenderbar -- damit die Pruefung den vollen
Fall in Sekunden erreicht und nicht dreissig Videos anhaengen muss.
Ein Grenzfall, den niemand prueft, weil das Pruefen zu lange
dauert, ist ein ungeprueftes Verhalten. */
export const LISTE_MAX = Number(process.env.REAKTION_LISTE_MAX || 30);
export function reaktionTabellen(d) {
d.exec(`
/* Genau EINE Zeile. Die Sperre steht in der Tabelle und nicht im
Programm: Ein Programm kann man umgehen, eine Bedingung nicht. */
CREATE TABLE IF NOT EXISTS reaktion (
id INTEGER PRIMARY KEY CHECK (id = 1),
stand TEXT NOT NULL DEFAULT 'zu'
CHECK (stand IN ('zu','vorbereitung','live')),
titel TEXT NOT NULL DEFAULT '',
video TEXT NOT NULL DEFAULT '',
vorschau TEXT NOT NULL DEFAULT '',
beginnt_am TEXT,
host_id INTEGER REFERENCES personen(id) ON DELETE SET NULL,
layout TEXT NOT NULL DEFAULT 'kino',
laeuft INTEGER NOT NULL DEFAULT 0,
sekunde REAL NOT NULL DEFAULT 0,
stand_seit TEXT NOT NULL DEFAULT '',
gestartet_am TEXT,
geaendert TEXT NOT NULL DEFAULT ''
);
/* Wer gerade mit Kamera dabei ist. Der Host steht NICHT hier --
er ist an der Sendung selbst vermerkt. Ein Gast, der geht,
wird geloescht; wer stumm ist, bleibt stehen. */
CREATE TABLE IF NOT EXISTS reaktion_gaeste (
person_id INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE,
seit TEXT NOT NULL,
stumm INTEGER NOT NULL DEFAULT 0,
platz INTEGER NOT NULL DEFAULT 1
);
/* Wer gerade zusieht. Wird beim Verlassen geloescht und von der
Pflege entfernt, wenn sich jemand zwei Minuten nicht meldet.
Daraus kommt die Zuschauerzahl -- und die Entscheidung, wer
noch ein Kamerabild bekommt. */
CREATE TABLE IF NOT EXISTS reaktion_dabei (
person_id INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE,
seit TEXT NOT NULL,
gesehen TEXT NOT NULL,
sicht INTEGER NOT NULL DEFAULT 0
);
/* Der Live-Chat. Eigene Tabelle und nicht der Hauschat: Was hier
gesagt wird, gehoert zu dieser einen Sendung und ist danach
vorbei. Im Hauschat wuerde es die Gespraeche der Leute
ueberschwemmen, und die Moderation waere eine andere. */
CREATE TABLE IF NOT EXISTS reaktion_chat (
id INTEGER PRIMARY KEY AUTOINCREMENT,
person_id INTEGER REFERENCES personen(id) ON DELETE SET NULL,
name TEXT NOT NULL DEFAULT '',
rolle TEXT NOT NULL DEFAULT '',
text TEXT NOT NULL,
erstellt TEXT NOT NULL,
weg_am TEXT,
weg_von INTEGER REFERENCES personen(id) ON DELETE SET NULL
);
/* Was gelaufen ist. Eine Sendung je Zeile, erst beim Beenden. */
CREATE TABLE IF NOT EXISTS reaktion_verlauf (
id INTEGER PRIMARY KEY AUTOINCREMENT,
titel TEXT NOT NULL DEFAULT '',
video TEXT NOT NULL DEFAULT '',
host_id INTEGER REFERENCES personen(id) ON DELETE SET NULL,
begonnen TEXT,
beendet TEXT NOT NULL,
zuschauer INTEGER NOT NULL DEFAULT 0,
beitraege INTEGER NOT NULL DEFAULT 0
);
/* ==== DIE WARTESCHLANGE ======================================
Was als Naechstes laeuft. Eine Zeile je Video, die Spalte „platz“ gibt
die Reihenfolge.
SIE IST NICHT DASSELBE WIE DER VERLAUF. Der Verlauf sagt, was
gelaufen IST -- die Warteschlange, was laufen SOLL. Beides in
eine Tabelle zu legen waere sparsam und falsch: Ein Eintrag
muesste dann „schon gelaufen ja/nein" tragen, und jede Abfrage
im Haus muesste diese Frage mitstellen. Vergisst sie eine,
steht ein Video zweimal im Abend.
DER TITEL STEHT HIER MIT DRIN und wird nicht jedes Mal neu bei
YouTube erfragt. Sonst haengt die Anzeige der Liste an einem
fremden Dienst: Ist er langsam, laedt das Pult langsam; ist er
weg, steht dort nichts. Einmal holen, hinlegen, fertig. */
CREATE TABLE IF NOT EXISTS reaktion_liste (
id INTEGER PRIMARY KEY AUTOINCREMENT,
video TEXT NOT NULL,
titel TEXT NOT NULL DEFAULT '',
platz INTEGER NOT NULL DEFAULT 0,
von_id INTEGER REFERENCES personen(id) ON DELETE SET NULL,
gesetzt_am TEXT NOT NULL
);
CREATE INDEX IF NOT EXISTS idx_reaktion_liste_platz
ON reaktion_liste (platz, id);
CREATE INDEX IF NOT EXISTS idx_reaktion_chat_zeit
ON reaktion_chat (weg_am, id);
CREATE INDEX IF NOT EXISTS idx_reaktion_dabei_gesehen
ON reaktion_dabei (gesehen);
`);
/* DIE EINE ZEILE ANLEGEN, WENN ES SIE NOCH NICHT GIBT.
`INSERT OR IGNORE` und nicht „erst fragen, dann schreiben": Zwei
Anfragen gleichzeitig beim ersten Start wuerden sonst beide
„gibt es nicht" lesen und beide schreiben wollen. */
d.prepare(`INSERT OR IGNORE INTO reaktion
(id, stand, stand_seit, geaendert) VALUES (1, 'zu', ?, ?)`)
.run(new Date().toISOString(), new Date().toISOString());
/* ==== NACHGEWACHSENE SPALTEN ====================================
`ALTER TABLE ... ADD COLUMN` und NICHT „Tabelle neu bauen und
umkopieren". Am 11.09.2026 hat genau dieses Umkopieren an
anderer Stelle drei Spalten mit Inhalt verschluckt, ohne
Fehlermeldung und bei unveraenderter Zeilenzahl -- weil die
Spaltenliste von Hand abgeschrieben war. Eine Liste, die
niemand pflegt, kann nicht veralten; `ADD COLUMN` braucht gar
keine. */
const da = new Set(d.prepare("PRAGMA table_info(reaktion)").all().map((z) => z.name));
if (!da.has("video_titel")) {
/* Der Name des laufenden Videos, einmal bei YouTube geholt.
Ohne ihn stuende im Pult und auf der Wartetafel nur die
elfstellige Kennung -- die sagt niemandem etwas. */
d.exec("ALTER TABLE reaktion ADD COLUMN video_titel TEXT NOT NULL DEFAULT ''");
console.log("[reaktion] Spalte video_titel angelegt.");
}
}