CCcam DVBAPI Delayer: Risolvi il congelamento& Guida all'impostazione

Se sei arrivato qui perché i tuoi canali si bloccano ogni 10 secondi in modo preciso, stai affrontando una corsa temporale — non una linea cattiva. Ilconfigurazione del delayer dvbapi di CCcam è la manopola che lo risolve. Questa guida copre esattamente come impostarlo, come leggere i log per sintonizzarlo correttamente e quando non aiuterà, così non perdi tre ore a inseguire la cosa sbagliata.

Cosa fa realmente il DVBAPI Delayer

L'interfaccia DVBAPI è come il tuo decoder (o ricevitore basato su Linux che esegue Enigma2, ad esempio) espone il suo CA descrambler al software di spazio utente. Invece di utilizzare un CAM fisico, un client DVBAPI come OScam o il plugin DVBAPI integrato di CCcam scrive le parole di controllo (CW) direttamente nel demuxer tramite/dev/dvb/adapterX/caY.

Il delayer inserisce una pausa — misurata in millisecondi — tra il momento in cui il software riceve una CW decrittografata e il momento in cui scrive quella CW nell'hardware. Senza quella pausa, la CW può arrivare più velocemente di quanto il demuxer sia pronto a consumarla. Il risultato: uno schermo nero, un congelamento o un breve stutter ad ogni cambio di chiave.

Tempi ECM-a-parola di controllo in CCcam DVBAPI

Definizioni rapide così siamo sulla stessa lunghezza d'onda. UnECM (Messaggio di Controllo dei Diritti) è un breve pacchetto crittografato trasmesso nel flusso DVB. Il tuo client di condivisione lo invia a monte, la scheda lo decrittografa e restituisce unaparola di controllo — la chiave effettiva di 8 byte di cui il tuo descrambler ha bisogno per decodificare il video. Quel viaggio completo richiede alcuni millisecondi a seconda della tua linea.

La maggior parte dei fornitori di TV a pagamento ruotano le loro chiavi su unperiodo crittografico di circa 10 secondi. Quando il periodo cambia, arriva un nuovo ECM, viene recuperata una nuova CW e il client DVBAPI deve scriverla nel demuxer esattamente al momento giusto. Troppo presto e l'hardware la scarta. Troppo tardi e ottieni un intervallo di congelamento.

Perché è necessaria una pausa prima di scrivere la CW nel demuxer

L'hardware del demuxer su molti ricevitori — specialmente le unità Dreambox più vecchie e le scatole Enigma2 economiche — ha una finestra molto piccola in cui accetta una nuova CW. Se il tuo client di condivisione è veloce (il che è di solito una cosa buona), può vincere la corsa contro l'hardware e scrivere prima che il demuxer abbia finito di passare al nuovo periodo crittografico.

Il delayer costringe il software a rimanere sulla CW per N millisecondi prima di scrivere. Quel margine di manovra consente all'hardware di recuperare. Sembra controintuitivo — rallentare la risposta per risolvere un problema — ma funziona, e funziona costantemente quando è sintonizzato correttamente.

Come CCcam differisce dalla gestione dvbapi di OScam

Il supporto nativo di DVBAPI di CCcam è piuttosto basilare. Funzionerà, ma la configurabilità è limitata — ottieni un ritardo globale, e questo è tutto. L'implementazione dvbapi di OScam è notevolmente più matura: ritardi per CAID, sovrascritture per SID, un'interfaccia web che mostra i tempi ECM in tempo reale e un targeting migliore degli adattatori.

Ecco perché la maggior parte delle configurazioni di produzione collega CCcam a OScam: CCcam gestisce il protocollo e la rete di condivisione delle schede, ma OScam gestisce il vero descrambling. Se stai ancora eseguendo CCcam DVBAPI in modo nativo e combattendo contro i congelamenti, il percorso di migrazione a OScam vale la pena considerarlo — maggiori dettagli nell'ultima sezione.

Configurazione del Delayer passo dopo passo

Ottenere laconfigurazione del delayer dvbapi di CCcam corretta inizia con sapere quale file modificare. Il percorso varia a seconda della tua immagine e se stai utilizzando il DVBAPI integrato di CCcam o collegandoti tramite OScam.

Localizzare il config: CCcam.cfg vs oscam.dvbapi

Per il puro CCcam DVBAPI, il config principale si trova in/var/etc/CCcam.cfg su la maggior parte delle immagini Enigma2 (OpenATV, OpenPLi, OpenViX). Su configurazioni più vecchie o immagini basate su Gemini potresti trovarlo in/etc/CCcam.cfg. Controlla entrambi se non sei sicuro.

