Direkt zum Hauptinhalt

Status auf Linux

Wichtig vorweg: Linux ist bei Chatlix Connect kein offiziell beworbenes Ziel-OS. Laut interner Open-Beta-Planung (OPEN_BETA_KNOWN_LIMITS.md) liegt der Fokus klar auf Windows; Linux-Anfragen werden aktuell mit "Windows zuerst, dein OS folgt nach Public-Cut" beantwortet. Trotzdem werden bei jedem Release automatisch Linux-Artefakte gebaut und ausgeliefert, und ein wachsender Teil der Community nutzt sie produktiv. Diese Seite beschreibt den tatsaechlichen Stand, keine Marketing-Aussage.

Zwei Varianten, nicht eine

Anders als frueher hier dokumentiert gibt es fuer Linux zwei komplett unterschiedliche Builds, die parallel gepflegt werden:

  • Desktop-App (empfohlen) — Electron-basierte GUI mit Tray, Einrichtungsassistent und OBS-Auto-Discovery. Ausgeliefert als .AppImage und als chatlix-connect-desktop-linux.tar.gz. Das ist dieselbe Codebasis wie die Windows-Desktop-App (connect/desktop, Electron-Builder-Target AppImage + tar.gz), nur ohne Windows-spezifische Signierung.
  • Headless-CLI-Binary (fuer Server/Streaming-Boxen ohne Desktop-Session) — ein mit pkg gebautes, statisch gebuendeltes Node-Binary chatlix-connect-linux ohne GUI, ohne Tray, ohne Fenster. Das ist die Variante, die sich fuer einen systemd-User-Service eignet (siehe Seite « Systemd-Unit (optional) »), weil sie keine grafische Session braucht.

Beide Varianten teilen sich denselben Verbindungs-Client (WebSocket zu Chatlix, OBS-Modul, Game-Watcher-Anbindung), aber nicht denselben Konfigurationsort — siehe unten. Wenn du unsicher bist, welche Variante du hast: Die Desktop-App zeigt ein Tray-Icon und ein Fenster, das CLI-Binary läuft nur im Terminal.

Status pruefen

Fuer das CLI-Binary bringt die App eingebaute Diagnose-Kommandos mit:

./chatlix-connect-linux doctor
./chatlix-connect-linux repair

doctor prueft Config, Verbindung und OBS-Modul und gibt eine Zusammenfassung aus (kein separates status-Subkommando mehr — die fruehere Doku dazu war veraltet). Ohne Argumente startet die App normal und zeigt im Terminal eine Live-Status-Konsole mit:

  • Verbindungsstatus — VERBUNDEN, VERBINDET ERNEUT, VERBINDET, ANMELDUNG FEHLGESCHLAGEN, TEILWEISE VERBUNDEN oder NICHT VERBUNDEN. Die Labels sind bewusst deutsch, nicht die englischen internen State-Namen.
  • OBS-Verbindung — Host:Port aus der Config (Standard 127.0.0.1:4455, OBS-WebSocket v5 ab OBS 28). Bei Fehler steht der Klartext-Fehler dabei (auth failed, connection refused etc.).
  • Wiederverbindungen — Zaehler getrennt nach Server- und OBS-Reconnects. Staendig steigende Zahlen deuten auf ein instabiles Netz oder OBS, das haeufiger neu startet als Connect.
  • Aktionszaehler — Szenenwechsel, Quellen-Toggles, Screenshots seit Start. Nuetzlich um zu sehen, ob Dashboard-Aktionen ueberhaupt ankommen.

Bei der Desktop-App siehst du denselben Status visuell im Hauptfenster bzw. im Tray-Menü, zusaetzlich zu den Menuepunkten fuer Logs oeffnen, OBS testen und Diagnose exportieren (aus den Windows-Helper-Skripten uebernommene Funktionen, unter Linux ueber das Electron-Menü statt .bat-Dateien).

Live-Status im Dashboard

Der Status wird parallel per Heartbeat an das Dashboard gemeldet und ist unter /dashboard/connect sichtbar. Das ist die Quelle der Wahrheit fuer Rewards und Actions, die Connect brauchen — wenn das Dashboard offline zeigt, helfen lokale VERBUNDEN-Meldungen nichts, dann stimmt meist der Token in der Config nicht mit dem Account im Dashboard ueberein.

