CCcam Fehlersuche Überprüfung: Beheben von Freezing& FBL-Fehlern

Wenn Sie ein CCcam- oder OScam-Setup betreiben und das Bild ständig einfriert, wird Ihnen diese CCcam Fehlersuche Überprüfung viel Zeit sparen. Freezing ist kein einzelnes Problem — es ist ein Symptom mit etwa fünf verschiedenen Ursachen, und die meisten Menschen verbringen Stunden damit, ihre Box neu zu starten, anstatt die eine Protokollzeile zu lesen, die ihnen genau gesagt hätte, was falsch ist. Ich habe jahrelang Share-Server betrieben, und der diagnostische Prozess unten ist derselbe, den ich jedes Mal verwende, wenn eine Linie ausfällt.

Bevor Sie also CCcam.cfg oder oscam.server berühren, lassen Sie uns festlegen, was das Protokoll Ihnen tatsächlich sagt. Das ist der Teil, den jede andere CCcam Fehlersuche Überprüfung überspringt.

Wie man ein CCcam-Freeze liest, bevor man die Konfiguration berührt

Freezing ist keine Diagnose. Es ist ein Symptom. Die Box ist eingefroren, weil etwas in der ECM-Kette zu lange gedauert hat oder ganz ausgefallen ist — aber "Freezing" allein sagt Ihnen nichts darüber, ob der Fehler in Ihrer Konfiguration, Ihrem Netzwerk, der Karte Ihres Partners oder einer toten Linie liegt. Sie müssen zuerst das Protokoll ansehen.

Freeze vs. schwarzer Bildschirm vs. verschlüsseltes Bild — drei verschiedene Fehler

Diese werden ständig zusammengefasst und sollten es nicht sein. Ein Freeze bedeutet, dass eine ECM (Entitlement Control Message) angefordert wurde und schließlich ankam, aber zu spät — der Decoder hatte kein gültiges Steuerwort mehr, bevor das neue eintraf, also hält er das letzte Bild. Ein schwarzer Bildschirm bedeutet normalerweise, dass überhaupt keine ECM-Antwort zurückkam oder dass die angeforderte CAID von nichts auf Ihrer Kartenliste bedient wird. Ein verschlüsseltes Bild — sichtbares Rauschen, kein eingefrorenes Bild — bedeutet normalerweise, dass Sie ein DCW (Steuerwort) zurückbekommen haben, aber es ist das falsche, was auf eine CAID/Anbieter-Mismatch oder einen beschädigten Schlüssel hinweist.

Wenn Sie diese Unterscheidung falsch machen, verbringen Sie ein Wochenende damit, die Hop-Limits anzupassen, während das eigentliche Problem Ihr LNB-Kabel ist.

Aktivieren des ausführlichen Protokollierens: debug 4 und der CCcam-Protokollpfad

Ihre CCcam-Konfiguration befindet sich unter/etc/CCcam.cfg (oder/usr/keys/CCcam.cfg auf einigen enigma2-Images). Um nützliche Diagnosedaten zu erhalten, setzen Sie:

DEBUG : 4

Debug-Stufe 4 gibt Ihnen vollständige ECM-Anforderungs-/Antwortprotokollierung, nicht nur Verbindungsereignisse. Ohne sie sehen Sie Peer-Verbindungs-/Trennungsnachrichten, aber nichts über die tatsächliche Schlüsselübergabe — was für die Diagnose von Freezing nutzlos ist.

Bei OScam befindet sich das Äquivalent unter/etc/oscam/oscam.conf im[global] Block:

logfile = /var/log/oscam.log

Wenn Sie das Webinterface (normalerweise auf Port 8888 oder was auch immer Sie unter[webif] eingestellt haben) betreiben, gibt Ihnen die Leserstatusseite die gleichen ECM-Zeitdaten in einer viel lesbareren Tabelle — ich überprüfe das, bevor ich jemals eine rohe Protokolldatei ansehe.

ECM-Antwortzeiten im Protokoll lesen (wie 'gut' aussieht)

Eine gesunde CCcam-Protokollzeile sieht etwa so aus:

[03:14:22] ECM (0100:000000) von (CCcam) Client PeerName, cw: 142 ms

