CCcam Protokollanalyse: Lesen& Debuggen von CCcam-Protokollen wie ein Profi

Wenn Ihr CCcam-Server Peers abbricht, Kanäle einfriert oder kryptische Zeilen ausgibt, die Sie nie analysiert haben, sind Sie nicht allein. Die meisten Leute, die ein Sharing-Setup betreiben, lesen ihre Protokolle nie, bis etwas kaputt geht — und dann starren sie auf eine Wand aus Text, ohne zu wissen, was normal ist und was ein Warnsignal darstellt. Dieser Leitfaden behandelt die besten Praktiken zur Analyse von CCcam-Protokollen, die ich aus Jahren des Betriebs und der Reparatur dieser Boxen, Feld für Feld, gelernt habe, damit Sie tatsächlich Probleme diagnostizieren können, anstatt zu raten.

Wo CCcam-Protokolle gespeichert sind und wie man ausführliches Logging aktiviert

In den meisten Linux-basierten Setups schreibt CCcam standardmäßig in/var/log/CCcam.log, vorausgesetzt, die Konfiguration hat überhaupt eine LOGFILE-Direktive gesetzt. Auf Enigma2-Boxen — Vu+, Dreambox, Zgemma, welches Image Sie auch verwenden — könnte dieser Pfad überhaupt nicht existieren, oder er wird umgeleitet nach/tmp/CCcam.log. Einige Images speichern es unter/media/hdd/, wenn Sie eine Festplatte angeschlossen haben, was ehrlich gesagt der richtige Ort ist, wenn Sie die Option haben.

Standardprotokollpfade und wie man sie umleitet

Öffnen Sie Ihre/etc/CCcam.cfg und suchen Sie nach dem LOGFILE-Schlüssel. Wenn er fehlt, fügen Sie ihn hinzu:

LOGFILE : /media/usb/CCcam.log

Das ist der wichtige Teil — zeigen Sie darauf auf einen USB-Stick oder ein Netzwerkfreigabe, nicht auf den internen Flash. Ich habe das vor Jahren auf einer Dreambox 800 HD auf die harte Tour gelernt, mit vielleicht 200 MB nutzbarem Flash. Ich ließ DEBUG über Nacht während einer Fehlersuche aktiviert, die Protokolldatei wuchs über das hinaus, was der Flash verarbeiten konnte, und die Box ließ sich am nächsten Morgen nicht mehr starten. Musste sie neu flashen. Totaler Zeitverlust eines Abends, der hätte vermieden werden können, wenn ich zuerst ein externes Laufwerk gemountet hätte.

DEBUG und Protokollebene in CCcam.cfg einstellen

Der Schlüssel, der die Ausführlichkeit steuert, ist einfach:

DEBUG : 1

Wenn Sie dies auf 1 setzen, erhalten Sie Verbindungsereignisse, ECM/EMM-Verkehr und Share-Aktivität. Einige Builds unterstützen höhere Werte (2 oder 3) für noch mehr Details, aber ehrlich gesagt ist DEBUG : 1 für 95% der Fehlersuche ausreichend. Höhere Werte fügen hauptsächlich EMM-Rauschen hinzu, das es schwieriger macht, die ECM-Zeilen zu finden, die Ihnen tatsächlich wichtig sind. Starten Sie den Daemon neu, nachdem Sie dies geändert haben —killall -9 CCcam&& /usr/bin/CCcam oder verwenden Sie das Neustart-Skript Ihres Images, je nachdem, wie es installiert ist.

Protokollrotation, damit Sie den Flash nicht füllen

Ausführliches Logging auf einem stark frequentierten Multi-Peer-Server kann Megabytes pro Stunde erzeugen. Wenn Sie aus irgendeinem Grund auf Flash protokollieren, richten Sie einen einfachen Truncationsjob ein. Ein Cron-Eintrag wie dieser hält die Dinge im Rahmen:

0 * * * * [ $(stat -c%s /media/usb/CCcam.log) -gt 5242880 ]&& > /media/usb/CCcam.log

