Files
dogfather-universe/server/reaktion-tabellen.js
T
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.
2026-09-28 08:16:49 +02:00

265 lines
12 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"];
/** Wer im Live-Chat schreiben darf.
*
* Filipes Notiz nennt „Chat" als eine der acht Host-Steuerungen.
* Gemeint ist nicht die Moderation -- die gab es schon -- sondern
* der Chat selbst: Einen Beitrag wegzunehmen, nachdem er stand, ist
* etwas anderes, als ihn gar nicht erst zuzulassen.
*
* DREI STUFEN UND NICHT ZWEI. „Zu" ist in einer Sendung fast immer
* zu viel -- dann sitzen alle vor einem stummen Fenster. Die
* mittlere Stufe ist die, die man wirklich braucht: Es wird laut,
* das Team ordnet kurz, danach geht es wieder auf. */
export const CHAT_MODI = ["offen", "team", "zu"];
/** 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("chat_modus")) {
/* Wer im Live-Chat schreiben darf. Gilt fuer die ganze Sendung,
nicht je Person -- deshalb hier und nicht an den Zusehenden. */
d.exec("ALTER TABLE reaktion ADD COLUMN chat_modus TEXT NOT NULL DEFAULT 'offen'");
console.log("[reaktion] Spalte chat_modus angelegt.");
}
const dabei = new Set(
d.prepare("PRAGMA table_info(reaktion_dabei)").all().map((z) => z.name));
if (!dabei.has("kamera_aus")) {
/* Wer sein Bild gerade abgeschaltet hat.
AN DIESER TABELLE UND NICHT AN DEN GAESTEN: Hier steht, wer
gerade da ist -- Host, Gaeste und Zuschauer in einer Liste.
Genau die richtige Lebensdauer: Wer geht, nimmt seinen Zustand
mit, und die Pflege raeumt ihn ohnehin weg. */
d.exec("ALTER TABLE reaktion_dabei ADD COLUMN kamera_aus INTEGER NOT NULL DEFAULT 0");
console.log("[reaktion] Spalte kamera_aus angelegt.");
}
if (!dabei.has("mikro_aus")) {
/* Und dasselbe fuers Mikro. Wer sich selbst stummschaltet und
trotzdem redet, saehe sonst bei allen anderen ein ganz
normales Fenster -- niemand merkt, dass nichts ankommt, und er
selbst am wenigsten. */
d.exec("ALTER TABLE reaktion_dabei ADD COLUMN mikro_aus INTEGER NOT NULL DEFAULT 0");
console.log("[reaktion] Spalte mikro_aus angelegt.");
}
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.");
}
}