NCam "Kann nicht dekodieren" Fehler: Ursachen& Lösungen

Wenn Sie nach einer Lösung für den ncam kann nicht dekodieren Fehler suchen, ist das erste, was Sie verstehen sollten, dass dieser Fehler nicht ein Problem ist — es sind mindestens vier verschiedene Probleme, die dieselbe Protokollnachricht erzeugen. Das Neustarten von NCam und das erneute Eingeben Ihrer Zeile ist der Rat, den Sie in den meisten Foren finden. Es behebt fast nichts. Dieser Leitfaden arbeitet die tatsächliche Ursache durch, indem er den ECM-Lebenszyklus vom PMT-Parsing bis zur Anwendung des Steuerworts verfolgt, sodass Sie genau isolieren können, wo Ihre Einrichtung fehlschlägt.

Was "Kann nicht dekodieren" tatsächlich in NCam bedeutet

NCam ist ein OSCam-Fork. Das Konfigurationsverzeichnis ist typischerweise/etc/tuxbox/config/ und die Dateien folgen der Benennung oscam.* —ncam.conf,ncam.server,ncam.dvbapi,ncam.user. Wenn Sie an OSCam gewöhnt sind, ist die Struktur identisch. Das Verhalten ist ebenfalls identisch, einschließlich der Art und Weise, wie es Dekodierfehler protokolliert.

Die Nachricht "kann nicht dekodieren" bedeutet, dass NCam entweder ein Steuerwort (CW) von einem Leser erhalten hat, das jedoch vom Entschlüsseler abgelehnt wurde, oder dass kein CW rechtzeitig angekommen ist. Der Stream bleibt verschlüsselt. Die Box zeigt einen schwarzen Bildschirm. Dies unterscheidet sich von drei anderen Fehlerzuständen, die Sie in Protokollen sehen werden:

• keine Quelle verfügbar — kein Leser hat die CAID überhaupt zugeordnet
• sid nicht gefunden — die Dienst-ID ist nicht in der Kanalliste eines Lesers
• kein passender Leser — CAID existiert, aber der Anbieter-/Gruppenfilter hat den Leser blockiert

"Kann nicht dekodieren" impliziert speziell, dass die ECM-Pipeline weitergegangen ist — ein Leser wurde kontaktiert — aber der letzte Dekodierschritt fehlgeschlagen ist. Das ist die Unterscheidung, die zählt.

Die Protokollzeile und wo sie erscheint

Öffnen Sie das NCam-Webinterface unterhttp://your-box-ip:8888 (oder was auch immerhttpport Sie in[webif] eingestellt haben) und gehen Sie zu Live Log. Sie suchen nach Zeilen, die mitdvbapi gekennzeichnet sind und Einträge, dieecm hash,kein cw, oder das explizitekann nicht dekodiert werden Zeichen. Der Pfad zur Protokolldatei ist festgelegt in[global] vonncam.conf — typischerweiselogfile = /var/log/ncam.log oder/tmp/ncam.log auf eingebetteten Systemen.

Dekodierungsfehler vs. keine ECM-Anfrage vs. ECM abgelehnt

Hier läuft die Fehlersuche meistens schief. "Keine ECM-Anfrage" bedeutet, dass die dvbapi-Schicht nie nach einem CW gefragt hat — das ist einpmt_mode oder Socket-Problem. "ECM abgelehnt" bedeutet, dass der Server mit einem Fehler geantwortet hat. "Kann nicht dekodieren" bedeutet, dass ein CW angekommen ist, aber nicht funktioniert hat. Diese drei Ergebnisse benötigen völlig unterschiedliche Lösungen, und sie sehen oberflächlich ähnlich im Protokoll aus, wenn man nicht genau liest.

Wie sich NCam von OSCam dvbapi-Namensgebung unterscheidet