Das überprüft die Dateigröße jede Stunde und löscht sie, wenn sie 5 MB überschreitet. Grob, aber es funktioniert in BusyBox-Umgebungen, in denen vollständiges logrotate nicht verfügbar ist. Wenn Sie auf einer richtigen Linux-Box sind (Ubuntu-Server, Debian, was auch immer), verwenden Sie einfach echtes logrotate mit einer Konfiguration in/etc/logrotate.d/cccam, die auf Ihren Protokollpfad mit wöchentlicher Rotation und Kompression zeigt.

Für die Live-Anzeige, ohne auf das Wachstum der Datei zu warten, telneten oder SSH in die Box und führen Sietail -f /media/usb/CCcam.log. Es gibt auch eine Weboberfläche — standardmäßig auf Port 16001 — die einen Protokoll-Tab hat, der die letzten Aktivitäten anzeigt, falls Sie sich nicht mit einem Terminal befassen möchten.

Dekodierung der Anatomie einer CCcam-Protokollzeile

Hier scheitern die meisten Anleitungen. Sie zeigen einen Screenshot eines Protokolls und sagen "siehe, es ist verbunden", ohne jemals zu erklären, was jedes Feld tatsächlich bedeutet. Lassen Sie uns das beheben. Hier ist eine repräsentative (anonymisierte) Zeile, die Sie aus einem CCcam-Protokoll sehen würden:

2026/07/17 21:14:03 (SHARE01) [FTA] ECM (0100:001234:2A3F) hop 1 - OK (312 ms)

Das aufschlüsseln Feld für Feld: Der Zeitstempel kommt zuerst, dann der Peer-Name oder Handle in Klammern (SHARE01 in diesem Fall — welcher Nickname für diese Verbindung festgelegt ist). Als nächstes ist ein Tag, der den Kartentyp oder die Anbietergruppe angibt. Dann haben Sie CAID:ident:SID — die CAID identifiziert das Verschlüsselungssystem (0100 ist Seca, 0500 ist Viaccess usw.), die ident schränkt den Anbieter-Schlüsselset ein, und die SID ist die Dienst-ID für den spezifischen Kanal, der angefordert wird.

Verbindungszeilen: verbunden, getrennt und Anmeldestatus

Getrennt vom ECM-Verkehr sehen Sie Zeilen wie:

2026/07/17 21:00:11 client SHARE01 verbunden

2026/07/17 21:45:02 client SHARE01 getrennt (Verbindung vom Peer geschlossen)

Diese zeigen Ihnen den Zustand der tatsächlichen TCP-Sitzung, unabhängig davon, ob das Dekodieren funktioniert. Ein Peer, der sich verbindet und stundenlang verbunden bleibt, ist gesund. Ein Peer, der sich verbindet, innerhalb von Sekunden abbricht und sich wiederholt verbindet, sagt Ihnen, dass etwas nicht stimmt, bevor Sie überhaupt die ECM-Daten ansehen.

Karten-/Share-Zeilen: Leser, Anbieter-ID und Hop-Zahl

Die Hop-Zahl ist eines der am meisten missverstandenen Felder im gesamten Protokoll. Hop 1 bedeutet, dass die Karte oder der Leser, der die Anfrage beantwortet, lokal zu diesem Peer ist — eine direkte physische Karte oder ein OSCam-Leser ohne Reshare dazwischen. Hop 2 bedeutet, dass dieser Peer es von jemand anderem erhalten hat, der die tatsächliche Karte hat. Hop 3, Hop 4 und darüber hinaus bedeuten, dass Sie mehrere Reshares tief in einer Kette sind, und jeder dieser Hops fügt Latenz und einen weiteren Fehlerpunkt hinzu.

ECM-Anforderungszeilen: VON Peer, ZU Leser und Dekodierungsergebnis

Richtung ist wichtig. Eine VON-Zeile bedeutet, dass jemand einen Kanal von Ihnen anfordert — Sie fungieren als Anbieter. Eine ZU-Zeile bedeutet, dass Sie derjenige sind, der anfordert, und Ihre Box fragt einen Leser (lokale Karte oder upstream Peer), um zu dekodieren. Wenn Sie nur VON-Zeilen und keine ZU-Zeilen für eine bestimmte CAID sehen, haben Sie überhaupt keine funktionierende Quelle für dieses Verschlüsselungssystem, sei es Share oder anders.