Diese 142 ms sind Ihre ECM-Antwortzeit — die Lücke zwischen der Anfrage und dem zurückkommenden Steuerwort. Alles unter etwa 250-300 ms ist angenehm. Zwischen 300-800 ms werden Sie gelegentliche Mikro-Ruckler bei Kanälen mit kurzen Krypto-Perioden sehen. Über 800 ms, konstant, und Sie werden sichtbares Freezing sehen — der Decoder hat einfach kein gültiges Schlüsselwort mehr, bevor das nächste eintrifft. Wenn die Krypto-Periode eines Kanals 8-10 Sekunden beträgt und Ihre ECM-Zeit darüber hinausgeht, erhalten Sie bei jedem einzelnen Zyklus ein hartes Freezing, wie ein Uhrwerk.

Dies ist die nützlichste Fähigkeit in jeder CCcam Fehlersuche Überprüfung: Korrelieren Sie den Freeze-Zeitstempel auf Ihrem Fernseher mit der ECM-Zeile zur gleichen Sekunde im Protokoll. Neun von zehn Mal sagt Ihnen der ms-Wert alles.

Mapping des Freezes zu einer CAID/Anbieter-ID

Jede ECM-Zeile enthält ein CAID:providerID-Paar — im obigen Beispiel,0100:000000. Notieren Sie sich, welche CAID/Anbieter-Kombinationen einfrieren und welche nicht. Wenn es immer dieselbe CAID ist (sagen wir, 0100 für Cryptoworks oder 0500 für Viaccess), sagt Ihnen das, dass das Problem spezifisch für den Peer oder die lokale Karte ist, die diese CAID bedient — nicht für Ihr gesamtes Setup. Das ist der Unterschied zwischen "meine Linie ist tot" und "eine spezifische Karte hinter meiner Linie ist überlastet", und es ändert, was Sie reparieren.

Die häufigsten Ursachen (nach Häufigkeit geordnet)

In der Reihenfolge, wie oft ich diese tatsächlich in der Wildnis sehe, hier ist, was deinen Feed stört.

Tot oder gedrosselt C-Linien und wie FBL (Freeze Box Loop) entsteht

Das ist die Hauptursache, bei weitem. Eine C-Linie in deiner CCcam.cfg:

C: 185.xx.xx.xx 12000 myuser mypass

...kann auf TCP-Ebene "aktiv" sein (der Socket verbindet sich gut), während die Karte dahinter völlig überlastet ist oder der Peer dein Konto gedrosselt hat. Deine Box fordert ein ECM an, erhält nicht rechtzeitig ein gültiges DCW, fordert erneut an, erhält immer noch keines und fordert erneut an. Das ist FBL — Freeze Box Loop — und es sieht von außen identisch zu einer toten Linie aus, außer dass die Verbindung nie tatsächlich abbricht. Überprüfe das Protokoll: Wenn du wiederholte ECM-Anfragen für dieselbe CAID ohne entsprechende "cw:"-Antwortzeile siehst oder Antwortzeiten, die ständig steigen, ist die Karte dieses Peers entweder tot, überlastet oder hat stillschweigend aufgehört, diese Provider-ID zu bedienen.

Hop- und Reshare-Limits, die stillschweigend die Sichtbarkeit deiner Karte töten

CCcam.cfg ermöglicht es dir, die Anzahl der Hops zu begrenzen, durch die eine Karte reshared werden kann:

F: freundname 12000 benutzer pass 1 0 { 1,2,3 }

Die Zahlen in den geschweiften Klammern sind die CAID-Reshare-Hop-Limits. Eine Karte bei Hop 0 ist lokal — sie befindet sich physisch in deiner Box. Hop 1 bedeutet einen Peer entfernt. Bei Hop 3 oder mehr wurde dieser Schlüssel durch drei separate Server weitergeleitet, bevor er dich erreicht, und jeder Hop fügt Latenz und einen neuen Fehlerpunkt hinzu. Ich habe gesehen, dass Hop-4-Karten technisch "funktionieren", aber mit ECM-Zeiten über 1200 ms — völlig nutzlos für alles mit einer schnellen Kryptoperiode.

CAID/Provider-Mismatch und fehlendes ecm.info

Manchmal denkt der Reader, dass er CAID 0500 bedient, aber die tatsächliche Provider-ID darunter hat sich verschoben, oder deine CCcam.providers-Datei listet ein Ident auf, das nicht mehr mit dem übereinstimmt, was die Karte zurückgibt. In OScam, überprüfeecm.info im Protokollverzeichnis — es protokolliert jede ECM-Anfrage mit der CAID, der Provider-ID und ob eine gültige Antwort zurückkam. Wenn du ständig "nicht gefunden" gegen eine CAID siehst, von der du dachtest, dass sie abgedeckt ist, ist deine Provider-Datei veraltet.