Kaum, ehrlich gesagt. Diencam.dvbapi Datei verwendet die gleiche P:/I:/D:-Syntax wieoscam.dvbapi. Einige Builds platzieren Konfigurationen in/usr/keys/ anstelle von/etc/tuxbox/config/ — überprüfen Sie Ihr spezifisches Image. Der Webif-Port ist in den meisten NCam-Bauten standardmäßig auf 8888 eingestellt, im Gegensatz zu OSCams 8888, also keine Änderung dort.

Lesen Sie die Protokolle, bevor Sie etwas ändern

Im Ernst. Jede Konfigurationsänderung, die Sie blind vornehmen, fügt eine neue Variable hinzu. Bevor Sie etwas berühren, erhalten Sie eine saubere Aufzeichnung dessen, was NCam tatsächlich mit einem bestimmten Kanal macht.

Aktivieren Sie vollständiges Logging (debug 255) sicher

Inncam.conf unter[global], setzen Siedebug = 255 vorübergehend. Dies protokolliert alles: PMT-Parsing, ECM-PID-Auswahl, Reader-Zuordnung, CW-Timing und Entschlüsselungsaufrufe. Auf einem Pi oder schwachen STB wird dies das Protokoll überfluten und kann tatsächlich die Dinge so weit verlangsamen, dass späte CWs verursacht werden — was ein Symptom erzeugt, das wie das Problem aussieht, das Sie zu diagnostizieren versuchen. Erfassen Sie 60 Sekunden Protokoll für einen Kanal, setzen Sie danndebug = 0 wieder. Lassen Sie es nicht laufen.

Sie können auch die Ausführlichkeit pro Reader im Webif umschalten, ohne die Datei zu bearbeiten, was während des Live-Debuggings sauberer ist.

Verfolgen des ECM-Lebenszyklus: Anfrage, gefunden, cw, dekodieren

Eine erfolgreiche Dekodierungsaufzeichnung sieht in folgender Reihenfolge so aus: dvbapi analysiert die PMT und findet ECM-PIDs, NCam wählt eine PID aus und sendet eine ECM-Anfrage an einen passenden Reader, der Reader gibt ein CW zurück, NCam übergibt das CW an den Entschlüsseler, der Entschlüsseler wendet es an und der Stream wird entschlüsselt. "Kann nicht dekodieren" bricht an diesem letzten Schritt ab — entweder kam das CW nie, kam zu spät oder kam falsch.

Suchen Sie nach der Zeile, die die ECM-Zeit in Millisekunden anzeigt. Etwas wieecm time: 340ms ist in Ordnung. 1800ms auf einem Kanal mit einer 1,8-sekündigen Krypto-Periode bedeutet, dass das CW genau am Rand ankommt und möglicherweise verworfen wird.

Erkennung von CAID-/Provider-/SID-Unstimmigkeiten im Trace

Mit aktivem Debug 255 sehen Sie das vollständige CAID:provid-Paar, das NCam verwendet, um einen Reader abzugleichen. Wenn Ihr Readercaid = 0500 hat, aber die ECM des Kanals mit dem Provider032830 gekennzeichnet ist und dieservices oderident Zeile diesen Provider nicht enthält, stimmt NCam auf CAID ab, aber der Reader lehnt die spezifische ECM ab. Das Protokoll zeigt, dass der Reader es versucht hat, aber nichts Gültiges zurückgegeben hat.

Beheben Sie die dvbapi-Bindung und die PID-Zuordnung

Dies ist die häufigste Ursache dafür, dass eine ncam cannot decode-Fixierung in einer zuvor funktionierenden Konfiguration erforderlich ist – etwas in der dvbapi-Bindung ist falsch, entweder durch ein Image-Update, ein Neutuning des Kanals oder eine Konfiguration, die von Anfang an nie richtig war.

ncam.dvbapi-Syntax: P/I/D-Zeilen, CAID, provid, SID, ECM PID

Diencam.dvbapi Datei steuert, wie NCam Kanäle zu ECM-Quellen zuordnet. Hier ist ein konkretes Beispiel:

