Focus SAT CCcam/OScam Setup: Configurazione& Risoluzione dei Problemi

Se stai eseguendo un server softcam e i tuoi canali focus sat continuano a mostrare uno schermo nero, bloccandosi ogni pochi secondi, o generando errori ECM nel log, il problema non è quasi certamente la tua antenna. Nove volte su dieci si tratta di un blocco lettore mal configurato, di un CAID non corrispondente, o di un timeout che sta soffocando CW validi o aspettando così a lungo che il canale è già in fase di congelamento prima che la chiave arrivi.

Questo articolo è per le persone che sono già nel mezzo della configurazione — hai una linea, hai un server in esecuzione e qualcosa di specifico è rotto. Il pacchetto focus sat si trova principalmente su Hot Bird 13E e Thor 0.8W/1W a seconda della tua regione, e la configurazione della crittografia ha alcune peculiarità che possono confondere anche le configurazioni esperte.

Inizia catturando il CAID live prima di toccare qualsiasi altra cosa. I valori statici che trovi pubblicati sui forum non sono affidabili — gli operatori li ruotano, e una configurazione precedentemente funzionante può smettere di funzionare silenziosamente durante la notte.

Identificazione del CAID e degli ID Provider di Focus SAT

Qui è dove la maggior parte delle persone salta avanti e poi trascorre ore a risolvere il problema sbagliato. Il CAID e l'ID provider sono la base — se li sbagli, nulla a valle funzionerà, indipendentemente da quanto sia pulito il tuooscam.server appare.

Lettura del CAID/provider dalla schermata delle informazioni del canale

Sintonizzati su un canale focus sat crittografato che sai dovrebbe decrittografare. Su la maggior parte delle immagini Enigma2, premi il pulsante Info due volte o tieni premuto a lungo per ottenere la vista dei dettagli tecnici. Vuoi la linea del sistema CA — mostrerà qualcosa come0B00:000000 o una coppia esadecimale simile. La prima metà è il CAID, la seconda è l'ID provider.

Su OpenPLi e OpenATV, la schermata delle informazioni estese (di solito accessibile tramite il pulsante blu> Segnale) elencherà i descrittori CA attivi nel PMT. Su immagini Vuplus che eseguono Black Hole, gli stessi dati si trovano sotto Menu> Informazioni> Stato di Sintonizzazione. Il percorso esatto varia a seconda della skin, ma ogni immagine moderna di Enigma2 espone questo da qualche parte.

Annota i valori esadecimali esatti. Non presumere. L'ID provider in particolare varia tra i trasponder che trasportano lo stesso pacchetto, e sbagliarlo è la causa più comune di un canale che appare FTA ma congelato.

Conferma il CAID con OScam webif (Lettore> Diritti)

Se hai l'OScam webif in esecuzione (porta predefinita 8888), vai su Lettori e fai clic sul tuo lettore attivo. La scheda Diritti mostra cosa espone effettivamente la scheda o la linea. Incrocia queste informazioni con ciò che ha riportato il ricevitore.

Lo strumento diagnostico più utile è il log live. Cerca nel log di OScam l'attività ECM su quel canale:

grep -i ecm /var/log/oscam/oscam.log | tail -50

O se stai eseguendo oscam con il log che va a stdout attraverso il tuo sistema di init:

journalctl -u oscam -f | grep -i "ecm\|caid\|reader"

Ogni riga ECM ti dà il triplet CAID:provid:srvid completo — per esempio0B00:004A01:1234. L'ID servizio (srvid) è specifico per il canale. Il provid è ciò di cui hai bisogno nel campoident del tuo lettore.

Perché il CAID sbagliato fa apparire i canali FTA-ma-congelati

Ecco uno scenario che inganna le persone: il canale ha un componente non crittografato (come una finestra di anteprima gratuita o una frequenza di trasponder diversa che trasporta lo stesso servizio FTA). Il ricevitore si blocca su di esso, il canale sembra riprodursi, e poi si congela o pixelizza perché il flusso principale è effettivamente crittografato e nessun CW sta arrivando.

Guarda anche i canali che sono FTA su un trasponder e crittografati su un altro che trasporta lo stesso ID servizio. Se la tua scansione ha rilevato prima la versione FTA, il ricevitore potrebbe indirizzare le richieste ECM all'entrata sbagliata nella sua lista di canali. Eliminare e riscanalizzare solo il trasponder crittografato di solito risolve questo problema.

Se il log di OScam mostra la richiesta ECM in arrivo ma non trova lettori corrispondenti, o mostra il lettore che la rifiuta, si tratta di un mismatch di CAID o ident — non di un problema di rete.

Configurazione del Lettore OScam e ECM

