Timeout ECM NCam: Come Risolverlo (Guida Completa)

Se stai cercando una soluzione per il timeout ECM di NCam, probabilmente hai già fissato log pieni di righe cometimeout ECM (0x0963) (3000 ms) mentre i canali si bloccano o diventano neri durante lo streaming. La parte frustrante? La maggior parte dei consigli online dice semplicemente "aumenta il valore del timeout" — il che non risolve nulla e fa sembrare i blocchi più lunghi. Questa guida affronta le cause reali, da lettori upstream non funzionanti a uno slot CI bloccato proprio sulla tua box.

Prima di toccare qualsiasi configurazione, comprendi cosa stai realmente guardando. Un timeout non è la stessa cosa di un decodifica fallita, e trattarli allo stesso modo fa perdere ore.

Cosa Significa Davvero un Timeout ECM in NCam

Ogni canale criptato invia ECM — Messaggi di Controllo dei Diritti — circa ogni 10 secondi. Il tuo client NCam ne cattura uno, lo invia a un lettore (una scheda locale, un peer di rete, un emulatore) e aspetta una parola di controllo in risposta. Quella parola di controllo è ciò che decripta realmente il flusso. Se non arriva risposta entro la finestra configurata, NCam registra un timeout e riprova o passa a un altro lettore.

Il Ciclo di Richiesta/Risposta ECM Spiegato

Il flusso va: dvbapi cattura ECM dallo stream → NCam lo instrada al miglior lettore disponibile in base al bilanciatore di carico → lettore/server lo decodifica usando la scheda → parola di controllo restituita → dvbapi la passa al decodificatore. L'intero viaggio di andata e ritorno su un setup sano con un lettore locale di solito avviene in meno di 300 ms. Su un peer di rete con un salto, potresti vedere 400–800 ms. Inizia a vedere 1500+ ms costantemente e i timeout diventano una questione di quando, non di se.

Quel valore di ecm-timeout (default 3000 ms nella maggior parte delle build) è quanto tempo NCam aspetta prima di rinunciare a un lettore per quella specifica richiesta ECM. Tre secondi sembrano molti. Ma se il tuo periodo di crittografia è di 10 secondi e stai aspettando 3 secondi, poi riprovando con un altro lettore, poi aspettando altri 3 — sei già nel prossimo periodo di crittografia senza parola di controllo. Lo schermo diventa nero.

Leggere la Riga di Timeout nel Tuo Log NCam

Una tipica riga di timeout appare così:

2026/03/15 21:04:33 c (ecm) r=MyReader CAID: 0963 PROVID: 000000 SID: 12AB PID: 0200 LEN: 183 READER: timeout (3000 ms)

Scomponendo:0963 è il CAID (il sistema di crittografia — Sky in questo caso),000000 è l'ID del fornitore,12AB è l'ID del servizio (il canale specifico), e3000 ms è la finestra di timeout scaduta. Il nome del lettore (MyReader) ti dice quale fonte upstream non ha risposto. Questo è il tuo primo indizio.

Timeout vs. 'Non Trovato' vs. 'Rifiutato' — Problemi Diversi

Questa è la cosa che quasi nessuno spiega correttamente. Questi tre risultati hanno cause radici completamente diverse:

• Timeout — Il lettore era raggiungibile, la richiesta è stata inviata, ma non è arrivata risposta in tempo. Cause: alta latenza, server sovraccarico, connessione morta, problema di segnale locale.
• Non trovato — Il lettore ha risposto, ma non ha la scheda/diritto per quel CAID o fornitore. Scheda sbagliata, pacchetto sbagliato, o la scheda semplicemente non è abbonata.
• Rifiutato — Il peer ha attivamente rifiutato la richiesta. Di solito filtraggio SID/CHID sul lato server, o un ECM falso/falsificato bloccato.

Se stai cercando un timeout con soluzioni destinate a "non trovato" — controllando i diritti, cambiando server — girerai in tondo. La parola chiave del log è tutto. Leggila prima.

Regolazione dei Parametri di Timeout e Lettore

Le posizioni dei file di configurazione variano leggermente a seconda della build, ma nella maggior parte delle configurazioni Linux embedded (box Enigma2, ecc.) stai cercando/etc/tuxbox/config/ o/var/keys/. Su un server autonomo è tipicamente/etc/oscam/. I file principali che toccherai sonooscam.conf,oscam.server, eoscam.dvbapi.