Netzwerk-Jitter, MTU und die Router-NAT-Timeout-Falle

CCcam verwendet standardmäßig TCP-Port 12000. OScam führt häufig sein eigenes Protokoll auf 8888-ähnlichen Bereichen für webif aus, wobei newcamd typischerweise auf 988x-Ports läuft, wenn du Protokolle überbrückst. Wenn die NAT-Tabelle deines Routers eine inaktive TCP-Verbindung (häufiger Standard liegt irgendwo zwischen 300-600 Sekunden bei Consumer-Routern) zeitlich begrenzt und CCcam nicht häufig genug Keep-Alives sendet, bricht die Linie stillschweigend ab — deine Box denkt, sie ist noch verbunden, der Router nicht, und ECMs gehen nirgendwo hin, bis eine Wiederverbindung erfolgt. Bei PPPoE/ADSL-Leitungen können speziell MTU-Mismatches (PPPoE-Overhead frisst 8 Bytes, daher benötigst du oft 1492 statt 1500) Pakete fragmentieren und ECM-Daten intermittierend beschädigen — dies zeigt sich als sporadisches Einfrieren, das überhaupt nichts mit deinem Provider zu tun hat.

Überlastete Karte: ECM-Warteschdepth und 'sid'-Zuweisung

Wenn du deine eigene Karte an mehrere nachgelagerte Benutzer teilst, kann eine physische Karte nur so viele gleichzeitige ECM-Anfragen dekodieren, bevor die Warteschlange sich staut. Achte darauf, wie viele aktive SIDs (Service/Stream-IDs) einen einzelnen Reader in deinem Protokoll oder auf der webif-Statusseite erreichen. Eine einzelne überlastete Karte, die 15 gleichzeitige Kanäle an verschiedene Benutzer bedient, zeigt steigende ECM-Zeiten für alle — das ist oft der Grund für das Einfrieren, das nur zu bestimmten Tageszeiten auftritt, wie zur Hauptsendezeit am Abend, wenn alle gleichzeitig zuschauen.

Behebung: Konfigurationsänderungen, die das Einfrieren tatsächlich stoppen

Sobald du weißt, was das Protokoll zeigt, hier ist, was tatsächlich etwas bewirkt.

Anpassung von CCcam.cfg: CACHE EX, GHOST CARDS OFF und empfohlene Timeouts

Einige Direktiven in CCcam.cfg helfen wirklich:

CACHE EX : 1

CACHE EX aktiviert das ECM-Caching, sodass wiederholte Anfragen nach demselben Schlüssel innerhalb eines kurzen Zeitfensters den Peer nicht erneut belasten.GHOST CARDS OFF verhindert, dass CCcam Karten bewirbt, die es durch einen Peer sehen kann, die aber tatsächlich nicht zuverlässig sind — Geisterkarten sind ein großer Beitrag zu FBL, weil deine Box denkt, sie hat einen schnellen Weg zu einer CAID, die tatsächlich drei Hops tief und langsam ist.MINIMUM CW : 1 stellt einfach sicher, dass ein Kontrollwort nicht leer sein darf, bevor es akzeptiert wird, und filtert fehlerhafte Antworten von einem unzuverlässigen Peer heraus.

OScam-Äquivalente: [cache] und dvbapi-Einstellungen, die wichtig sind

Der echte Vorteil von OScam hier ist der Lastenausgleich. In oscam.conf:

[global]

lb_mode = 1 ist der "schnellster Reader"-Modus — OScam verfolgt aktiv die Antwortzeiten pro CAID/Provider über jeden Reader, den du hast, und leitet Anfragen an denjenigen weiter, der gerade am schnellsten ist, anstatt blind das erste aufgelistete zu belasten.lb_retrylimit (in ms) sagt ihm, dass er bei einem langsamen Reader aufgeben und auf den nächstbesten umschalten soll, anstatt dort zu sitzen und zu warten. Diese eine Einstellung behebt mehr Einfrieren als jede CCcam.cfg-Anpassung, die ich je vorgenommen habe, weil CCcam kein Äquivalent hat — es fragt einfach weiterhin denselben Peer, unabhängig davon, wie langsam er historisch war.

Rate-Limiting eines schlechten Peers anstatt ihn abzulehnen

Wenn ein Peer eine CAID bedient, die niemand sonst hat, aber langsam ist, lehne ihn nicht einfach ab — drossle deine Abhängigkeit von ihm. In OScam, senke seine Priorität unter[reader] mit demlb_weight Parameter, damit der Lastenausgleich nur darauf zurückgreift, wenn nichts Schnelleres verfügbar ist, anstatt es als gleichwertige Option zu behandeln.