Se stai usando OScam con un lettore CCcam (la configurazione più comune), il ritardo si trova in/etc/tuxbox/config/oscam/oscam.dvbapi o/var/etc/oscam.dvbapi, di nuovo a seconda della tua immagine. OpenATV tende a usare/var/etc/. Le immagini OE-Alliance a volte lo mettono sotto/etc/oscam/. Eseguifind / -name oscam.dvbapi 2>/dev/null se non riesci a trovarlo.

Impostare il valore di ritardo (parametro DELAY e intervalli ms)

InCCcam.cfg, la riga appare così:

DELAY : 150

Sono millisecondi. Inizia da100–300 ms e regola da lì. Se i canali si bloccano ancora al cambio di chiave, aumentalo di 50 ms. Se il cambio canale sembra lento — premi un pulsante e aspetta un attimo troppo a lungo — sei andato troppo in alto, riportalo indietro in passi di 25 ms.

Inoscam.dvbapi, il formato è diverso. Una riga di ritardo globale appare così:

DELAY : 150

Ma puoi anche mirare a voci specifiche. Il formato completo per voce è:

P: CAID:ProvID:SID:PMT_PID:ECM_PID : DELAY

Ad esempio, per impostare un ritardo di 200 ms per una specifica combinazione CAID/fornitore lasciando tutto il resto a 100 ms:

DELAY : 100

Dove alcuni ricevitori espongono un'interfaccia web per CCcam (il server HTTP integrato funziona sulla porta 16001 per impostazione predefinita), potresti trovare anche un campo "DVB API DELAY" lì. Non fare affidamento solo su di esso — le modifiche tramite l'interfaccia web non sempre sopravvivono a un riavvio del demone a meno che anche il file di configurazione sottostante non venga aggiornato.

Sovrascritture di ritardo per canale e per CAID

Questo è ciò che la maggior parte delle guide manca. Un ritardo globale è impreciso — rallenta ogni cambio di canale su ogni CAID. Ma in pratica, il problema di tempistica è quasi sempre specifico per CAID o addirittura specifico per trasponder. Il periodo crittografico di un fornitore si sincronizza bene a 100 ms; un altro ha bisogno di 250 ms perché i loro ECM arrivano leggermente in ritardo rispetto al cambio di chiave.

OScam'soscam.dvbapi ti consente di definire i ritardi in modo preciso. Se conosci il CAID (ad es., 0963 o 1810) del pacchetto problematico, imposta un ritardo più alto solo per quella voce e lascia il globale più basso. Il tuo pacchetto sportivo cambia rapidamente; il tuo pacchetto film rimane stabile. Entrambi funzionano.

Su un trasponder con CAID misti — diciamo, un pacchetto free-to-air multiplexato con uno criptato — assicurati che il tuo targeting CAID sia preciso o rallenterai il cambio canale su quelli che non ne hanno bisogno.

Riavviare il demone e confermare il caricamento delle modifiche

CCcam non ricarica la configurazione a caldo. Dopo aver modificatoCCcam.cfg, riavvialo:

killall -9 CCcam&& sleep 2&& CCcam

O tramite il tuo script di init se ne hai uno configurato (/etc/init.d/CCcam riavvia). Controlla/tmp/CCcam.log o qualunque percorso di log tu abbia configurato e cerca la riga DELAY che viene analizzata all'avvio.

Per OScam, un riavvio soft è sufficiente:

killall -HUP oscam

Oppure usa l'interfaccia web di OScam sulla porta 8888 → Riavvia. Controlla che la pagina delle informazioni confermi che il valore di ritardo dvbapi è quello che ti aspetti.

Leggere i log per trovare il giusto ritardo

Indovinare i valori di ritardo è una perdita di tempo. I log ti dicono esattamente cosa sta succedendo, e cinque minuti a leggerli battono un'ora di tentativi ed errori.

Abilitare il logging di debug (loghistorysize, livelli di log)

Neloscam.conf di OScam, sotto[global]:

[global]

Il livello 64 ti dà dettagli a livello ECM senza inondare il log di rumore. Se hai bisogno di più, combinato:loglevel = 64+32 aggiunge informazioni di debug del lettore. Qualsiasi valore superiore e avrai bisogno di unloghistorysize più grande o la cronologia si riempie prima che tu possa leggerla.