Zeitfelder: was der Millisekundenwert wirklich bedeutet

Die Zahl in Klammern — 312 ms in meinem Beispiel — ist die ECM-Dekodierungslatenz, die Zeit zwischen dem Versenden der Anfrage und dem Zurückkommen der Antwort. Für eine lokale Karte, die in Ihrem eigenen Leser sitzt, ist alles unter etwa 400 ms gesund. Für einen WAN-Peer, insbesondere einen, der ein paar Hops entfernt oder über eine langsamere Verbindung ist, sind höhere Zahlen normal und nicht automatisch ein Problem. Was zählt, ist die Konsistenz. Ein Peer, der bei stabilen 250 ms sitzt, ist in Ordnung. Ein Peer, der zwischen 200 ms und 3000 ms springt, ist derjenige, der Ihre Freezes verursacht.

Diagnose der häufigsten Probleme aus dem Protokoll

Sobald Sie die Felder verstehen, ist der wahre Wert der besten Praxis der CCcam-Protokollanalyse das Musterabgleich über die Zeit — nicht das Starren auf eine einzelne Zeile. Ein einzelner Timeout bedeutet nichts. Ein Muster von Timeouts bei derselben CAID vom selben Peer jeden Abend bedeutet alles.

Kanal-Freeze und intermittierende ECM-Timeouts

Wenn ein Kanal einfriert, aber Audio/Video ansonsten vor und nach dem Einfrieren gut spielt, durchsuchen Sie das Protokoll um diesen Zeitstempel nach der CAID und SID dieses Kanals. Suchen Sie nach einer Reihe von steigenden ECM-ms-Werten, gefolgt von einer Timeout-Zeile, dann einer frischen erfolgreichen Dekodierung, sobald ein neuer ECM-Zyklus beginnt. Dieses Muster — schleichende Latenz, dann eine Lücke, dann Wiederherstellung — deutet eindeutig auf einen überlasteten oder überfüllten Peer hin, nicht auf Ihre eigene Hardware.

Peers, die sich verbinden und dann abfallen (Anmelde-Schleifen)

Wiederholte Verbindungs-/Trennzyklen vom selben Peer, insbesondere innerhalb von Sekunden, führen fast immer auf eines von drei Dingen zurück: ein Benutzername/Passwort-Mismatch (überprüfen Sie die F:-Zeilen in Ihrer CCcam.cfg gegen das, was der Peer erwartet), ein falscher Port auf einer Seite oder eine MAXHOP-/Versionsinkompatibilität, bei der der Client des Peers Ihre Verbindung ablehnt, weil Ihre MAXHOP-Einstellung nicht mit dem übereinstimmt, was sie erwarten. Überprüfen Sie die genaue Trennungsgrundzeichenfolge im Protokoll — "falsches Passwort" und "Verbindung vom Peer geschlossen" weisen auf sehr unterschiedliche Lösungen hin.

Hohe Hop-Zahlen und Reshare-Ketten, die das Dekodieren verlangsamen

Wenn Sie konsequent Hop 3 oder Hop 4 für Kanäle sehen, die früher schnell dekodiert wurden, hat sich etwas upstream um ihre Reshare-Kette umstrukturiert, und Sie sind jetzt weiter von der tatsächlichen Karte entfernt. Überprüfen Sie Ihre RESHARE- und MAXHOP-Werte in CCcam.cfg — das zu aggressive Senken von MAXHOP kann Sie vollständig von funktionierenden Shares abschneiden, während ein zu hoher Wert langsame, unzuverlässige lange Ketten durchlässt. Es gibt hier keine universell richtige Zahl; es hängt davon ab, was Ihre Peers tatsächlich anbieten.

Tote oder abgelehnte Karten vs. tatsächlich fehlende Berechtigungen

Eine "Karte abgelehnt" oder "Berechtigung abgelaufen"-Zeile ist anders als ein Timeout — es bedeutet, dass die Karte geantwortet hat und nein gesagt hat, normalerweise weil das Abonnement dahinter abgelaufen ist oder das spezifische Kanalpaket nicht enthalten ist. Das ist kein Netzwerkproblem oder ein Konfigurationsproblem auf Ihrer Seite. Kein Maß an Wiederholungen oder Anpassungen der Hop-Einstellungen behebt eine abgelaufene Berechtigung upstream.