ecm-timeout in [global] e Per-Reader

L'impostazione globale si trova inoscam.conf sotto il[global] blocco:

[global]

Puoi sovrascrivere questo per lettore inoscam.server:

[reader]

Aumentare l'ecm-timeout da 3000 a 5000 ms dà ai peer lenti più tempo per rispondere. Questo ti garantisce una decodifica stabile su un server al limite. Ma — e questo è importante — significa anche che ogni ECM fallito ora richiede 5 secondi interi prima che si attivi il failover. Se hai tre lettori e uno è morto, ogni cambio di canale potenzialmente aspetta 5 secondi per ogni lettore morto prima di atterrare su quello funzionante. Aumentare il timeout senza risolvere il problema sottostante peggiora l'esperienza dell'utente, non la migliora.

lb_retrylimit e lb_reopen_seconds per il bilanciamento del carico

Il bilanciatore di carico di NCam tiene traccia di quali lettori stanno funzionando bene e instrada i nuovi ECM di conseguenza. Due impostazioni controllano come gestisce i lettori scadenti:

[global]

lb_retrylimit imposta il tempo di risposta ECM (in ms) sopra il quale un lettore viene de-prioritizzato. A 900 ms, qualsiasi lettore che richiede costantemente più tempo di quello viene spostato in basso nella lista.lb_reopen_seconds controlla quanto a lungo NCam aspetta prima di dare un'altra possibilità a un lettore scadente — 900 secondi (15 minuti) impedisce di martellare un peer morto ad ogni singola richiesta ECM e di aggiungere ritardi di 3 secondi in tutto. Se questo è impostato troppo basso (come 60 secondi) e hai un upstream realmente morto, NCam continua a riprovare costantemente, e ogni tentativo è un altro timeout che consuma il tuo stream.

cccmaxhops, cccwantemu e limiti specifici per lettore

PerCCcam lettori,cccmaxhops limita quanti salti una scheda può essere condivisa prima che NCam la ignori. Tienilo a 1 o 2 al massimo. Schede a 3–5 salti di distanza sono spazzatura per il tempo ECM — stai aggiungendo la latenza di più server intermedi.

[reader]

Impostacccwantemu = 0 a meno che tu non voglia effettivamente schede emulate da quel peer. Le voci emulate possono apparire nel bilanciatore di carico e fallire su canali crittografati reali, causando timeout spurii.

Dove si trovano i file di configurazione e come ricaricarli

Dopo la modifica, non è necessario un riavvio completo. Nell'interfaccia web di NCam (di solito ahttp://your-box:8888), vai aConfig → Riavvia o usa il pulsante Ricarica Lettori. In alternativa, invia un SIGHUP al processo:killall -HUP oscam. Le modifiche aoscam.server hanno effetto immediato al ricaricamento. Le modifiche aoscam.conf [global] richiedono tipicamente un riavvio completo delprocesso oscam, non solo un ricaricamento del lettore. process, not just a reader reload.

Latenza di rete e cause lato server

Prima di cambiare un singolo valore di configurazione, scopri dove si verifica effettivamente il ritardo. Cambiare ecm-timeout quando il problema è un lettore upstream non funzionante non porta a nulla. Trascorri 10 minuti a misurare prima.

Misurare il tempo di andata e ritorno verso il peer upstream

Inizia con un ping di base all'IP o al nome host del server. Se stai ottenendo tempi di ping superiori a 200 ms su un server che dovrebbe trovarsi in Europa, questo è il tuo problema. Poi approfondisci conmtr (Traceroute di Matt):

mtr --report --report-cycles 100 yourpeer.example.com

Questo ti mostra la perdita di pacchetti e la latenza per ogni hop. Un singolo hop con il 40% di perdita di pacchetti nel mezzo del percorso causerà timeout ECM intermittenti anche con un server sano dall'altra parte. La soluzione lì è il percorso di rete, non la configurazione di NCam.

Ora incrocia i dati con l'interfaccia web di NCam. SottoStato, la colonna del tempo ECM mostra i tempi di risposta effettivi per lettore. Se vedi costantemente 1200–1800 ms lì con un timeout di 3000 ms, stai vivendo al limite. Un momento sbagliato e scade il tempo.

MTU, frammentazione e problemi di porta (intervallo predefinito 12000)