# Bevorzuge Provider 032830 auf CAID 0500

Die vier-Felder-FormP: CAID:provid:SID:ecmpid ist das, was Sie verwenden, wenn die automatische Erkennung die falsche ECM PID auswählt. Dies ist wichtiger, als die meisten Anleitungen anerkennen – ein Kanal mit mehreren ECM PIDs unter derselben CAID wird NCam raten lassen, und es rät oft falsch nach einem Kanal-Rescan.

boxtype / dvbapi-Modus (au, pmt_mode, listen_socket)

Inncam.conf muss der[dvbapi] Block mit Ihrer Hardware und Ihrem Image übereinstimmen. Eine typische enigma2-Konfiguration sieht so aus:

[dvbapi]

Falschespmt_mode ist ein stiller Killer – NCam erhält niemals das PMT, fordert niemals ein ECM an, und das Protokoll zeigt einfach nichts, was für diesen Kanal passiert. Die Box scheint ohne Fehler einzufrieren. Verschiedene enigma2-Images (OpenATV, OpenPLi, OpenViX, E2iPlayer) verhalten sich hier unterschiedlich.

Das Erzwingen der richtigen ECM PID, wenn die automatische Erkennung die falsche auswählt

Das betrifft die Leute am häufigsten, wenn ein Kanal sowohl ein primäres als auch ein Backup-ECM hat oder wenn FTA- und verschlüsselte Audioinhalte denselben Transportstream teilen. Die dvbapi-Schicht von NCam analysiert das PMT und sieht mehrere ECM PIDs. Mit Debug 255 sehen Sie alle aufgelistet. Das Protokoll zeigt etwas wie:

dvbapi: fand 2 ECMpids für SID 0x1234: 0x0640 (CAID 0500) 0x0641 (CAID 0500)

NCam wählt die erste aus. Wenn nur die zweite für den Provider Ihres Readers gültig ist, erhalten Sie ein CW zurück, das jedoch nicht entschlüsselt wird. Pin es explizit mit einer vier-Felder-P: Zeile, wie oben gezeigt. Nachdem ein Kanal seine Übertragungsparameter geändert hat, können alte Pin-Zeilen in ncam.dvbapi auf ECM PIDs verweisen, die nicht mehr existieren – der Kanal erhält stillschweigend kein ECM und Sie haben wieder einen schwarzen Bildschirm.

Berechtigungen und der /tmp/camd.socket / dvbapi-Gerätepfad

Auf Linux-basierten STBs benötigt NCam die Berechtigung, um in/tmp/camd.socket zu schreiben und lesen von/dev/dvb/adapter0/ca0 (und Demux-Knoten). Wenn NCam als Nicht-Root-Benutzer läuft, überprüfen Sie, ob der Benutzer in dervideo Gruppe ist und ob der Socket-Pfad beschreibbar ist. Ein Berechtigungsfehler hier führt dazu, dass NCam stillschweigend nicht bindet — Sie erhalten dasselbe Schwarzbildsymptom wie bei einem pmt_mode-Mismatch, aber das Protokoll zeigt einen Socket-Bind-Fehler, wenn Sie bei Debug 255 zuschauen.

Wenn die Karte/Share das Problem ist, nicht NCam

Sobald Sie bestätigt haben, dass die dvbapi funktioniert und ein ECM angefordert und beantwortet wird, aber der Kanal immer noch nicht dekodiert, hat sich das Problem weiter oben verschoben. Dies ist die zweite Hälfte jeder ordnungsgemäßen Untersuchung zur Behebung von ncam kann nicht dekodieren.

ECM beantwortet, aber CW ungültig: falscher Schlüssel, AES/CWPK oder Tier

