Connect-Last

Chatlix Connect läuft im Hintergrund auf deinem Stream-PC und hält die Brücke zwischen Chatlix-Cloud, OBS und optional deinen Spielen/Lichtern. Diese Seite erklärt, wie viel Ressourcen Connect wirklich verbraucht und welche Intervalle dahinterstecken.

Baseline-Verbrauch

Im Idle-Zustand — gepairt, OBS verbunden, keine aktive Game-Watcher-Pipeline:

• RAM: unter 100 MB.
• CPU: unter 5% auf einem aktuellen Mid-Range-Prozessor.
• Netzwerk: minimal, Bridge-Heartbeat läuft persistent mit Auto-Reconnect, nicht als simples Polling.

Die tatsächlichen Hintergrund-Intervalle

Aus dem aktuellen Connect-Code — das sind die Zyklen, die konstant im Hintergrund laufen, unabhängig davon ob du gerade streamst (Quellenangabe „main.js" der Vorversion war falsch, Connect ist modular aufgebaut):

• OBS-Status-Refresh: alle 10 Sekunden (Snapshot an den Server) — im Code als STATE_PUSH_INTERVAL_MS = 10_000 bestätigt.
• Lokale Intent-Poller (Custom-Scripts, lokaler Sound, lokaler Input): alle 2 Sekunden — leichtgewichtig, rein lokal. Das ist kein einzelner „Core-State-Sync", sondern mehrere kleine Poller mit demselben Intervall.
• Game-Watcher-Heartbeat: alle 30 Sekunden — bestätigt im separaten Game-Watcher-Prozess (HEARTBEAT_INTERVAL_MS = 30 * 1000), nicht in Connect selbst.

Für eine feste „Game-Detection alle 20 Sekunden" und eine periodische „Licht-Discovery alle 90 Sekunden" gibt es keinen Beleg im Code: Die Geräte-Discovery für Lighting-Backends (Hue & Co.) läuft als einmaliger Scan mit wenigen Sekunden Timeout, ausgelöst durch Nutzeraktion oder Verbindungsaufbau, nicht als Dauerschleife alle 90 Sekunden. Diese beiden Zahlen wurden aus der Vorversion entfernt, weil sie sich nicht verifizieren ließen.

Keiner dieser Zyklen ist einzeln teuer, aber in Summe erklären sie, warum Connect nie ganz auf 0% CPU fällt — das ist normales Verhalten, kein Leck.

Was die Last hochzieht

1. Game-Watcher

Der Game-Watcher pollt aktive Prozesse und kann bei bestimmten Spiele-Integrationen (RCON-Verbindungen, Live-Client-APIs) zusätzliche Last erzeugen. Wenn du Game-Watcher nicht aktiv nutzt, deaktiviere die Integration statt sie nur ungenutzt laufen zu lassen.

2. Lighting-Discovery

Die Netzwerk-Suche nach Hue/Lifx-artigen Backends (SSDP/mDNS-artige Probes) läuft als kurzer, einmaliger Scan (wenige Sekunden), nicht als Dauerschleife. Auf sehr großen Heimnetzwerken (viele VLANs/Subnetze) kann ein einzelner Scan minimal länger dauern — in der Praxis meist vernachlässigbar.

3. Replay-Buffer-Uploads

Wenn du Replay-Highlights direkt aus Connect hochlädst (Replay-Bridge), entsteht kurzzeitig echte Netzwerk- und CPU-Last durchs Encodieren/Hochladen — das ist ein bewusster Peak, kein Dauerzustand.

OBS-Anbindung ist kein Last-Treiber

Die OBS-Kommunikation selbst (Status-Push alle 10s, Round-Trip-RPC bei Aktionen mit 200ms–15s Timeout) ist bewusst leichtgewichtig gehalten und praktisch nie die Ursache für spürbare Last — auch nicht bei vielen gleichzeitigen Overlay-Aktionen. Für Browser-Source-lastige Performance-Probleme siehe stattdessen OBS-Performance.

Troubleshooting bei ungewöhnlich hoher Last

1. Connect neu starten — löst die meisten schleichenden Leaks nach langer Laufzeit.
2. Log prüfen (connect.log) auf wiederholte Fehler/Reconnect-Schleifen — eine kaputte Verbindung, die ständig neu verhandelt, verbraucht spürbar mehr als eine stabile.
3. Nicht genutzte Integrationen (Lighting, Game-Watcher, Replay-Bridge) deaktivieren, statt sie im Hintergrund mitlaufen zu lassen.