Il protocollo CCcam di solito funziona sulla porta 12000 (configurabile nella linea del dispositivo del tuo lettore). Camd35 di solito utilizza 15000 o 15001. Queste sono connessioni TCP, quindi la frammentazione MTU non dovrebbe essere un problema — ma le tabelle di stato del firewall possono interrompere silenziosamente le connessioni inattive.

Questa è la causa del problema "timeout dopo inattività" che sorprende le persone. Guardi un canale per 20 minuti, ti fermi, torni un'ora dopo e non si decodifica. La connessione è tecnicamente ancora "attiva" dalla prospettiva di NCam, ma il NAT/firewall ha interrotto l'entrata di stato. La soluzione: abilita i keepalive TCP a livello di OS, o configura il tuo router per utilizzare un timeout di tracciamento della connessione più lungo per quelle porte. Su router basati su OpenWrt, aumentanf_conntrack_tcp_timeout_established sopra 7200 secondi.

Server sovraccarico: picchi di tempo ECM sotto carico concorrente

Una singola smart card fisica può rispondere solo a un ECM alla volta. Se un server ha 50 client che condividono una scheda e tutti e 50 colpiscono un refresh del periodo crittografico simultaneamente, quella scheda ha una coda. Il tempo ECM sale a 2000–3000 ms. Durante le ore di punta (serate, eventi sportivi nel fine settimana), questo diventa drammaticamente peggiore. La scheda non è rotta, il server non è mal configurato — è solo matematica. Troppi client per scheda.

Vedrai chiaramente questo schema: i tempi ECM nell'interfaccia web sono stabili a 400 ms per tutta la mattina, poi salgono a 1800 ms dalle 19:00 in poi. Questo è sovrascrittura del server, punto e basta. Nessuna quantità di ottimizzazione locale di NCam lo risolve. L'unica vera soluzione al timeout ECM di NCam per questo è trovare un server con meno client per scheda, o aggiungere un secondo peer upstream con lo stesso CAID come failover.

Problemi di sintonizzatore locale/CI che sembrano timeout

Ecco quello che spreca più tempo diagnostico: il problema non ha nulla a che fare con la rete. Uno slot CI (Common Interface) bloccato, un lettore di schede interne degradato o un segnale satellitare debole possono tutti produrre voci di timeout ECM nei log di NCam — perché l'ECM è stato catturato da uno stream difettoso, o il CI non ha restituito alcuna parola di controllo, e NCam lo ha registrato come un timeout.

Controlla i livelli di segnale nel menu del tuo ricevitore. SNR sotto circa 12 dB nella maggior parte delle configurazioni, o qualità del segnale sotto l'80%, inizia a produrre pacchetti corrotti. Questo include ECM corrotti. NCam non può decodificare un ECM confuso; scade aspettando una risposta che non può arrivare perché l'input era spazzatura fin dall'inizio. Prova lo stesso canale su un trasponder con una forza del segnale nota e buona e vedi se i timeout scompaiono. Se lo fanno, il problema è la tua antenna, LNB o cavo — non NCam.

Flusso di lavoro diagnostico passo dopo passo

Il più grande errore che le persone fanno è cambiare due o tre cose contemporaneamente e poi non sapere quale ha funzionato. Ecco il runbook che uso. Cambia una variabile. Osserva per almeno 15 minuti. Poi passa al passo successivo.

Abilita il logging dettagliato (livello di debug) in modo sicuro

Inoscam.conf [globale], aumenta temporaneamente il logging:

[globale]

Il livello di debug 64 ti fornisce dettagli sul routing ECM senza l'estrema verbosità del debug completo (255). Non lasciare il debug completo attivo permanentemente: su hardware embedded con storage lento, scrivere megabyte di log all'ora sulla memoria flash accorcerà la vita del dispositivo e può causare ritardi I/O che influenzano il decoding stesso. Abilitalo, riproduci il problema, poi disattivalo.

Correlare i timestamp dei log con il freeze

Quando un canale si blocca, annota l'ora esatta. Estrai il log e guarda 5–15 secondi prima di quel timestamp: i timeout ECM si manifestano prima del freeze visibile perché la parola di controllo termina leggermente dopo che la richiesta fallisce. Se vedi un gruppo di righe di timeout alle 21:04:25 e lo schermo è diventato nero alle 21:04:33, quello è il tuo evento. Annota il CAID, il PROVID e il SID di quelle righe.

