Errore NCam "Impossibile decodificare": Cause& Soluzioni

Se stai cercando una soluzione per l'errore ncam impossibile decodificare, la prima cosa da capire è che questo errore non è un problema unico — sono almeno quattro problemi diversi che producono lo stesso messaggio di log. Riavviare NCam e reinserire la tua linea è il consiglio che troverai nella maggior parte dei forum. Risolve quasi nulla. Questa guida analizza la causa reale seguendo il ciclo di vita dell'ECM dalla fase di analisi PMT all'applicazione della parola di controllo, in modo da poter isolare esattamente dove la tua configurazione si interrompe.

Cosa significa realmente "Impossibile decodificare" in NCam

NCam è un fork di OSCam. La directory di configurazione è tipicamente/etc/tuxbox/config/ e i file seguono la denominazione oscam.* —ncam.conf,ncam.server,ncam.dvbapi,ncam.user. Se sei abituato a OSCam, la struttura è identica. Anche il comportamento è identico, compreso il modo in cui registra i fallimenti di decodifica.

Il messaggio "impossibile decodificare" significa che NCam ha ricevuto una parola di controllo (CW) da un lettore, ma il decrittatore l'ha rifiutata, oppure nessuna CW è arrivata in tempo. Lo stream rimane criptato. La scatola mostra uno schermo nero. Questo è distinto da tre altri stati di errore che vedrai nei log:

• nessuna sorgente disponibile — nessun lettore corrispondeva al CAID
• sid non trovato — l'ID del servizio non è presente nella lista dei canali di alcun lettore
• nessun lettore corrispondente — il CAID esiste ma il filtro del fornitore/gruppo ha bloccato il lettore

"Impossibile decodificare" implica specificamente che il pipeline ECM è andato oltre — è stato contattato un lettore — ma il passaggio finale di decodifica è fallito. Questa è la distinzione che conta.

La riga di log e dove appare

Apri l'interfaccia web di NCam suhttp://your-box-ip:8888 (o qualsiasihttpport tu abbia impostato in[webif]) e vai su Live Log. Stai cercando righe contrassegnatedvbapi e voci che mostranoecm hash,no cw, o l'esplicitonon può decodificare la stringa. Il percorso del file di log è impostato in[global] dincam.conf — tipicamentelogfile = /var/log/ncam.log o/tmp/ncam.log su sistemi embedded.

Errore di decodifica vs. nessuna richiesta ECM vs. ECM rifiutato

Qui è dove la maggior parte della risoluzione dei problemi va male. "Nessuna richiesta ECM" significa che il livello dvbapi non ha mai chiesto un CW — è unpmt_mode o un problema di socket. "ECM rifiutato" significa che il server ha risposto con un errore. "Non può decodificare" significa che un CW è arrivato ma non ha funzionato. Questi tre risultati necessitano di soluzioni completamente diverse, e sembrano superficialmente simili nel log se non leggi attentamente.

Come NCam si differenzia dalla denominazione dvbapi di OSCam

Quasi per niente, onestamente. Ilncam.dvbapi file utilizza la stessa sintassi P:/I:/D: dioscam.dvbapi. Alcuni build posizionano le configurazioni in/usr/keys/ invece di/etc/tuxbox/config/ — controlla la tua immagine specifica. La porta webif predefinita è 8888 nella maggior parte delle build di NCam rispetto all'8888 di OSCam, quindi nessuna modifica lì.

Leggi i log prima di cambiare qualcosa

Sul serio. Ogni modifica di configurazione che fai alla cieca aggiunge una nuova variabile. Prima di toccare qualsiasi cosa, ottieni una traccia pulita di ciò che NCam sta effettivamente facendo con un canale specifico.

Abilita il logging completo (debug 255) in modo sicuro