Logs einsehen

Der Log-Ort haengt von der Variante ab — das ist der groesste Unterschied zur alten Doku, die pauschal ~/.local/share/chatlix-connect/ nannte:

  • CLI-Binary (portabel): Logs liegen relativ zur Binary selbst unter ./logs/connect.log, im selben Verzeichnis auch connect.json (Config), connect-status.json, crashes/ und diagnostics/. Der Code (src/core/paths.js) leitet das Wurzelverzeichnis explizit vom Ort der Binary ab (dirname(process.execPath)), nicht von $HOME.
  • Desktop-App (Electron): nutzt Electrons userData-Pfad. Unter Linux ist das ~/.config/Chatlix Connect/ (der Ordnername mit Leerzeichen kommt direkt aus app.setName('Chatlix Connect')). Darin liegen connect.json und ein logs/-Unterordner mit taeglich rotierenden Dateien chatlix-connect-YYYY-MM-DD.log (keine 5-MB-Groessenrotation wie beim CLI-Binary, sondern Datumsrotation).

Bei Problemen ist der Anfang einer Sitzung interessant (Config-Load, WS-Handshake), bei Reward- oder Action-Fehlern das Ende der aktuellsten Datei.

Im Vordergrund laufen lassen

Fuer kurze Sessions reicht es, das CLI-Binary in einem Terminal-Tab laufen zu lassen (Ctrl+C zum Beenden). Die Desktop-App laeuft normalerweise im Tray weiter, auch wenn du das Fenster schliesst — richtig beenden geht ueber "Beenden" im Tray-Menü oder pkill -f "Chatlix Connect". Fuer dauerhaften Headless-Betrieb ohne Desktop-Session nutzt du den User-Systemd-Service mit dem CLI-Binary (siehe « Systemd-Unit (optional) ») — die Desktop-App eignet sich dafuer nicht, sie braucht eine laufende grafische Session (X11; unter reinem Wayland ohne XWayland startet Electron in der Regel gar nicht oder nur mit --ozone-platform=x11).

Schnelltest

  1. Passende Variante starten (Desktop-App per Doppelklick/AppImage, oder CLI-Binary im Terminal).
  2. Im Dashboard unter /dashboard/connect pruefen, dass die Anzeige innerhalb weniger Sekunden auf online springt.
  3. Im Dashboard unter /dashboard/actions eine Test-Aktion ausloesen (z.B. eine OBS-Source togglen).
  4. Terminal-Log bzw. Log-Datei pruefen — die Aktion sollte als Event mit Zeitstempel durchlaufen und der Aktionszaehler im Live-Status hochzaehlen.

Wenn das funktioniert, ist die Basis-Verbindung sauber. Reward- oder Game-Watcher-spezifische Probleme sind dann eine Ebene darueber — siehe « Manuelle Installation » fuer den Game-Watcher.

Bekannte Linux-Eigenheiten

  • Wayland vs. X11: Lokale Input-Simulation und Bildschirm-bezogene Module (nut-js, fuer z.B. lokale Tastatur-/Maus-Aktionen) sind nativ auf X11 gebaut. Unter reinem Wayland (GNOME/KDE ohne XWayland-Kompatibilitaet) funktionieren diese Module nicht zuverlaessig oder gar nicht. Pruefe mit echo $XDG_SESSION_TYPE, ob du unter x11 oder wayland laeufst.
  • StreamDeck/USB-HID-Geraete: Die Anbindung nutzt node-hid, das auf Linux ohne passende udev-Regel keinen Zugriff auf das Geraet als normaler User bekommt (Fehlerbild: "cannot open device" trotz sichtbarem Geraet in lsusb). Es gibt aktuell keine mitgelieferte udev-Regel-Datei im Repo — du musst manuell eine Regel unter /etc/udev/rules.d/ fuer die Vendor/Product-ID deines Geraets anlegen und udevadm control --reload-rules ausfuehren, oder Connect testweise mit sudo starten um das Problem einzugrenzen (nicht fuer Dauerbetrieb).
  • AppImage und FUSE: Auf sehr schlanken Distros/Containern ohne libfuse2 startet die .AppImage nicht direkt (Fehler dlopen(): error loading libfuse.so.2). Siehe « Manuelle Installation » fuer den Workaround.