I file di configurazione di OScam si trovano in luoghi diversi a seconda della tua immagine. Su OpenPLi è tipicamente/etc/tuxbox/config/oscam/. Nelle immagini che utilizzano il layout tuxbox potrebbe essere/var/config/oscam/. In alcune versioni di OpenATV lo troverai sotto/etc/oscam/. Controlla dove punta la tua istanza in esecuzione con:

ps aux | grep oscam

Il-c argomento nella riga del processo ti indica la directory di configurazione.

blocco lettore oscam.server: caid, ident, gruppo

Ecco un blocco lettore di partenza pulito per una condivisione di protocollo remoto — questo copre newcamd ecccam lettori, regola la riga del protocollo secondo necessità:

[reader]

Ilident riga è quella che la maggior parte delle configurazioni sbaglia. Ha bisogno del prefisso CAID seguito da due punti e dall'ID del fornitore che hai catturato dal log live. Se il fornitore ha più ID attivi, elencali separati da virgole:ident = 0B00:004A01,004A02.

Ilgroup valore deve corrispondere al gruppo assegnato all'utente in oscam.user — quella discrepanza di gruppo è l'altra causa principale delle voci "nessun lettore corrispondente" che le persone inseguono per ore.

oscam.user con binding au e gruppo

Il tuo account utente inoscam.user ha bisogno dello stesso numero di gruppo e del giusto ambito CAID:

[account]

Se hai più lettori in gruppi diversi, l'utente deve essere nel gruppo che contiene il lettore che trasporta questo pacchetto. Se il lettore è nel gruppo 1 e l'utente è nel gruppo 2, OScam registrerà l'ECM come in arrivo ma non avrà dove instradarlo. L'entrata del log appare come "nessun lettore corrispondente" o "rifiutato" — non un fallimento di autenticazione, solo un errore di instradamento.

Impostare il timeout ECM e il comportamento di ripetizione lb_ in oscam.conf

Aprioscam.conf e trova il[global] sezione. I valori chiave:

[global]

Illb_mode = 1 abilita il bilanciamento del carico in base al tempo di risposta ECM. Questo è ciò che desideri quando hai più lettori — preferirà quello più veloce. Ma impostarelb_nbest_percaid troppo alto (3 o 4) inizia a interrogare lettori lenti o morti inutilmente, il che aumenta effettivamente la frequenza di congelamento durante i picchi di carico. Inizia con 1 e aumentalo solo se hai lettori ridondanti confermati funzionanti.

lb_retrylimit in millisecondi indica a OScam quando considerare un lettore troppo lento e provare un altro. 800ms è ragionevole per un lettore locale a bassa latenza. Per i peer remoti con RTT variabile, spingilo a 1200–1500ms. Impostarlo a 200ms su un lettore remoto causerà tentativi costanti e timeout.

L'override per CAIDlb_retrylimits = 0B00:1200 ti consente di ottimizzare specificamente per questo pacchetto senza influenzare altri.

Gestione della cache e CW per un output stabile

La cache CW di OScam (cwcache) può effettivamente causare una specifica classe di freeze: il ricevitore riceve un CW valido, funziona bene, cambi canale e torni, e rimane nero per alcuni secondi. Questa è la cache che serve un CW obsoleto dalla sessione precedente sullo stesso SRVID. La chiave crittografica è cambiata ma la cache non è scaduta.

Se stai vedendo questo schema specificamente sui cambi di canale, aggiungi aoscam.conf:

[cache]

Una durata della cache di 15 secondi è solitamente sicura per periodi di rotazione CW standard di 10 secondi. Andare oltre rischia di servire chiavi obsolete.

Configurazione CCcam e priorità delle linee

Se stai usando CCcam piuttosto che OScam come tuo softcam principale, la configurazione si trova in/etc/CCcam.cfg. La sintassi è diversa ma i concetti sono gli stessi: devi dire a CCcam quale CAID instradare attraverso quale connessione e devi controllare il comportamento dei salti.

Nozioni di base sulla C-line e F-line di CCcam.cfg

Una C-line è la tua connessione client in uscita a un server di condivisione. Un F-line è un peer in arrivo che è autorizzato a connettersi a te. Per decodificare il pacchetto hai bisogno di una C-line:

# Connetti a un server di condivisione

