Direkt zum Hauptinhalt

Cinematics Troubleshooting

Nach jedem Fire im Reaction Lab zeigt die Seite einen Health-Snapshot pro Teilaktion (Lighting, Overlay, Feed). Die Status-Werte dort (ok / no-device / no-bridge / failed) sind die schnellste Fehlerquelle — diese Seite erklärt, was dahintersteckt.

Cinematic läuft, aber kein Licht

Der Lighting-Status im Health-Snapshot sagt dir sofort, welcher Fall vorliegt:

  • no-device — kein Lighting-Gerät angelegt oder das Gerät ist auf inaktiv gestellt. Leg eins unter /dashboard/lighting an bzw. aktiviere es.
  • no-bridge — der Backend-Publish war erfolgreich, aber es gab subscribers: 0, also keinen Listener im LAN. Das betrifft WLED, Hue, Nanoleaf und Yeelight, weil die über user:<uid>:lights laufen und einen aktiven Zuhörer brauchen: entweder einen offenen Dashboard-Tab mit /dashboard/lighting, den lokalen Game-Watcher-Bridge-Prozess (127.0.0.1:9878) oder Chatlix Connect mit laufendem Smart-Lights-Modul.
  • failed — der Provider selbst hat den Fire abgelehnt, z.B. invalid_preset oder *_publish_failed. Govee/LIFX/Tapo laufen direkt über deren Cloud-API vom Backend aus, brauchen also keine Bridge — hier ist ein failed meistens ein Cloud-/Auth-Problem, kein LAN-Problem.

Über Chatlix Connect gekoppelte Smart-Lights (nicht die klassischen Lighting-Geräte) laufen zusätzlich über ein eigenes Rollen-Filter: jede Lampe kann in ihrer Konfiguration auf bestimmte Cinematics eingeschränkt sein (cinematic_raid, cinematic_horror, cinematic_celebration, oder cinematic_all für alle fünf). Reagiert eine Connect-Lampe nur bei manchen Cinematics nicht, prüf zuerst ihre Rolle statt die Bridge-Verbindung zu verdächtigen.

Cinematic läuft, aber kein Overlay-Effekt in OBS

  1. Ist die Chatlix-Browser-Source überhaupt in OBS eingebunden und in der aktuell aktiven Szene sichtbar? Eine versteckte oder nicht geladene Quelle bekommt das Event zwar gepublisht, rendert aber nichts.
  2. Steht die Browser-Source auf „Quelle aktiv lassen, wenn nicht sichtbar"? Sonst pausiert OBS das JS im Hintergrund und der Effekt verpufft, weil das Overlay den Publish verpasst.
  3. Cache-Problem: einmal Refresh auf der Browser-Source klicken, dann erneut im Reaction Lab feuern.
  4. Beachte: das Overlay-Event geht an jedes Overlay deines Accounts gleichzeitig, nicht nur an ein ausgewähltes. Wenn du mehrere Overlay-URLs im Einsatz hast, feuern theoretisch alle — prüf, ob du versehentlich die falsche URL in OBS eingebunden hast.

Der Chat-Text der Cinematic taucht nicht im echten Twitch-Chat auf

Das ist kein Bug. Die Chat-Teilaktion einer Cinematic ist in V1 nur eine Vorschau im Dashboard (preview_only_v1) — es wird technisch nichts über den Bot in deinen Chat gepostet. Brauchst du einen echten Chat-Post bei einem bestimmten Event, baue das über eine eigene Chat-Automation, unabhängig von Cinematics.

Game-Watcher-Event löst keine Cinematic aus

  1. Läuft der Game-Watcher überhaupt und meldet er Events? Prüf unter /dashboard/game-watcher bzw. die Session-Cards, ob aktuell Events reinkommen.
  2. Ist das Event-Paar (Spiel, Event-Typ) in GameEventCinematicMapper überhaupt gemappt? Manche Events sind absichtlich stumm geschaltet (player_join, chat_message, research_completed u.ä.) — siehe die Tabelle auf der Auslösen-Seite.
  3. Severity zu niedrig? low und normal feuern nie automatisch eine Cinematic, nur high/critical oder ein spezifisches Mapping.
  4. 30-Sekunden-Cooldown pro Nutzer + Slug: Wenn kurz vorher schon dieselbe Cinematic automatisch gefeuert hat, wird der nächste Treffer als cooldown_skip übersprungen — kein Fehler, einfach Anti-Spam.

Reaction Lab zeigt „Effekt ist in deinen Settings aus"

Im Reaction Lab kannst du Horror- und Flash-Effekte pro Account deaktivieren (z.B. wegen Fotosensibilität oder weil dir horror_jumpscare zu hart ist). Diese Einstellung blockt den Fire clientseitig, bevor überhaupt ein Request rausgeht — dein Klick auf die Kachel bringt in dem Fall bewusst gar keinen Backend-Call. Schalte die Einstellung im Cinematic-Settings-Panel der Seite wieder an, wenn du den Effekt doch willst.

Häufige Backend-Fehlercodes beim Fire

  • unknown_cinematic (HTTP 400) — falscher oder leerer Slug. Passiert nur bei eigenen API-Aufrufen, nicht über die normale UI.
  • csrf_invalid (HTTP 403) / session_required (HTTP 403) — deine Dashboard-Session ist abgelaufen. Seite neu laden und neu einloggen.
  • no_publisher — Redis ist gerade nicht erreichbar. Betrifft dann Lighting, Feed und Overlay gleichzeitig — wenn alle drei Teilaktionen an einem Fire fehlschlagen, ist das der Verdacht, nicht ein einzelnes defektes Gerät.
  • internal_error (HTTP 500) — unerwarteter Fehler im Handler. Kommt immer als sauberes JSON zurück, nie als nackte HTML-500-Seite. Wenn das öfter auftritt, User-Hash aus Dashboard → Profil mitschicken.

Lighting-Provider antwortet mit Fehlercode

  • Govee Cloud: 429 = Rate-Limit erreicht. Kurz warten, erneut feuern.
  • Tapo Cloud: Login schlägt fehl (tapo_login_failed) — Zugangsdaten im Lighting-Menü prüfen, Tapo macht bei jedem Fire einen frischen Login (kein Token-Cache in V1).
  • LIFX: lifx_fire_failed meist ein abgelaufener API-Token — im Lighting-Menü neu verbinden.
  • WLED / Hue / Nanoleaf / Yeelight: kein direkter HTTP-Fehler sichtbar, weil das über die Bridge läuft — hier zählt no-bridge (siehe oben), nicht ein Cloud-Fehlercode.

Cinematic taucht überhaupt nicht im Reaction-Feed auf

  • Browser-Cache: hart neu laden (Strg+Shift+R).
  • Dashboard-Tab im Hintergrund: die Live-Verbindung pausiert in machen Browsern bei inaktiven Tabs. Tab in den Vordergrund holen und erneut feuern.
  • Feed-Filter oben in der Seite steht evtl. nicht auf „Alle" — Filter auf cinematic oder all stellen.
  • Wenn danach immer noch nichts ankommt: Support kontaktieren mit deinem User-Hash (Dashboard → Profil → „User-Hash kopieren") und der ungefähren Uhrzeit des Fires — der Eintrag lässt sich dann in chain_reaction_events nachschlagen.