Eine gefrorene Linie von CCcam auf das OScam-Protokoll migrieren

Dies ist der sauberste Weg, um zu isolieren, ob der Fehler im Protokoll oder im Peer selbst liegt. Fügen Sie einen cccam-Typ-Leser in oscam.server hinzu, der auf denselben Host und dieselben Anmeldeinformationen zeigt:

 [reader]

Wenn die gleiche physische Linie jetzt unter dem Lastenausgleich von OScam besser funktioniert als unter rohem CCcam, war der Fehler nie der Peer — es war CCcam, das einen schlechten Leser ohne Backoff-Logik erneut versucht hat. Das ist ein wirklich nützlicher Datenpunkt in jeder CCcam-Fehlerbehebung, da es Ihnen sagt, ob Sie Ihren Protokollstapel reparieren oder eine andere Kartenquelle ganz finden sollten.

Überprüfung der Lösung mit einem kontrollierten Kanal-Zap-Test

Vertrauen Sie nicht auf den Eindruck „fühlt sich besser an“. Wählen Sie zwei Kanäle, die bekannt dafür sind, viel ECM-Verkehr zu haben (schnelle Krypto-Periode, hohe Zuschauerzahl), und zapen Sie 20 Mal hintereinander zwischen ihnen, während Sie die Protokolle oder die ECM-Zeitspalte im Webinterface beobachten. Notieren Sie vor Ihrer Lösung die durchschnittliche ms und die Anzahl der Aussetzer. Wiederholen Sie danach denselben Test. Wenn die durchschnittliche ECM-Zeit gesunken ist und die Anzahl der Aussetzer bei 20 Zaps null erreicht hat, hat die Lösung gehalten. Wenn sie auf einem der Kanäle immer noch über 800 ms steigt, haben Sie es noch nicht gelöst — gehen Sie zurück zum Protokoll.

Wie man beurteilt, ob eine Linie oder ein Anbieter es wert ist, behalten zu werden

Teil jeder echten CCcam-Fehlerbehebung ist die Entscheidung, ob man weiter gegen eine schlechte Linie kämpfen oder sie loslassen soll. So beurteilen Sie das objektiv, anstatt auf Ihr Bauchgefühl zu hören.

Objektive Metriken: Uptime %, durchschnittliche ECM-Zeit, Aussetzfrequenz

Setzen Sie eine Grenze und halten Sie jede Linie daran. Die nachhaltige ECM-Antwortzeit sollte im Durchschnitt unter etwa 400 ms für die CAIDs liegen, die Sie tatsächlich ansehen. Die Uptime — was bedeutet, dass die Verbindung bestehen bleibt und tatsächlich gültige DCWs bereitstellt, nicht nur TCP-verbunden — sollte irgendwo über 99 % gemessen über eine Woche liegen, nicht nur an einem einzigen guten Abend. Aussetzerereignisse auf Ihren stärksten Kanälen sollten höchstens ein paar pro Tag sein, nicht pro Stunde. Wenn eine Linie diese Zahlen über einen längeren Testzeitraum nicht erreichen kann, ist es kein Konfigurationsproblem mehr — es ist die Linie.

Grüne Flaggen in einer Peer-Einrichtung (lokale Karten, niedriger Hop, stabile IP)

Eine vertrauenswürdige Einrichtung zeigt Karten bei Hop 0 oder 1 — was bedeutet, dass sie wirklich lokal oder einen Hop entfernt ist, nicht durch vier Schichten von Reshare weiterverkauft. Die Endpunkt-IP ist über Wochen stabil, nicht rotierend. Die bereitgestellten CAIDs sind dokumentiert und stimmen mit dem überein, was tatsächlich in Ihrem ecm.info-Protokoll angezeigt wird. Dies sind die technischen Fingerabdrücke von jemandem, der ein echtes, gut gewartetes Kartensetup betreibt, und nicht von einer Reshare-Farm.

Rote Flaggen, die zukünftige Aussetzer vorhersagen

Achten Sie auf IPs, die sich alle paar Tage ohne Vorankündigung ändern, auf Kartenlisten, die für das, was eine kleine persönliche oder kleine Unternehmensstruktur sein sollte, unrealistisch groß aussehen, und auf Hop-Werte, die nicht übereinstimmen — eine Karte, die Hop 1 beansprucht, sich aber verhält, als wäre sie vier Hops tief in Ihrer ECM-Zeitmessung. Jede dieser Flaggen sagt Aussetzer voraus, bevor sie überhaupt beginnen, da sie alle auf Instabilität upstream hinweisen, die Sie nicht einsehen und über die Sie keine Kontrolle haben.