La porta 12000 è il valore predefinito di CCcam e la maggior parte dei server lo utilizza. Se ti connetti a unnewcamd server invece, usa un N-line con porta 15050 (anch'essa un valore predefinito comune). Verifica che la tua linea sia effettivamente connessa accedendo alla pagina delle informazioni di CCcam — tipicamente ahttp://receiver-ip:16001 — e controllando la sezione Server Connessi. Verde significa connesso, rosso significa che il handshake è fallito.

Utilizzo della priorità CAID/ident e delle linee di ignoranza

CCcam ha direttive P: (priorità) e I: (ignora) che indirizzano l'instradamento per CAID specifici. Se hai più C-line e una è chiaramente migliore per questo pacchetto, usa:

# Dai priorità a questo server per CAID 0B00

Senza queste direttive, CCcam fa round-robin tra i server connessi e otterrai tempi di decodifica incoerenti. Durante le ore di punta, quando un server degrada, questo causa freeze intermittenti che sembrano casuali ma sono in realtà legati al carico.

Forzare un salto lettore specifico per il pacchetto

Il conteggio dei salti è molto importante per l'affidabilità della decodifica. Un lettore hop-1 significa che la scheda è direttamente connessa al server con cui stai parlando. Hop-2 significa un relay tra te e la scheda. Nei miei test, hop-1 e hop-2 sono generalmente buoni per una decodifica stabile. Hop-3 e superiori introducono una variazione di latenza che si manifesta come freeze durante una rapida rotazione ECM.

CCcam espone le informazioni sui salti nella sua pagina di stato. Sotto Schede Connesse, vedrai il conteggio dei salti per ciascuna voce CAID. Se il pacchetto mostra hop-4 o superiore, quel server non sta ottenendo la sua scheda direttamente — sta facendo relay attraverso più nodi. Trova una fonte migliore o accetta l'instabilità.

Puoi anche limitare quali salti CCcam utilizzerà:

ALLOW SIDMAPPING = no

IlIGNORE RESHARE DISTANCE impostazione dice a CCcam di rifiutare i CW che arrivano da più di N salti di distanza. Impostarlo a 2 filtra i rifiuti ad alto salto a costo di ridurre le tue opzioni di fallback.

Risoluzione dei problemi di freeze, schermi neri ed errori ECM

Prima di incolpare il softcam, escludi sempre prima il segnale. Sintonizzati su un canale free-to-air sullo stesso trasponder. Se anche quello sta pixelando o cadendo, il tuo problema è LNB/piatto, non configurazione. Inizia a fare debug del softcam solo dopo aver confermato che il trasponder è bloccato e i canali FTA sono puliti.

Lettura dei tempi di risposta ECM nel log

OScam registra i tempi di risposta ECM in millisecondi su ciascuna linea CW. Una decodifica sana appare così:

2026/06/03 21:14:02 c [SRVID 1234] ECM ha risposto (0B00/004A01) da focus_peer1 (220ms)

Sotto 400ms è solido. 400–1000ms è marginale ma di solito va bene per una rotazione CW di 10 secondi. Qualsiasi cosa che colpisce ripetutamente 3000ms+ significa che il lettore sta lottando. Se vedi 9000ms seguito da un timeout, il lettore ha rinunciato — quello è il tuo freeze proprio lì.

Il modello da tenere d'occhio è CW trovato ma in arrivo in ritardo. Il canale sembra funzionare, poi si blocca ogni volta che la chiave ruota. OScam ha trovato il CW, ma ci sono voluti 2800ms su una finestra di 2500ms. La soluzione è o una fonte di lettore più veloce o un ecmtimeout più alto per dare più tempo ai lettori lenti.

Correzione delle voci ricorrenti 'nessun lettore corrispondente' / 'rifiutato'

Se il log mostra costantemente "nessun lettore corrispondente" per una specifica coppia CAID:provid, procedi in questo ordine:

1. Controlla che il blocco del lettore in oscam.server abbia il correttocaid eident valori che corrispondono a quelli che hai catturato dal vivo
2. Verifica che ilgruppo del lettore corrisponda algruppo dell'utente in oscam.user
3. Conferma che il lettore sia effettivamente connesso — controlla la pagina Readers dell'interfaccia web per lo stato "connesso"
4. Se utilizzi cacheex, controlla se la cache sta servendo un rifiuto da un tentativo fallito precedente

"Rifiutato" è diverso — di solito significa che il lettore si è connesso ma la scheda o il server hanno attivamente rifiutato l'ECM. Questo accade quando stai inviando richieste ECM per un CAID che il server non gestisce, o quando il filtro ident dall'altra parte sta bloccando la tua richiesta.

Problemi di rete e MTU su peer remoti

Questo è facile da perdere. Se i tuoi freeze si verificano specificamente su flussi HD e specificamente su peer remoti (non lettori di rete locale), la frammentazione MTU è un forte candidato. I flussi HD hanno payload ECM più grandi, e un collegamento remoto con MTU impostato a 1500 ma che passa attraverso PPPoE o un tunnel VPN con MTU effettivo più basso frammenterà quei pacchetti. I pacchetti CW frammentati spesso arrivano incompleti, attivando un timeout.

Testalo:ping -M do -s 1472 your.peer.server. Se vedi errori "frammentazione necessaria", riduci il tuo MTU. Su Linux, impostalo sull'interfaccia:

ip link set eth0 mtu 1400

Oppure impostalo permanentemente nella tua configurazione di rete. 1400 offre abbastanza margine per la maggior parte dell'overhead del tunnel. Dopo aver cambiato, riavvia oscam e osserva se i freeze solo HD si risolvono.

Distinguere problemi di segnale/LNB da problemi di softcam

Un rapido albero decisionale:

• I canali FTA sullo stesso trasponder si bloccano → problema di segnale/LNB. Fermati qui, ripara la tua antenna.
• FTA bene, i canali criptati schermo nero immediatamente → softcam non si connette, probabile mismatch CAID o lettore non connesso.
• Funziona per 10–30 secondi poi si blocca → timeout di rotazione CW. L'ECM è lento o fallisce nella rotazione della chiave.
• Si blocca solo durante l'ora di punta → server sorgente sovraccarico. Fuori picco va bene. Controlla i tempi ECM durante entrambi i periodi.
• Funziona dopo il riavvio, si interrompe dopo il cambio di canale → cache CW obsoleta. Vedi la correzione cwcachetime sopra.

La cache ECM del ricevitore può anche mascherare temporaneamente i problemi. Alcuni STB memorizzano l'ultima CW valida per alcuni secondi dopo la scadenza. Questo fa sembrare una configurazione rotta funzionare subito dopo un riavvio, poi fallire 10–15 secondi dopo una volta che la chiave memorizzata scade e un nuovo ECM è necessario.

Scegliere una fonte di condivisione affidabile (Criteri generali)

Quando stai valutando qualsiasi fonte per il pacchetto focus sat — o qualsiasi pacchetto — gli indicatori tecnici contano più di ogni altra cosa. Una risposta ECM veloce alle 2 del mattino non significa nulla se il server si blocca alle 20 quando metà dei suoi abbonati è online contemporaneamente.

Indicatori di uptime e stabilità da testare

Esegui il tuo lettore OScam per almeno 24 ore prima di concludere che una sorgente è stabile. Osserva i tempi di risposta ECM in queste finestre specifiche: 7–9am, 12–2pm, 6–10pm. La finestra serale è dove le sorgenti sovraccariche mostrano le loro reali prestazioni. Se vedi i tempi ECM saltare da 180ms in ore non di punta a 2400ms durante le ore di punta, quella sorgente ti darà dei freeze quando conta di più.

OScam registra tutto. Dopo un giorno di funzionamento, esegui:

grep "focus_peer1" /var/log/oscam/oscam.log | grep -v "not found" | awk '{print $NF}' | sort -n

Questo ti dà una distribuzione approssimativa dei tempi di risposta per quel lettore. Se il 95° percentile è sotto 800ms, sei messo bene. Se è sopra 2000ms, aspettati dei freeze.

Conteggio dei salti e ragionamento su schede locali vs remote

Una sorgente con accesso diretto alla scheda (hop-1 in termini CCcam) supererà sempre una catena di ridistribuzione sotto carico. Il motivo è semplice: ogni salto aggiunge la propria latenza di elaborazione e introduce un altro potenziale punto di guasto. Durante la domanda di picco, una catena hop-3 potrebbe dover attendere due nodi intermedi per elaborare prima che il tuo CW arrivi.

Se hai l'opzione, una sorgente in cui l'operatore tiene fisicamente la scheda e il server è collocato con essa supererà costantemente una ridistribuzione. Il RTT dal tuo ricevitore alla scheda è ciò che guida il tempo ECM, e ogni salto nella catena si aggiunge a quello.

Un setup legittimo significa che tu o la tua sorgente avete diritto alla scheda condivisa. Tieni presente questo quando valuti le opzioni: utilizzare una scheda a cui non hai diritto è sia un rischio legale che tecnico, poiché gli operatori possono rilevare schemi di condivisione e invalidare la scheda senza preavviso.

Segnali di allerta che prevedono freeze

Allontanati da qualsiasi sorgente che mostri questi:

• Tempi di risposta ECM che variano in modo selvaggio — 150ms un minuto, 4000ms il successivo — indicano una connessione sovraccarica o instabile
• Conteggio dei salti di 3 o superiore nello stato CCcam
• Riconnessioni frequenti visibili nel log di OScam (più di una volta all'ora in condizioni normali)
• Nessuna risposta alla specifica combinazione CAID/provid di cui hai bisogno — il server sta ridistribuendo schede che non coprono il tuo pacchetto
• Prestazioni stabili per un'ora e poi degradanti — suggerisce un limite di banda o un throttling della sessione in azione

E un caso limite da conoscere: gli operatori ruotano periodicamente gli ID provider per i pacchetti focus sat e altri su Hot Bird. Se una configurazione che ha funzionato bene per mesi inizia improvvisamente a registrare "no matching reader" senza cambiamenti da parte tua, controlla di nuovo i valori CAID/provid live. La tua linea ident potrebbe ora puntare a un ID provider obsoleto che l'operatore ha ritirato.