Einige Systeme — Nagra-Varianten, bestimmte Conax-Implementierungen — legen einen zusätzlichen Schlüssel auf den CW. Der Leser gibt zurück, was wie ein gültiger CW aussieht, NCam wendet ihn an, und der Entschlüsseler produziert Müll. Dies ist ein AES- oder CWPK-Mismatch. Der Share hat die richtige CAID und den Anbieter, aber eine andere Schlüsselvariante als die, die Ihr Inhalt benötigt. Sie werden sehen, dass das ECM im Protokoll erfolgreich abgeschlossen wird, aber der Stream wird nicht entschlüsselt. Lösung: Überprüfen Sie die genaue CAID-Variante, die Ihr Kanal verwendet (0500 und 0503 sind unterschiedlich), und bestätigen Sie, dass der Share diese Variante ausdrücklich abdeckt.

Fehlendes Tier ist der andere Fall: die Karte oder das Konto hat CAID 0500, aber nicht das spezifische Abonnementpaket, das diesen Kanal freischaltet. Das ECM wird beantwortet (die Karte verarbeitet es), gibt aber einen null oder ungültigen CW zurück. Einige Leser protokollieren dies ausdrücklich alscw nicht gefunden .

BISS, Tunneling (konstante CW) und Powervu-Sonderfälle

BISS-verschlüsselte Kanäle und konstante CW (Tunneling)-Kanäle verwenden überhaupt keine ECMs. Wenn Sie versuchen, einen BISS-Kanal über den normalen ECM-Pfad zu entschlüsseln, erhalten Sie ein perpetuelles "kann nicht dekodieren", da es kein ECM gibt, das antworten kann. BISS-Schlüssel gehen inncam.keys oderSoftCam.Key je nach Ihrem Image, unter Verwendung des Standardformats für die SID. PowerVU ist ähnlich — es benötigt eine spezifische Handhabung und die richtige Schlüsseldatei, nicht einen Cardsharing-Leser.

Wenn Ihr Kanal BISS ist und Sie ihn als ECM-Fehler debuggen, debuggen Sie völlig das falsche.

Latenz, ecm-Timeout und 'cw zu spät' Dekodierungsfehler

In[global] vonncam.conf,ctimeout = 1500 legt die maximalen Millisekunden fest, die NCam auf einen CW wartet. Wenn der Share 1600 ms benötigt, um zu antworten, kommt der CW nach ctimeout an und wird verworfen. Das Protokoll zeigtcw zu spät oder ähnlich. Der Kanal bleibt schwarz, obwohl der Schlüssel technisch korrekt war.

Tuning: Sie könnenctimeout als Test auf 2500 ms erhöhen, aber die echte Lösung ist ein schnellerer Share oder weniger Hops. Bei CCC-Lesern steuertcccmaxhops wie viele Resharing-Knoten das ECM durchläuft — jeder Hop fügt Latenz hinzu. Setzen Sie es auf 1 oder 2, wenn Sie können.ccckeepalive = 1 verhindert die Latenz bei der Verbindungsneuverhandlung auf keepalive-fähigen Servern.

Leserabgleich: lokale Karten, ccc/cccam-Leser, Gruppe/Dienste

NCamsDienste undGruppeFilter inncam.serverundncam.userkönnen stillschweigend eine SID von einem Leser blockieren. Wenn Sie eine Dienst-Whitelist oder eine SID-Tabelle inncam.services (sidtab) einrichten und der aktuelle Kanal nicht darin enthalten ist, wird NCam das ECM nicht an diesen Leser weiterleiten. Der Leser zeigt als online an. Die CAID stimmt überein. Aber die SID wird herausgefiltert, bevor das ECM jemals gesendet wird. Überprüfen Sieservices =undgroup =Zeilen in Ihrer Leser-Konfiguration und verifizieren Sie, dass die Kanal-SID erlaubt ist.

Schritt-für-Schritt-Diagnoseliste

Führen Sie diese in der Reihenfolge aus. Jeder Schritt zeigt Ihnen genau, welche Schicht defekt ist. Dies ist der systematische ncam kann nicht dekodieren Fixprozess — überspringen Sie keine Schritte, auch wenn Sie denken, Sie kennen die Antwort.