Testa un lettore alla volta

Inoscam.serverdisabilita tutti i lettori tranne uno aggiungendoenable = 0 a ciascun blocco che vuoi saltare, poi ricarica. Forza una sintonizzazione sul canale problematico. Guarda la scheda Stato di webif — in particolare la colonna del tempo ECM e i contatori ecmok/ecmnok per il tuo lettore attivo. Se quel lettore va in timeout con carico zero (solo la tua singola sessione), il problema è la latenza di quel lettore o la tua connessione ad esso. Se risponde bene, riattiva il lettore successivo e testa con entrambi.

Questo approccio a lettore singolo è il più veloce diagnostico di correzione del timeout ECM di NCam che conosca. Elimina immediatamente i problemi di bilanciamento del carico e gli effetti di interazione tra lettori.

Conferma la correzione senza falsi positivi

Un singolo zap di canale riuscito non conferma una correzione. NCam memorizza brevemente l'ultima parola di controllo valida, quindi puoi zapparla, ottenere un'immagine, pensare che sia risolto — e poi si blocca 10 secondi dopo quando inizia il prossimo periodo crittografico e si verifica di nuovo lo stesso timeout. Guarda il contatore ecmok in webif per almeno 15 minuti, sul canale specifico che stava fallendo. Vuoi vedere ecmok incrementare ogni 10 secondi con tempi ECM ben al di sotto della tua impostazione di timeout, con zero eventi ecmnok durante quella finestra. Questa è una correzione confermata.

Come scegliere una fonte upstream affidabile

Ottenere un peer upstream solido è la correzione a lungo termine del timeout ECM di NCam che nessuna quantità di ottimizzazione della configurazione locale può sostituire. Ecco cosa conta realmente quando si valuta una fonte.

Criteri che correlano con tempi ECM bassi

Il tempo di risposta ECM è il miglior predittore di affidabilità. Qualsiasi peer decente dovrebbe fornire tempi di risposta inferiori a 700 ms per il CAID di cui hai bisogno, misurati durante le ore di punta — non solo alle 2 del mattino quando il server è inattivo. La prossimità geografica conta qui: un server fisicamente vicino a te su un percorso di rete a bassa latenza supererà sempre un server "premium" su un percorso transatlantico congestionato.

Il conteggio dei salti è l'altro grande fattore. Una scheda condivisa a 1 salto dalla fonte (il peer sta eseguendo la scheda reale) batterà sempre una scheda a 3 salti attraverso una catena di ri-condivisione. Ogni salto aggiunge latenza e un potenziale punto di guasto. Chiedi specificamente quanti salti ci sono dalla scheda fisica a cui viaggia la tua richiesta ECM. Qualsiasi cosa sopra 2 è un campanello d'allarme.

Campanelli d'allarme che prevedono timeout frequenti

Tempi ECM superiori a 1200 ms durante un periodo di test dovrebbero squalificare immediatamente una fonte. Questo è già il 40% del tuo budget di timeout predefinito speso, senza margine per la variazione. I server senza limite di client tendono a peggiorare progressivamente nel tempo man mano che accolgono più utenti: osserva se i tempi ECM sono stabili su una finestra di osservazione di 30 minuti o in lenta crescita.

Nessun periodo di test offerto è di per sé un campanello d'allarme. Qualsiasi operatore sicuro delle prestazioni del proprio server ti permetterà di testarlo. Se non puoi verificare il tempo ECM prima di impegnarti, stai volando alla cieca.

Testare prima di impegnarsi

Configura il nuovo peer come lettore singolo inoscam.server con tutti gli altri lettori disabilitati. Eseguilo durante un periodo di punta serale: è allora che si manifesta l'oversubscription. Guarda la colonna del tempo ECM in webif. Un server che mostra 350 ms a mezzogiorno e 2400 ms alle 20:00 è sovrascritto e causerà timeout regolarmente. Un server che mantiene 400–600 ms durante le ore di punta vale la pena mantenerlo. Il rapporto ecmnok/ecmok dovrebbe rimanere ben al di sotto del 5% su una fonte affidabile: se stai vedendo il 15% di fallimenti ECM anche quando i tempi di risposta sembrano a posto, c'è un problema di filtraggio o di autorizzazione da indagare separatamente.