Wie eine legitime Anbieterbeziehung technisch aussieht

Um klarzustellen, geht es darum, Ihre eigenen Abonnementkarten und die legitime Interoperabilität zwischen Ihrer eigenen Hardware zu testen — das Teilen zwischen einer Karte, die Sie besitzen, und einer zweiten Box in Ihrem eigenen Zuhause oder die Überprüfung einer Geschäftsbeziehung mit dokumentiertem, lizenziertem Kartenzugang. Eine legitime technische Beziehung gibt Ihnen einen einzigen stabilen Endpunkt, eine dokumentierte CAID/Anbieter-Liste, die Sie mit Ihrer eigenen ecm.info-Ausgabe abgleichen können, und ehrliche Hop-Berichterstattung, die Sie unabhängig durch Ihre eigenen Protokolle bestätigen können. Wenn davon nichts von Ihrer Seite verifiziert werden kann, ist das die tatsächliche rote Flagge — nicht die Aussetzer selbst.

Was nicht funktioniert (Hören Sie auf, Zeit mit diesen zu verschwenden)

Das sind die Dinge, die die Leute zuerst ausprobieren, und sie beheben fast nie etwas, weil sie nicht das angehen, was das Protokoll tatsächlich zeigt.

Die Box in einer Schleife neu starten, anstatt das Protokoll zu lesen

Ein Neustart löscht aktive Verbindungen und setzt Timer zurück, sodass die Dinge manchmal für zehn Minuten besser aussehen. Das ist keine Lösung — es ist ein Zufall des Timings. Die zugrunde liegende ECM-Latenz oder der tote Peer ist immer noch da; Sie haben nur den FBL-Zyklus vorübergehend zurückgesetzt. Wenn Sie neu starten und das Protokoll nicht überprüfen, sind Sie in einer Stunde wieder hier mit dem genau gleichen Problem und null weiteren Informationen als zu Beginn.

Blind die Hop-/Reshare-Grenzen erhöhen

Ihre Hop-Grenze von 2 auf 4 zu erhöhen, macht mehr Karten sichtbar, sicher — aber jede dieser neu sichtbaren Karten ist definitionsgemäß weiter entfernt und langsamer. Das ist das Gegenteil einer Lösung. Es tauscht „keine Karte verfügbar“ gegen „eine langsame Karte verfügbar“ und langsame Karten sind genau das, was die Aussetzer verursacht, die Sie zu lösen versuchen. Wenn Sie den Hop-Grenzen nachjagen, überprüfen Sie zuerst den ECM-ms-Wert — eine Hop-1-Karte bei 900 ms ist schlechter als eine Hop-2-Karte bei 200 ms.

Copy-pasted CCcam.cfg 'Fixes' aus Foren

Der Konfigurationsdump einer anderen Person enthält deren C-Linien, deren CAIDs, deren Hop-Einstellungen, die auf deren Peer-Beziehungen abgestimmt sind — nichts davon passt zu Ihrem Setup. Das Einfügen einer fremden CCcam.cfg über Ihre eigene ersetzt funktionierende Linien durch tote und irrelevante CAIDs, die Sie nicht benötigen, während es nichts an dem tatsächlichen Peer- oder Netzwerkproblem tut, das Ihre Aussetzer verursacht.

Die Schüssel/LNB beschuldigen, wenn das Protokoll ECM-Latenz zeigt

Dies ist die größte Fehldiagnose, die ich sehe. Aussetzer bei schlechtem Wetter oder Aussetzer, die anscheinend mit Regen korrelieren, können tatsächlich ein Signalproblem sein — ein echter SNR-Abfall von der Schüssel oder dem LNB. Aber das zeigt sich als ein verschlüsseltes oder völlig verlorenes Bild mit Signalstärke-/Qualitätswerten, die in Ihrem Tuner-Status sinken, nicht als saubere Freeze-and-Resume-Zyklen mit normalen Signalpegeln. Wenn Ihr Protokoll zeigt, dass ECM-Anfragen ausgehen und spät zurückkommen — ein klarer ms-Wert, der über 800 steigt — ist Ihre Schüssel in Ordnung. Positionieren Sie ein LNB nicht wegen eines Timing-Problems beim Kartenteilen neu.