Bestätigen Sie, dass der Leser online ist und die richtige CAID hat

1. Öffnen Sie webif → Leser. Bestätigen Sie, dass der Status grün/verbunden ist, nicht rot.
2. Überprüfen Sie, ob die CAID-Liste des Lesers die genaue CAID Ihres Kanals enthält. 0500 ≠ 0503 ≠ 0504.
3. Wenn Sie einen CCC/CCcam-Leser inncam.serververwenden, überprüfen Sieprotocol = cccam, den richtigen Host/Port und dassuser/passwordgenau mit der Serverseite übereinstimmen — einschließlich der Groß- und Kleinschreibung.
4. Überprüfen Siegroup =auf dem Leser undgroup =auf dem Benutzerkonto. Sie müssen mindestens eine Gruppennummer teilen.

Bestätigen Sie, dass dvbapi das ECM anfordert (nicht still)

1. Setzen Siedebug = 255, stimmen Sie auf den fehlerhaften Kanal ein, überprüfen Sie das Live-Protokoll innerhalb von 10 Sekunden.
2. Suchen Sie nachdvbapi: got PMToder Äquivalent. Wenn abwesend, erhält NCam das PMT nicht — falschespmt_modeoder Socket-Pfad.
3. Suchen Sie nach der ECM PID-Zeile, die die CAID und die ausgewählte PID NCam anzeigt. Wenn sie nach dem PMT nicht vorhanden ist, überprüfen Sie die I: Zeilen inncam.dvbapi, die diese CAID blockieren.
4. Bestätigen Sie, dass der Socket/tmp/camd.socketexistiert und vom NCam-Prozess beschreibbar ist.

Bestätigen Sie, dass ein CW zurückgegeben wird und dessen Timing

1. Im Protokoll finden Sie die ECM-Anforderungszeile und suchen Sie dann nach der CW-Antwortzeile, die das Timing anzeigt (z. B.ecm time: 342ms).
2. Wenn keine CW-Antwort vorhanden ist: Der Reader hat die ECM erhalten, konnte aber nicht darauf antworten. Überprüfen Sie die Stufe/Abonnement auf der Karte oder den CAID:provid-Mismatch bei einem Share.
3. Wenn eine CW-Antwort vorhanden ist, das Timing jedoch >1500ms beträgt: Sie treffen aufctimeout. Testen Sie mitctimeout = 3000in[global]vorübergehend.
4. Wenn die CW-Antwort schnell und sauber ist, der Kanal jedoch immer noch nicht dekodiert: AES/CWPK-Mismatch, falsche ECM PID oder BISS/konstante CW-Kanal wird falsch behandelt.

Isolieren Sie einen Kanal/CAID nach dem anderen

1. Testen Sie mit einem bekannten Kanal auf derselben CAID, der funktionieren sollte. Wenn das auch fehlschlägt, liegt das Problem beim Reader/Share, nicht beim spezifischen Kanal.
2. Wenn nur ein Kanal fehlschlägt: Überprüfen Sie eine einzigartige ECM PID-Situation oder eine SID, die sich in einer anderen Abonnementstufe befindet.
3. Wenn alle Kanäle auf einer CAID fehlschlagen: Der Reader ist verbunden, aber nicht für diese CAID autorisiert.
4. Wenn alle Kanäle auf allen CAIDs fehlschlagen: Die dvbapi-Bindung ist auf Socket-/pmt_mode-Ebene beschädigt.

Wenn jeder Schritt oben überprüft wird — Reader online, korrekte CAID, ECM angefordert, schnelles CW zurückgegeben — aber die Dekodierung immer noch fehlschlägt, haben Sie ein Schlüssel-/Stufen-/Stream-Problem, kein NCam-Konfigurationsproblem. Die Lösung liegt auf der Quellseite, nicht in Ihren Konfigurationsdateien.