Werkzeuge und Methoden zur Analyse von CCcam-Protokollen im großen Maßstab

Zeilenweise Lesen bringt Sie nur so weit, wenn Sie ein Dutzend Peers und Hunderte von ECM-Anfragen pro Stunde haben. Hier sparen ein paar grep- und awk-Einzeiler Ihnen wirklich Zeit, und ehrlich gesagt ist es der Teil, den die meisten Anleitungen ganz überspringen zugunsten eines einzigen annotierten Screenshots.

grep, awk und sort Einzeiler für die Triage

Um jedes Timeout-Ereignis zu erfassen:

grep -i "timeout" /media/usb/CCcam.log

Um jedes "nicht dekodiert"-Ereignis zu finden, das ein ganz anderer Fehlermodus ist (mehr dazu weiter unten):

grep -i "not decoded" /media/usb/CCcam.log

Zählen von ECM OK vs. Timeout-Verhältnissen pro Peer

Das ist nützlicher. Um zu bewerten, welche Peers die meisten Timeouts erzeugen:

grep "timeout" CCcam.log | awk '{print $4}' | sort | uniq -c | sort -rn

Passen Sie die Feldnummer ($4) basierend darauf an, wo der Peer-Name in Ihrem tatsächlichen Protokollformat sitzt — es variiert ein wenig zwischen den CCcam-Versionen. Um eine durchschnittliche ECM-Zeit pro CAID zu erhalten:

grep "OK" CCcam.log | awk -F'[()]' '{print $2, $4}' | awk '{sum[$1]+=$3; count[$1]++} END {for (c in sum) print c, sum[c]/count[c]"ms"}'

Führen Sie das über ein paar Stunden Protokolle aus, und Sie werden sofort sehen, welche CAID im Durchschnitt 250 ms und welche 1800 ms hat. Das ist Ihre Problem-CAID, und jetzt wissen Sie, wo Sie sich konzentrieren müssen, anstatt zu raten.

Live-Verkehr beobachten vs. Nachanalyse

Um einen intermittierenden Freeze in Echtzeit zu erfassen, führen Sie austail -f CCcam.log | grep -i "yourCAID" während Sie den Kanal beobachten, der einfriert. Sie sehen den genauen Moment, in dem der Timeout in Echtzeit auftritt, was viel nützlicher ist, als es später aus einer statischen Datei zu rekonstruieren. Um langsamere Trends zu erkennen — ein Peer, der den Großteil des Tages in Ordnung ist, aber zur Hauptsendezeit Probleme hat — benötigen Sie den aggregierten Nachanalyseansatz mit awk-Durchschnittswerten über ein rotiertes Protokoll, das mehrere Stunden oder einen ganzen Tag umfasst.

Vorteil von OSCam: readerinfo, Statusseite und sauberere Protokolle

Es ist erwähnenswert: Viele Setups verwenden OSCam als tatsächlichen Reader/Karten-Handler hinter einer CCcam-Protokoll-Peering-Schicht, da die Web-Statusseite von OSCam und die Ausgabe von readerinfo strukturierter sind als rohe CCcam-Textprotokolle. Wenn Ihre Box eine gemischte Umgebung ist, sehen Sie manchmal sowohl CCcam-Format- als auch OSCam-Formatzeilen im selben Protokolldatei vermischt, und die Feldreihenfolge stimmt nicht überein. Gehen Sie nicht davon aus, dass jede Zeile dem oben beschriebenen Format folgt — überprüfen Sie, welcher Daemon sie tatsächlich geschrieben hat, bevor Sie nach Spaltenposition filtern.

Worauf man achten sollte, wenn man einen Peer aus Protokollen auswählt oder bewertet

Es geht hier nicht darum, Ihnen zu sagen, wo Sie einen Share bekommen — darum geht es nicht. Es geht darum, die Protokolle einer Verbindung zu lesen, die Sie bereits haben, und objektiv zu entscheiden, ob sie tatsächlich gut oder nur vertraut ist.