Per CCcam, la verbosità del log è impostata inCCcam.cfg:

LIVELLO DEBUG : 1

Il livello 1 è solitamente sufficiente per vedere gli eventi di consegna CW. Il livello 3 fornisce il traffico ECM completo ma genera molta uscita.

Interpretare il tempo di decodifica/freeze nel log

Quello che stai cercando è il tempo tra l'arrivo dell'ECM e la consegna del CW, e come questo si correla con i tuoi eventi di freeze. Nei log di OScam, ogni riga di decodifica appare all'incirca così:

[reader] (tempo ecm: 87 ms) CW trovato [0963/000000/1234]

Quel valore di 87 ms è il tuo tempo di andata e ritorno ECM. Se il tuo periodo crittografico è di 10 secondi e i tuoi ECM arrivano a un tempo di decodifica di 87 ms in modo costante, un ritardo di 100–150 ms copre il gap con margine. Se quel numero aumenta occasionalmente a 400 ms (problema di rete, server occupato), hai bisogno di un ritardo maggiore o di una linea migliore.

Confronta i timestamp dei freeze nel log del tuo ricevitore con l'intervallo di cambio chiave. Se i freeze si verificano costantemente a intervalli di 9.8–10.2 secondi, si tratta di un problema di temporizzazione e il ritardatore lo risolverà. Se i freeze sono casuali — ogni pochi minuti, senza un modello — non è un problema di temporizzazione.

Strumenti: tail -f, pagina di stato oscam, colonna tempo ECM

L'interfaccia web di OScam suhttp://[receiver-ip]:8888 ha una scheda ECM/EMM che mostra i tempi di decodifica in tempo reale per CAID. Quella colonna "msec" è su cui basi la tua regolazione del ritardo. Si aggiorna in tempo reale.

Per guardare il log grezzo:

tail -f /tmp/oscam.log | grep "ecm time"

Esegui questo comando mentre cambi canale e guardi i freeze. Il metodo di regolazione pratica: inizia alto (diciamo, 300 ms), osserva la lentezza nel cambiare canale, riduci di 50 ms ogni pochi minuti mentre monitori gli eventi di freeze. Quando i freeze riappaiono, aggiungi 75 ms come margine di sicurezza e considera il lavoro finito.

Configurazioni errate comuni e come risolverle

La maggior parte dei problemi di freeze che le persone attribuiscono al ritardatore sono in realtà qualcos'altro. Ecco cosa vedo costantemente.

Ritardo impostato globalmente quando solo un CAID ne ha bisogno

ImpostazioneRITARDO : 300 globalmente per risolvere un pacchetto di canali ostinato significa che ogni singolo cambio di canale richiede 300 ms in più. Se stai saltando attraverso un evento sportivo e cambiando 15 canali in 30 secondi, questo si traduce in un ritardo notevole.

Correzione: identifica il CAID che causa problemi (controlla il log ECM), imposta il ritardo elevato solo per quel CAID inoscam.dvbapi, e riporta il globale a 100 ms o meno.

Indice dell'adattatore/demux errato per box multi-tuner

Su un ricevitore dual-tuner — comune con Vu+ Duo2, Dreambox DM920, o simili — hai/dev/dvb/adapter0 e/dev/dvb/adapter1, ciascuno con il proprioca0 dispositivo. Se il tuo client DVBAPI sta scrivendo suadapter0/ca0 ma il tuner attivo èadapter1, avrai un completo fallimento di decrittazione indipendentemente dai valori di ritardo.

In OScam'soscam.dvbapi, imposti l'adattatore con:

BOXTYPE : dreambox

E verifica l'enumerazione dell'adattatore in/proc/bus/pci/ o tramitels /dev/dvb/. Alcune immagini numerano i tuner in modo diverso dopo un aggiornamento del kernel. Se la tua configurazione non è cambiata ma la decrittazione ha smesso di funzionare all'improvviso, controlla se gli indici degli adattatori sono cambiati.

Conflitti tra CCcam DVBAPI e un'istanza OScam parallela

Questo è sorprendentemente comune. Qualcuno installa OScam insieme a una configurazione CCcam in esecuzione senza disabilitare il DVBAPI integrato di CCcam. Entrambi cercano di aprire/dev/dvb/adapter0/ca0 simultaneamente. Il risultato è imprevedibile — a volte uno vince, a volte si scontrano, causando sempre instabilità.

