/* ===================================================================== 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. * * Filipe: „meine kamera groesser machen video kleiner. nur mein * bild, nur das video, moeglichkeit zwischen allem zu wechseln so * wie ich will." * * Die ersten drei sind Groessenverhaeltnisse, die letzten zwei ein * WEGLASSEN -- und das ist etwas anderes. „nur_video" und * „nur_kamera" braucht man vor allem fuer OBS: Dort liegt die * Kamera ohnehin als eigene Quelle, und die Buehnenseite soll dann * nichts doppelt zeigen. */ export const LAYOUTS = ["kino", "gleich", "kamera", "nur_video", "nur_kamera"]; /** Wie gross die Kamerafenster sind (Faktor auf die Grundgroesse). * * Filipe: „die verschiedenen groessen von kamera." * * SECHS STUFEN UND KEIN SCHIEBER. Ein Schieber verspricht eine * stufenlose Einstellung; im Live sucht dann jemand mitten in der * Sendung nach „dem richtigen Wert" statt zu senden. Sechs Stufen * trifft man blind. * * DIE GRENZEN SIND GEMESSEN. Unter 0,6 ist der Name unter dem Bild * nicht mehr zu lesen (das Schild steht bei 11,52 px und waechst * nicht mit); ueber 2 deckt ein einzelnes Fenster bei „Video gross" * mehr als die Haelfte der Leinwand zu, und dann ist es keine * Anordnung mehr, sondern die falsche. */ export const KAMERA_GROESSEN = [0.6, 0.8, 1, 1.25, 1.5, 2]; /** In welcher Ecke die Kamerafenster liegen. * * NUR BEI „VIDEO GROSS" -- in den anderen Anordnungen stehen sie * mittig oder fuellen die Flaeche, da gibt es keine Ecke. Genau das * sagt die Regie auch, statt einen Knopf anzubieten, der nichts * tut. * * WARUM ES DIESE EINSTELLUNG UEBERHAUPT BRAUCHT: Unten rechts liegt * bei TikTok die Knopfreihe, bei YouTube die Fortschrittsleiste, * und Untertitel stehen fast immer unten. Eine feste Ecke ist eine, * die bei jeder zweiten Plattform falsch ist. */ export const KAMERA_ECKEN = ["ol", "or", "ul", "ur"]; /** Die Geschwindigkeiten, die es gibt. * * YouTube kann 0,25 bis 2. Die 0,25 fehlt hier mit Absicht: Bei * einem Viertel klingt Sprache wie ein defektes Band, und in einer * Live-Sendung, in der nebenher geredet wird, ist das keine * Geschwindigkeit, sondern ein Aussetzer. * * WICHTIG IST, DASS SIE FUER ALLE GILT. Wer sie nur bei sich * umstellt, redet ueber eine Stelle, die die anderen noch nicht * gesehen haben -- deshalb steht sie an der Sendung und nicht im * Browser. */ export const TEMPI = [0.5, 0.75, 1, 1.25, 1.5, 2]; /** Wie lange eine Stummschaltung hoechstens gilt (Minuten). * * Eine Stunde. Wer laenger etwas braucht, nimmt die Massnahmen des * Treffs -- die haben eine Begruendungspflicht, eine Frist in Tagen * und stehen in der Geschichte. Eine Stummschaltung ueber Stunden * waere eine Sperre ohne all das. */ export const STUMM_MAX_MINUTEN = 60; /** So lange bleibt eine erledigte Meldung stehen. * * DREISSIG TAGE, UND NICHT LAENGER. Eine Meldung enthaelt drei * Dinge, die zusammen empfindlich sind: was jemand geschrieben hat, * wer es war und wer ihn gemeldet hat. Solange dieselbe Sendung * laeuft, ist das die Arbeitsgrundlage der Moderation; danach ist es * eine Liste darueber, wer sich mal danebenbenommen hat -- und wer * das gemeldet hat. * * Meistens sind sie ohnehin frueher weg: Der Live-Chat wird beim * Beenden der Sendung geloescht, und die Meldungen haengen mit * `ON DELETE CASCADE` daran. Diese Frist greift nur fuer den Fall, * dass eine Sendung nie ordentlich beendet wurde. */ export const MELDUNG_TAGE = 30; /** Die zwei kurzen Massnahmen der Sendung. */ export const MASSNAHMEN = ["stumm", "raus"]; /** 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 ); /* ==== DIE KURZEN MASSNAHMEN EINER SENDUNG ==================== „stumm" darf zusehen, aber nicht schreiben. „raus" ist aus dieser Sendung heraus. BEIDES ENDET MIT DER SENDUNG -- wie die Gaeste und der Live-Chat auch. Was laenger gelten soll, gehoert in die Massnahmen des Treffs: Die haben eine Begruendungspflicht, eine Frist in Tagen und stehen in der Geschichte. Ein Fuenf-Minuten-Aerger gehoert dort nicht hinein. EINE ZEILE JE PERSON. Zwei Massnahmen gegen dieselbe Person waeren zwei Antworten auf dieselbe Frage -- und dann entscheidet die Reihenfolge, welche gilt. */ CREATE TABLE IF NOT EXISTS reaktion_massnahmen ( person_id INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE, art TEXT NOT NULL CHECK (art IN ('stumm','raus')), /* Leer heisst: bis zum Ende der Sendung. */ bis TEXT, grund TEXT NOT NULL DEFAULT '', von INTEGER REFERENCES personen(id) ON DELETE SET NULL, erstellt TEXT NOT NULL ); /* Gemeldete Beitraege. Eigene Tabelle und nicht die des Treffs: Die zeigt auf „eintraege“, hier geht es um „reaktion_chat“ -- ein anderer Gegenstand, und ein Fremdschluessel kann nicht auf zweierlei zeigen. */ CREATE TABLE IF NOT EXISTS reaktion_meldungen ( id INTEGER PRIMARY KEY AUTOINCREMENT, beitrag_id INTEGER NOT NULL REFERENCES reaktion_chat(id) ON DELETE CASCADE, melder_id INTEGER REFERENCES personen(id) ON DELETE SET NULL, grund TEXT NOT NULL DEFAULT '', erstellt TEXT NOT NULL, erledigt_am TEXT, erledigt_von INTEGER REFERENCES personen(id) ON DELETE SET NULL ); /* DIESELBE PERSON MELDET DENSELBEN BEITRAG EINMAL. Ohne diese Sperre koennte einer allein eine Liste fuellen, und die Moderation sieht vor lauter Meldungen die echte nicht. */ CREATE UNIQUE INDEX IF NOT EXISTS idx_reaktion_meldung_einmal ON reaktion_meldungen (beitrag_id, melder_id); CREATE INDEX IF NOT EXISTS idx_reaktion_meldung_offen ON reaktion_meldungen (erledigt_am, id); /* 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("bildschirm")) { /* WER GERADE SEINEN BILDSCHIRM TEILT. Es ist eine eigene Spalte und nicht „kamera_aus umgedreht": Beim Teilen geht ein Bild hinaus, es ist nur ein anderes. Wer beides in eine Spalte legte, koennte nachher nicht mehr sagen, ob da ein schwarzes Fenster steht oder ein Schreibtisch. */ d.exec("ALTER TABLE reaktion_dabei ADD COLUMN bildschirm INTEGER NOT NULL DEFAULT 0"); console.log("[reaktion] Spalte bildschirm angelegt."); } 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("kamera_gross")) { /* Groesse und Ecke der Kamerafenster. Beide gelten fuer die ganze Sendung -- wer sendet, stellt das Bild fuer alle ein. */ d.exec("ALTER TABLE reaktion ADD COLUMN kamera_gross REAL NOT NULL DEFAULT 1"); d.exec("ALTER TABLE reaktion ADD COLUMN kamera_ecke TEXT NOT NULL DEFAULT 'ur'"); console.log("[reaktion] Spalten fuer die Kameragroesse angelegt."); } if (!da.has("tempo")) { /* Die Geschwindigkeit gilt fuer die ganze Sendung. REAL und nicht INTEGER: 0,75 und 1,25 sind die beiden, die man im Alltag am haeufigsten nimmt. */ d.exec("ALTER TABLE reaktion ADD COLUMN tempo REAL NOT NULL DEFAULT 1"); console.log("[reaktion] Spalte tempo angelegt."); } if (!da.has("zweit_video")) { /* ==== DAS ZWEITE VIDEO ======================================== Drei Spalten und keine eigene Tabelle. Es ist GENAU EINES -- ein Umschalter hat zwei Seiten, sonst ist er eine Liste, und die gibt es schon (`reaktion_liste`). DIE SEKUNDE IST DER GANZE PUNKT. Ohne sie waere „hin und her" ein Neustart von vorn, und dann schaltet niemand zweimal. Beim Tauschen wird die Stelle des gerade laufenden Videos hier hineingeschrieben und die gemerkte Stelle des anderen herausgeholt. */ d.exec("ALTER TABLE reaktion ADD COLUMN zweit_video TEXT NOT NULL DEFAULT ''"); d.exec("ALTER TABLE reaktion ADD COLUMN zweit_titel TEXT NOT NULL DEFAULT ''"); d.exec("ALTER TABLE reaktion ADD COLUMN zweit_sekunde REAL NOT NULL DEFAULT 0"); console.log("[reaktion] Spalten fuer das zweite Video 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."); } }