Uptime und Wiederverbindungsfrequenz als Qualitätsindikatoren

Durchsuchen Sie das Verbindungsprotokoll für einen bestimmten Peer über eine Woche. Ein Peer, der einmal verbindet und verbunden bleibt, abgesehen von geplanten Neustarts, ist eine stabile Infrastruktur. Ein Peer, der sich alle paar Stunden wieder verbindet, läuft entweder auf instabiler Hardware, hat eine unzuverlässige Verbindung oder startet seinen Dienst nach einem Zeitplan, den Sie nicht kontrollieren. Keines dieser Probleme ist für sich genommen disqualifizierend, aber häufige ungeplante Abbrüche während der Hauptsendezeiten sind das Muster, auf das man achten sollte.

Konstante niedrige ECM-Zeiten vs. spiky Latenz

Die durchschnittliche ECM-Zeit ist weniger wichtig als die Varianz. Ein Peer, der konstant bei 600 ms sitzt, ist in der Praxis nützlicher als einer, der zwischen 150 ms und 4000 ms schwankt, obwohl die beste Zahl des zweiten besser aussieht. Einfrieren kommt von den Spitzen, nicht von der Basislinie. Genau deshalb ist der oben beschriebene awk-Durchschnittsansatz wichtiger als das bloße Betrachten einer Handvoll Zeilen — die Varianz zeigt sich nur über eine echte Stichprobengröße.

Hop-Zahl und ob ein Share eine echte Karte oder ein Reshare ist

Wenn Sie die Hop-Zahl für eine bestimmte CAID aus Ihren Protokollen bestimmen können, sagt Hop 1 Ihnen, dass es von einer tatsächlichen physischen Karte oder einem direkten bezahlten Feed kommt. Alles ab Hop 3 oder tiefer bedeutet, dass Sie sich auf das Reshare eines Reshares verlassen, und jeder Link in dieser Kette ist ein potenzieller Fehlerpunkt, der außerhalb der direkten Kontrolle von jemandem liegt. Keines davon ist an sich falsch zu verwenden, aber wissen Sie, auf welches Sie sich tatsächlich verlassen, bevor Sie Stunden mit dem Debuggen verbringen, was möglicherweise nur eine inhärente Einschränkung einer langen Kette ist.

Einige Randfälle, die Sie im Hinterkopf behalten sollten, während Sie all dies tun: Überprüfen Sie die Uhr Ihrer Box. Zeitzonendrift oder eine Uhr, die sich nach einem Stromausfall zurückgesetzt hat, wird Ihre Fähigkeit beeinträchtigen, Protokollzeitstempel mit dem Zeitpunkt zu korrelieren, an dem Sie tatsächlich das Einfrieren gesehen haben — verifizieren Sie mitdate auf der Box, bevor Sie der Zeitstempelkorrelation vertrauen. Außerdem garantiert das Decodieren, das im Protokoll "OK" anzeigt, kein sauberes Bild — wenn ECM-Zeilen perfekt gesund aussehen, der Kanal aber trotzdem einfriert oder stottert, ist das sehr wahrscheinlich ein Tuner/Signalproblem oder ein Hardware-Entschlüsselungsproblem, kein Sharing-Problem. Und wenn Sie mehrere SIDs auf einer CAID haben, vertrauen Sie nicht auf eine aggregierte Statistik — einige Kanäle unter dieser CAID können ausfallen, während andere problemlos durchkommen, und durchschnittliche Zahlen werden das völlig verbergen. Filtern Sie pro SID, wenn mit einem bestimmten Kanal etwas nicht stimmt.

Fassen Sie all dies zusammen, und Sie haben das, was ich als Best Practice für die Analyse von cccam-Protokollen bezeichnen würde: ausführliches Protokollieren, das von Ihrem Flash-Speicher geleitet wird, ein echtes Verständnis dafür, was jedes Feld in einer Zeile bedeutet, eine Zuordnung von Symptomen zu Protokollsignaturen für die häufigsten Fehler und eine Handvoll von Kommandozeilen-Einzeilern, um rohen Lärm in eine tatsächliche rangierte Liste von Problemen zu verwandeln. Das ist der Unterschied zwischen Raten und tatsächlich etwas Reparieren.