Inncam.conf sotto[global], impostadebug = 255 temporaneamente. Questo registra tutto: parsing PMT, selezione PID ECM, corrispondenza del lettore, temporizzazione CW e chiamate al decrittatore. Su un Pi o un STB debole, questo inonderà il log e può effettivamente rallentare le cose a tal punto da causare CW tardivi — il che crea un sintomo che assomiglia al problema che stai cercando di diagnosticare. Cattura 60 secondi di log per un canale, poi impostadebug = 0 di nuovo. Non lasciarlo in esecuzione.

Puoi anche attivare la verbosità per lettore nel webif senza modificare il file, il che è più pulito durante il debug dal vivo.

Tracciamento del ciclo di vita ECM: richiesta, trovato, cw, decodifica

Una traccia di decodifica riuscita appare così in ordine: dvbapi analizza il PMT e trova i PID ECM, NCam seleziona un PID e invia una richiesta ECM a un lettore corrispondente, il lettore restituisce un CW, NCam passa il CW al decrittatore, il decrittatore lo applica e il flusso viene decrittato. "Non può decodificare" si interrompe a quell'ultimo passo — o il CW non è mai arrivato, è arrivato troppo tardi, o è arrivato sbagliato.

Cerca la riga che mostra il tempo ECM in millisecondi. Qualcosa cometempo ecm: 340ms va bene. 1800ms su un canale con un periodo di crittografia di 1,8 secondi significa che il CW sta arrivando proprio al limite e potrebbe essere scartato.

Identificare le discrepanze CAID/provider/SID nella traccia

Con il debug 255 attivo, vedrai la coppia CAID:provid completa che NCam sta usando per abbinare un lettore. Se il tuo lettore hacaid = 0500 ma l'ECM del canale è contrassegnato con provider032830 e iservizi oident non includono quel provider, NCam corrisponde su CAID ma il lettore rifiuta il specifico ECM. Il log mostrerà che il lettore ha tentato ma non ha restituito nulla di valido.

Correggi il Binding dvbapi e la Mappatura PID

Questa è la causa più comune di un fix "ncam cannot decode" necessario in un setup che funzionava precedentemente — qualcosa nel binding dvbapi è errato, sia a causa di un aggiornamento dell'immagine, una risintonizzazione del canale, o una configurazione che non è mai stata corretta fin dall'inizio.

sintassi ncam.dvbapi: righe P/I/D, CAID, provid, SID, ECM PID

Ilfile ncam.dvbapi controlla come NCam mappa i canali alle fonti ECM. Ecco un esempio concreto:

# Preferisci il provider 032830 su CAID 0500

La forma a quattro campiP: CAID:provid:SID:ecmpid è ciò che usi quando l'auto-rilevamento sceglie il PID ECM sbagliato. Questo è più importante di quanto la maggior parte delle guide riconosca — un canale con più PID ECM sotto lo stesso CAID farà indovinare NCam, e spesso indovina male dopo una riscanalizzazione del canale.

boxtype / modalità dvbapi (au, pmt_mode, listen_socket)

Inncam.conf, il[dvbapi] blocco deve corrispondere al tuo hardware e immagine. Un tipico setup enigma2 appare così:

[dvbapi]

Modalitàpmt_mode errata è un killer silenzioso — NCam non riceve mai il PMT, non richiede mai un ECM, e il log mostra semplicemente che non succede nulla per quel canale. La box sembra bloccarsi senza alcun errore. Diverse immagini enigma2 (OpenATV, OpenPLi, OpenViX, E2iPlayer) si comportano diversamente qui.

Forzare il corretto ECM PID quando l'auto-detect sceglie quello sbagliato

Questo colpisce le persone più spesso quando un canale trasmette sia un ECM primario che uno di backup, o quando l'audio FTA e criptato condivide lo stesso flusso di trasporto. Il livello dvbapi di NCam analizza il PMT e vede più PID ECM. Con il debug 255, vedrai tutti elencati. Il log mostra qualcosa come:

dvbapi: trovato 2 ECMpids per SID 0x1234: 0x0640 (CAID 0500) 0x0641 (CAID 0500)

NCam sceglie il primo. Se solo il secondo è valido per il provider del tuo lettore, riceverai un CW ma non si decripterà. Fissalo esplicitamente con una riga P: a quattro campi come mostrato sopra. Dopo che un canale cambia i suoi parametri di trasmissione, le vecchie righe pin in ncam.dvbapi possono puntare a PID ECM che non esistono più — il canale silenziosamente non riceve ECM e sei di nuovo con lo schermo nero.

Permessi e il percorso del dispositivo /tmp/camd.socket / dvbapi

Su STB basati su Linux, NCam ha bisogno di permessi per scrivere su/tmp/camd.socket e leggi da/dev/dvb/adapter0/ca0 (e nodi demux). Se NCam funziona come utente non root, controlla che l'utente sia nelvideo gruppo e che il percorso del socket sia scrivibile. Un errore di autorizzazione qui causa il fatto che NCam non si colleghi silenziosamente — ottieni lo stesso sintomo dello schermo nero come un mismatch di pmt_mode, ma il log mostrerà un errore di collegamento del socket se stai guardando a debug 255.

Quando il problema è la scheda/share, non NCam

Una volta confermato che il dvbapi funziona e che un ECM viene richiesto e risposto, ma il canale continua a non decodificare, il problema è salito a monte. Questa è la seconda metà di qualsiasi indagine corretta su "ncam non può decodificare".

ECM risposto ma CW non valido: chiave errata, AES/CWPK o tier

Alcuni sistemi — varianti Nagra, certe implementazioni Conax — sovrappongono una chiave aggiuntiva sopra il CW. Il lettore restituisce quello che sembra un CW valido, NCam lo applica e il descrambler produce spazzatura. Questo è un mismatch di AES o CWPK. La share ha il CAID e il provider giusti ma una variante di chiave diversa da quella richiesta dal tuo contenuto. Vedrai l'ECM completarsi con successo nel log ma il flusso non si decripta. Correzione: verifica la variante CAID esatta utilizzata dal tuo canale (0500 e 0503 sono diverse) e conferma che la share copra esplicitamente quella variante.

Il tier mancante è l'altro caso: la scheda o l'account ha CAID 0500 ma non il pacchetto di abbonamento specifico che sblocca questo canale. L'ECM viene risposto (la scheda lo elabora) ma restituisce un CW nullo o non valido. Alcuni lettori registrano questo esplicitamente comecw non trovato .

BISS, Tunneling (CW costante) e casi speciali di Powervu

I canali criptati BISS e i canali a CW costante (tunneling) non utilizzano affatto ECM. Se stai cercando di decriptare un canale BISS attraverso il normale percorso ECM, otterrai un perpetuo "impossibile decodificare" perché non c'è ECM a rispondere. Le chiavi BISS vanno inncam.keys oSoftCam.Key a seconda della tua immagine, utilizzando il formato standard per il SID. PowerVU è simile — necessita di una gestione specifica e del file di chiave giusto, non di un lettore di condivisione di schede.

Se il tuo canale è BISS e lo stai debugando come un errore ECM, stai debugando completamente la cosa sbagliata.

Latenza, timeout ecm e errori di decodifica 'cw troppo tardi'

In[global] dincam.conf,ctimeout = 1500 imposta il massimo di millisecondi che NCam aspetta per un CW. Se la share impiega 1600ms a rispondere, il CW arriva dopo ctimeout e viene scartato. Il log mostracw troppo tardi o simile. Il canale rimane nero anche se la chiave era tecnicamente corretta.

Sintonizzazione: puoi aumentarectimeout a 2500ms come test, ma la vera correzione è una share più veloce o meno salti. Su lettori CCC,cccmaxhops controlla quanti nodi di ridistribuzione attraversa l'ECM — ogni salto aggiunge latenza. Impostalo su 1 o 2 se puoi.ccckeepalive = 1 previene la latenza di rinegoziazione della connessione su server capaci di keepalive.

