DogFatherGitandClaude Opus 5
015ac7738e
Filipe hat die Kachel benutzt und bekam "Ging nicht." Im Protokoll des
Servers stand der Grund; im Kasten stand er nicht. Beides ist jetzt
behoben -- und beim Nachmessen kam ein groesserer Befund heraus.
DER BEFUND: DIE SEITE KOMMT LEER AN
Gemessen am 07.10.2026, von zwei Leitungen und auf fuenf Wegen:
ehrliche Kennung, accept text/html 17 KB, keine Daten
ehrliche Kennung + Browser-Accept 17 KB, keine Daten
Browser-Kennung 17 KB, keine Daten
Browser-Kennung + Accept + Sprache 17 KB, keine Daten
ganz ohne eigene Koepfe 17 KB, keine Daten
zweiter Abruf MIT Keksen 17 KB, keine Daten
echtes Chromium (headless) 17 KB, LEERE Seite
Titel "Campaign", leerer Koerper, zwei Skripte (tiktok-environment,
gfdatav1). Dasselbe fuer Filipes neue Kampagne UND fuer
"Gipfelstuermer", von meinem Rechner wie vom Server.
Damit traegt eine Annahme des Bauplans nicht: "HTML 1.100.298
Zeichen, serverseitig gerendert". Die 1,1-MB-Seiten, an denen der
Bauplan entwickelt wurde, stammen aus einer echten Browsersitzung.
Auf einen gewoehnlichen Abruf baut TikTok die Seite nicht mehr auf.
Ob das voruebergehend ist (Modern.js kann SSR abstufen -- die
gespeicherten Seiten tragen "renderLevel":2) oder bleibt, laesst
sich an einem Abend nicht sagen. Der Weg bleibt deshalb eingebaut:
Kommt die Seite wieder mit Daten, laeuft alles sofort.
WAS DER MENSCH DAVOR JETZT SIEHT
Der Leser unterscheidet HUELLE von UMBAU. Das sind zwei sehr
verschiedene Lagen: Bei einem Umbau ist etwas zu reparieren, bei
einer Huelle kann niemand etwas machen -- und soll das hoeren statt
zu suchen. Die Meldung sagt die Groesse, sagt "das liegt nicht an
dir und nicht am Link" und nennt den naechsten Schritt.
"umgebaut" steht dort ausdruecklich NICHT mehr: Dieser Satz haette
ihn auf die falsche Suche geschickt.
UND NIE WIEDER "Ging nicht."
Der Verlust der Meldung liess sich NICHT nachstellen -- 403 und 502
kommen beide woertlich im Kasten an, jetzt in bild-kampagne
gemessen (25 Messungen). Ein Ersatztext, der nichts sagt, ist aber
auch ohne bekannte Ursache falsch: Er laesst raten. Er nennt jetzt
die Nummer der Antwort und sagt, wo mehr steht.
GEPRUEFT
pruef-kampagne-lesen 108 -> 112 (Huelle und Umbau getrennt, mit
Gegenprobe: eine fremde Seite gilt NICHT als Huelle) ·
pruef-kampagne 99 -> 102 (fuenf verschiedene Saetze fuer fuenf
Faelle) · bild-kampagne 20 -> 25 (zeigt der Kasten den Grund?) ·
pruef-struktur, pruef-eventkarte 94, pruef-agentur 62,
pruef-css-klassen 39, pruef-zeichen 8, pruef-deutsche-texte 12
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=202610071759" />
|
||
</head>
|
||
<body class="obs-buehne">
|
||
<div id="platz"></div>
|
||
<script src="assets/js/werbung.js?v=202610071759" defer></script>
|
||
<script src="assets/js/buehne.js?v=202610071759" defer></script>
|
||
</body>
|
||
</html>
|