Hai bisogno esattamente di un client DVBAPI attivo. Se stai usando OScam, disabilita DVBAPI in CCcam rimuovendo o commentando laDVBAPI : 1 riga (o equivalente) inCCcam.cfg. Se stai usando il DVBAPI nativo di CCcam, assicurati che OScam non sia configurato come client dvbapi.

Caching lato ricevitore che maschera il vero problema

Alcune immagini Enigma2 — in particolare le versioni più vecchie di OpenPLi — memorizzano brevemente l'ultima CW utilizzata. Questo può far sembrare che la decodifica stia funzionando quando in realtà sta servendo chiavi obsolete per un secondo o due prima di fallire. Il sintomo: nessun blocco alla prima visione, ma zapping veloce causa brevi schermi neri che si risolvono da soli.

Disabilita il caching CW se la tua immagine espone quell'opzione, o aggiorna a una versione attuale dell'immagine in cui questo è gestito meglio. OpenATV 7.x e OpenPLi 9.x sono entrambi più affidabili qui rispetto a qualsiasi cosa del 2022 o precedente.

Quando il Delayer Non Aiuta (e Cosa Fa)

Questa è la sezione che la maggior parte delle guide salta, e importa. Laconfigurazione del delayer dvbapi CCcam risolve esattamente una cosa: una corsa temporale tra la consegna del CW e la prontezza del demuxer. Non risolve problemi di rete, linee difettose o limitazioni hardware.

Congelamenti causati dalla latenza di rete, non dal timing

Se i tempi di andata e ritorno ECM nel log di OScam saltano tra 80 ms e 1200 ms in modo casuale, si tratta di instabilità di rete. Forse il peer di condivisione è sovraccarico. Forse la tua connessione internet ha perdita di pacchetti. Il delayer non ha nulla da contribuire qui — non puoi impostarlo abbastanza alto da coprire un picco di 1,2 secondi senza far sentire lo zapping rotto.

Diagnosi dei problemi di rete conping -i 0.2 [server-ip] in esecuzione mentre guardi la TV. Se vedi ping anomali che coincidono con eventi di congelamento, l'impostazione del delay è irrilevante. Risolvi la rete o trova una fonte di condivisione più stabile.

Problemi di periodo crittografico / cambio chiave vs problemi di delay

I congelamenti legati al timing seguono un modello: si verificano a intervalli prevedibili che corrispondono al periodo crittografico. Se noti un congelamento alle 10:01:10 e un altro alle 10:01:20 e un altro alle 10:01:30, si tratta di un periodo crittografico di 10 secondi e di un problema di delay. Risolvilo con il delayer.

Se i congelamenti sono alle 10:01:12, 10:04:47, 10:09:03 — nessun modello — non si tratta di un problema di timing del cambio chiave. Non regolare il delayer, indaga su qualcos'altro.

Limitazioni hardware del demux su ricevitori più vecchi

Alcuni ricevitori più vecchi — Dreambox 500s, unità AZBox di prima generazione, alcune scatole cinesi senza nome — hanno demuxer hardware che semplicemente non possono accettare CW forniti via software abbastanza velocemente, indipendentemente da come è impostato il delay. La finestra è troppo stretta, o l'hardware ha peculiarità che nessun delay software può compensare.

Su queste scatole, il congelamento è spesso di pochi fotogrammi piuttosto che uno schermo nero totale, e si verifica ad ogni singolo cambio chiave indipendentemente da ciò che imposti. Se questa è la tua situazione, l'hardware è il collo di bottiglia. Un moderno ricevitore Vu+, Gigablue o AX gestirà la stessa configurazione senza problemi.

Migrazione da CCcam DVBAPI a OScam per stabilità

Se stai utilizzando il DVBAPI nativo di CCcam e incontri ostacoli con le opzioni di configurazione, migrare a OScam come gestore del DVBAPI mantenendo CCcam come protocollo di condivisione è la mossa giusta. Il ponte è semplice a un livello alto: OScam si connette a CCcam come lettore tramite il protocollo newcamd o CCcam sulla porta 10000 (o su qualsiasi porta utilizzi il tuo server CCcam), quindi gestisce tutto il descrambling DVBAPI locale da solo.

Inoscam.server, il tuo lettore CCcam appare così:

[reader]

OScam gestisce quindi il lato DVBAPI con il suo pieno controllo del delay, targeting per CAID e l'interfaccia web per monitorare tutto. I problemi di congelamento che derivano dall'implementazione base del DVBAPI di CCcam di solito scompaiono immediatamente quando fai questo passaggio.