Corrispondenza lettore: localcards, lettore ccc/cccam, gruppo/servizi

Iservizi di NCam egruppo filtri inncam.server encam.user possono silenziosamente bloccare un SID da un lettore. Se imposti una whitelist dei servizi o una tabella SID inncam.services (sidtab) e il canale attuale non è in essa, NCam non instraderà l'ECM a quel lettore. Il lettore appare online. Il CAID corrisponde. Ma il SID viene filtrato prima che l'ECM venga mai inviato. Controllaservizi = egruppo = righe nella configurazione del tuo lettore e verifica che il SID del canale sia consentito.

Checklist diagnostica passo-passo

Esegui questi passaggi in ordine. Ogni passaggio ti dice esattamente quale livello è rotto. Questo è il processo sistematico di risoluzione dei problemi di decodifica di ncam — non saltare i passaggi anche se pensi di conoscere la risposta.

Conferma che il lettore sia online e abbia il CAID corretto

1. Apri webif → Lettori. Conferma che lo stato sia verde/connesso, non rosso.
2. Controlla che l'elenco CAID del lettore includa il CAID esatto del tuo canale. 0500 ≠ 0503 ≠ 0504.
3. Se utilizzi un lettore CCC/CCcam inncam.server, verificaprotocollo = cccam, host/porta corretti, e cheutente/password corrispondano esattamente al lato server — inclusi maiuscole e minuscole.
4. Controllagruppo = sul lettore egruppo = sull'account utente. Devono condividere almeno un numero di gruppo.

Conferma che dvbapi richieda l'ECM (non silenzioso)

1. Impostadebug = 255, sintonizzati sul canale che fallisce, controlla il log live entro 10 secondi.
2. Cercadvbapi: ricevuto PMT o equivalente. Se assente, NCam non sta ricevendo il PMT — modalitàpmt_mode errata o percorso socket.
3. Cerca la linea ECM PID che mostra il CAID e il PID NCam selezionati. Se assente dopo che il PMT è stato visto, controlla le linee I: inncam.dvbapi che bloccano quel CAID.
4. Conferma che il socket/tmp/camd.socket esista ed è scrivibile dal processo NCam.

Conferma che un CW ritorni e il suo timing

1. Nel log, trova la linea della richiesta ECM, poi cerca la linea della risposta CW che mostra il timing (ad es.,tempo ecm: 342ms).
2. Se non c'è risposta CW: il lettore ha ricevuto l'ECM ma non è riuscito a rispondere. Controlla il tier/abbonamento sulla scheda, o la discrepanza CAID:provid su una condivisione.
3. Se esiste una risposta CW ma il timing è >1500ms: stai colpendoctimeout.Testa conctimeout = 3000 in[global] temporaneamente.
4. Se la risposta CW è veloce e pulita ma il canale non decodifica ancora: discrepanza AES/CWPK, PID ECM errato, o canale BISS/CW costante gestito in modo errato.

Isola un canale/CAID alla volta

1. Testa con un canale noto sullo stesso CAID che dovrebbe funzionare. Se anche quello fallisce, il problema è il lettore/condivisione, non il canale specifico.
2. Se solo un canale fallisce: controlla per una situazione unica di PID ECM o un SID che è in un tier di abbonamento diverso.
3. Se tutti i canali su un CAID falliscono: il lettore è connesso ma non autorizzato per quel CAID.
4. Se tutti i canali su tutti i CAID falliscono: il binding dvbapi è rotto a livello di socket/pmt_mode.

Se ogni passaggio sopra controlla — lettore online, CAID corretto, ECM richiesto, CW veloce restituito — ma la decodifica fallisce ancora, stai affrontando un problema di chiave/tier/stream, non un problema di configurazione NCam. La soluzione è sul lato sorgente, non nei tuoi file di configurazione.