DogFatherGitandClaude Opus 5
4503b1a475
Diene im Support (vor 5 Tagen): „Die Benachrichtigungen werden nicht
angezeigt, wenn neue Nachrichten reinkommen. Erst, wenn man die App
öffnet."
ERST GEMESSEN, WAS NICHT DAS PROBLEM IST. Am echten Bestand
nachgesehen: Diene HAT ein angemeldetes Geraet (Android, Chrome, seit
dem 29.09.), und alle zehn Geraete im Haus melden `fehler = 0`. An
der Zustellung liegt es nicht.
DANN NACHGESTELLT (pruef-abzeichen, Abschnitt 8):
Verbindung offen -> KEINE Benachrichtigung
Verbindung zu -> sie kommt
Genau sein Befund.
DER GEDANKE WAR RICHTIG, DIE FRAGE FALSCH. Im Quelltext stand:
if ((zuschauer.get(personId) || new Set()).size) continue;
und daneben die Begruendung -- „wer die Seite offen hat, sieht die
Nachricht ohnehin; ihm auch noch eine Meldung aufs Handy zu schicken
ist der schnellste Weg, dass er Benachrichtigungen abschaltet." Das
stimmt. Nur beantwortet `zuschauer` eine ANDERE Frage: ob eine
VERBINDUNG offen ist. Ein Handy mit der App im Hintergrund haelt sie
weiter -- und der Server hielt Diene fuer anwesend, waehrend sein
Bildschirm schwarz war.
DIE SEITE WEISS ES, DER SERVER NICHT. `document.visibilityState` ist
die einzige Stelle, die den Unterschied kennt. Also sagt sie es --
ueber einen winzigen Weg (`/api/chat/sicht`), beim Aufbau, bei jedem
Wechsel und mit `keepalive` beim Weggehen.
MIT VERFALL, und das ist der wichtige Teil: Ein Geraet, das
abstuerzt, im Funkloch steht oder eingefroren wird, sagt gar nichts
mehr. Ohne Verfall bliebe es fuer immer „sichtbar" und fuer immer
still. Wer nicht widerspricht, gilt nach zweieinhalb Minuten als weg
-- eine Meldung zu viel ist laestig, eine zu wenig ist genau der
Fehler, den Diene gemeldet hat. Dazu alle Minute ein Lebenszeichen,
solange die App vorn liegt.
EINE STELLE FUER DIE FRAGE. Sie wurde an zwei Orten gestellt:
`siehtZu()` und eine Abschrift mitten in `chatEreignis`. Die
Abschrift war die kaputte. Jetzt fragen beide dieselbe Funktion.
GEPRUEFT -- vier Lagen, und die zweite ist die wichtigere
Gegenprobe:
App liegt hinten -> Meldung kommt (war: nichts)
sieht wirklich hin -> KEINE Meldung (Absicht bleibt)
App weggelegt -> Meldung kommt wieder
gar keine Verbindung -> Meldung kommt
Ohne die zweite Zeile hiesse die Reparatur nur „jetzt kommt immer
eine", und das waere der schnellste Weg, dass jemand
Benachrichtigungen abschaltet.
UND EINE PRUEFUNG HAT DEN FEHLER MITGETRAGEN. pruef-anruf-klingelt
hielt den WORTLAUT der kaputten Zeile fest -- genau das, wovor ihr
eigener Kommentar drei Zeilen darueber warnt („Die Pruefung hat den
alten Wortlaut bestaetigt statt sein Verhalten"). Sie prueft jetzt
beides: dass gefragt wird, und dass die Frage die richtige ist.
pruef-abzeichen 26/0, pruef-chat, pruef-anruf 132/0,
pruef-chat-kanaele 81/0, pruef-anruf-klingelt 25/0, pruef-push-ziel
38/0, pruef-arten 28/0, pruef-reaktion 421/0, pruef-struktur,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
70 lines
3.0 KiB
HTML
70 lines
3.0 KiB
HTML
<!doctype html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<title>Bühne – das laufende Video</title>
|
||
<!-- ======================================================================
|
||
DAS LAUFENDE VIDEO ALS BROWSER-QUELLE (28.09.2026)
|
||
|
||
Zeigt das Video, das gerade in der Reaction läuft — auf dieselbe
|
||
Sekunde wie bei allen anderen. Sonst nichts: kein Chat, keine
|
||
Kameras, keine Bedienung, kein Rand.
|
||
|
||
WARUM DIE EIGENE KAMERA HIER NICHT DRIN IST: Sie ist in OBS
|
||
direkt als Gerät verfügbar, in besserer Qualität und frei in
|
||
Größe und Lage. Den Umweg über den Browser zu nehmen hieße,
|
||
Qualität gegen nichts einzutauschen — und die Größe wäre dann
|
||
festgelegt statt frei.
|
||
|
||
Sind GÄSTE im Bild, kommen deren Kameras über eine
|
||
Direktverbindung an, und die braucht eine angemeldete Seite.
|
||
Dafür gibt es den Bühnenmodus der Reaction-Seite
|
||
(`reaktion.html?nur=buehne`), der als Fenster aufgenommen wird.
|
||
|
||
In OBS: Quelle → Browser → diese Adresse, 1920 × 1080,
|
||
„Steuerung anzeigen" aus.
|
||
====================================================================== -->
|
||
<style>
|
||
html, body {
|
||
margin: 0; padding: 0;
|
||
background: #000;
|
||
height: 100%; overflow: hidden;
|
||
font-family: "Segoe UI", system-ui, -apple-system, sans-serif;
|
||
}
|
||
#platz { position: fixed; inset: 0; }
|
||
#platz iframe { width: 100%; height: 100%; border: 0; display: block; }
|
||
|
||
/* ==== BEI „NUR KAMERA" GEHT DAS BILD AUS ========================
|
||
Sonst läge im Stream ein stehengebliebenes YouTube-Bild unter
|
||
den Kameras — und Filipe sähe es nicht, weil er in OBS auf
|
||
seine Szene schaut und nicht auf die Quelle.
|
||
|
||
`visibility` UND NICHT `display`. Ein Spieler, den man aus dem
|
||
Seitenaufbau nimmt, hört auf zu dekodieren; beim Zurückschalten
|
||
müsste er erst wieder an die richtige Stelle springen, und das
|
||
sehen dann alle. So läuft er weiter, nur eben unsichtbar, und
|
||
ist in derselben Sekunde wieder da. */
|
||
body[data-bild="aus"] #platz { visibility: hidden; }
|
||
|
||
/* Was zu sehen ist, wenn gerade nichts läuft. Schwarz und still --
|
||
eine Beschriftung stünde im Stream. Nur bei einem falschen
|
||
Schlüssel gibt es einen Hinweis, denn den sieht man sonst nie. */
|
||
.obs-fehler {
|
||
position: fixed; left: 16px; top: 16px;
|
||
padding: 10px 14px; border-radius: 10px;
|
||
background: rgba(140, 20, 30, .9); color: #fff; font-size: 14px;
|
||
}
|
||
</style>
|
||
<!-- DIE WERBEEINBLENDUNG. Dieselbe Datei wie in der Reaction-Seite:
|
||
Zwei Fassungen altern unterschiedlich, und dann sieht der Stream
|
||
anders aus als das, worueber geredet wird. -->
|
||
<link rel="stylesheet" href="assets/css/werbung.css?v=202609302348" />
|
||
</head>
|
||
<body class="obs-buehne">
|
||
<div id="platz"></div>
|
||
<script src="assets/js/werbung.js?v=202609302348" defer></script>
|
||
<script src="assets/js/buehne.js?v=202609302348" defer></script>
|
||
</body>
|
||
</html>
|