Guida alla Risoluzione dei Problemi per MgCamd Share Non Apre (OSCam/CCcam)

Se sei atterrato qui cercandomgcamd: share not opening решение, sai già l'inferno specifico di vedere uno stato di connessione verde mentre i tuoi canali rimangono completamente neri. La linea sembra connessa. MgCamd non si sta bloccando. Ma nulla viene decifrato. Questa guida affronta le cause reali in ordine di probabilità — partendo dalla tua configurazione locale e finendo al server.

Questa non è una guida "incolla questo modello". Ogni sezione qui sotto presuppone che tu abbia già MgCamd in esecuzione e le credenziali a portata di mano — semplicemente non riesci a ottenere una parola chiave dalla scheda.

Cosa Significa Davvero 'Share Not Opening' in MgCamd

La frase "share not opening" descrive uno stato di errore specifico che è completamente diverso da un errore di accesso. MgCamd si autentica con successo al server newcamd — utente, password, porta tutto corretto — ma quando il tuo box si sintonizza su un canale e invia un ECM (Entitlement Check Message), nessuna parola chiave di controllo decrittata (dcw) torna indietro. Il canale è criptato. Il ciclo di decodifica non inizia mai. Schermo nero.

La maggior parte delle guide confonde "impossibile connettersi" con "share not opening" ed è per questo che sono inutili per questo problema.

Connessione attiva vs. decodifica fallita — due problemi diversi

Un errore di accesso appare come una linea che cade immediatamente o non mostra mai come connessa. MgCamd registrerà qualcosa comeaccesso fallito o tenterà semplicemente di riconnettersi ripetutamente. Vedrai la connessione rimbalzare in/var/log/mgcamd.log o ovunque la tua immagine lo scriva.

Un errore di decodifica è più silenzioso. La linea appare attiva. MgCamd si considera connesso. Ma l'ECM che il tuo box invia rimane senza risposta. Il canale non si apre mai perché nessuno sta restituendo una CW valida per il periodo di crittografia attuale — che ruota ogni 10 secondi nella maggior parte dei sistemi.

Leggere il log di MgCamd: richieste ECM, risposte e marcatori di timeout

Prima cosa: aumenta la verbosità. In/var/keys/mg_cfg, trova la riga di debug e impostala a livello 3:

G: { 03 }

Con questo abilitato, una decodifica sana appare così nel log:

[mgcamd] ecm per caid 0x0500 pid 0x0136 provider 0x032820

Una rotta appare così:

[mgcamd] ecm per caid 0x0500 pid 0x0136 provider 0x032820

O peggio, non ottieni nemmeno una richiesta ECM registrata — il che significa che MgCamd non sta nemmeno instradando il CAID del canale a quella linea. Problema diverso, stesso schermo nero.

Flusso del protocollo Newcamd: accesso OK ma nessun dcw

Il handshake newcamd ha due fasi. Fase uno: connessione TCP, scambio di chiavi DES, autenticazione utente/password. Fase due: traffico ECM/dcw effettivo. Puoi completare completamente la fase uno e ancora fallire la fase due. Una chiave DES errata è l'esempio classico — l'handshake a volte si completa in uno stato degradato che mostra "connesso" ma non produce nulla. Una scheda scaduta sul server è un'altra: l'accesso funziona bene, il controllo dei diritti restituisce vuoto.

Passo 1: Verifica la Linea Newcamd e la Chiave DES

Apri/var/keys/newcamd.list e guarda la tua linea CWS. Il formato è:

CWS = hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

L'ultimo blocco è la chiave DES. Deve essere esattamente di 14 byte — scritta come 14 coppie esadecimali separate da spazi. Alcune configurazioni la scrivono senza spazi come una stringa esadecimale di 28 caratteri. Entrambi i formati esistono; sappi quale si aspetta la tua immagine.

Sintassi di newcamd.list: CWS = host port user pass DES-key

Una linea funzionante completa appare così:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Dopo la chiave DES puoi opzionalmente fissare un CAID e un ID provider:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14 0500 032820

Se sbagli quel CAID/ident, nulla per quel provider verrà mai decifrato su questa linea, anche se il server ha la scheda.

Il trap della chiave DES di 14 byte (28 caratteri esadecimali)

Questa è la causa più comune del problema connesso-ma-nero. Qualcuno copia una chiave DES con uno spazio finale, perde un carattere o la incolla da un PDF che ha sostituito uno zero con la lettera O. La chiave sembra a posto a prima vista. MgCamd si connette. Nulla viene decifrato.

Conta i tuoi caratteri. Se la chiave è scritta come coppie separate da spazi: conta 14 coppie. Se è una stringa esadecimale continua: conta esattamente 28 caratteri. Non 27. Non 29. 28.

Fai attenzione anche alle incoerenze tra minuscole e maiuscole. Il protocollo newcamd è insensibile al maiuscolo per l'esadecimale, ma alcune versioni di MgCamd sono note per comportarsi male con chiavi a maiuscole miste. Normalizza a maiuscole se stai inseguendo un fantasma.

Testare la raggiungibilità: telnet/nc alla porta newcamd

Prima di incolpare la configurazione, conferma che la connessione TCP funzioni effettivamente dal tuo dispositivo:

nc -zv myserver.example.com 17000

Vuoi vedereConnessione a myserver.example.com 17000 porta [tcp/*] riuscita!. Se scade o rifiuta, non stai nemmeno raggiungendo il server — MgCamd che mostra "connesso" mentre questo fallisce significa che c'è uno stato memorizzato/caduto, che si cancella al riavvio.

Numeri di porta comuni e controlli firewall/NAT

Le porte Newcamd variano a seconda della configurazione del server, ma comunemente vanno da 10000 a 20000. Alcuni operatori usano 17000, 15000 o intervalli personalizzati. Se sei dietro CGNAT o doppio NAT (comune con internet mobile o alcuni ISP), la connessione TCP dal tuo dispositivo potrebbe apparire stabilita localmente ma il server non vede mai un socket reale. Lo stato "connesso" in MgCamd si basa sul completamento dell'handshake TCP locale — non prova che il socket lato server sia funzionale.

Testa da una rete diversa se sospetti problemi di NAT. Verifica anche che nessun firewall sul tuo router stia silenziosamente bloccando l'uscita su quella porta.

Passo 2: Controlla CAID, Provider e Routing ECM PID

Anche con un perfect newcamd.list, gli ECM possono comunque andare da nessuna parte se MgCamd li sta instradando sulla linea sbagliata o il lettore del server non gestisce quel CAID. Questa è la seconda causa più comune dimgcamd: share not opening решение problemi — ed è quasi sempre invisibile senza logging dettagliato.

Limitare una linea al corretto CAID/ident

In/var/keys/mg_cfg, ilC: blocco definisce quali CAID gestisce ciascuna linea. Un esempio:

C: ( 0500 )

La seconda forma fissa a un identificatore specifico del provider all'interno del CAID. Se il tuo server gestisce solo l'identificatore 032820 ma invii ECM per l'identificatore 040810, quelle richieste non restituiscono nulla. Abbina l'identificatore a ciò che il server ha effettivamente — chiedi all'operatore se non lo sai, o controlla OSCam webif.

Quando il CAID del canale non è sul lettore

Alcanali trasmettono più CAID sullo stesso trasponder. Il tuo dispositivo potrebbe selezionare il CAID 0x0100 (Seca) mentre il server ha solo 0x0500 (Viaccess). La soluzione è costringere il tuo dispositivo a utilizzare il CAID che il server gestisce, oppure configurare la lista di priorità di MgCamd per preferire quello corretto. In mg_cfg, ilP: le righe impostano l'ordine di priorità per i CAID quando sono disponibili più opzioni.

ECM PID e trasponder multipli-CAID

Questo caso limite colpisce frequentemente le persone. Un trasponder trasmette un canale crittografato con due diversi sistemi CA — diciamo Nagravision su PID 0x0600 e Irdeto su PID 0x0601. Il tuo ricevitore potrebbe bloccarsi sul PID Irdeto perché è elencato per primo nel PMT. MgCamd invia l'ECM alla tua linea Irdeto, che non ha scheda. Nel frattempo, la tua linea Nagravision rimane inattiva con una scheda perfettamente valida che la decifrerà immediatamente.

Costringi l'ECM PID nelle impostazioni del canale del tuo ricevitore se la tua immagine lo supporta, oppure configura MgCamd per instradare quel CAID specifico esclusivamente sulla linea corretta.

Liste di priorità e di ignoranza (voci mg_cfg C:/P:)

LeI: (ignore) righe in mg_cfg sono l'inverso diC: — dicono a MgCamd di non inviare mai un CAID/ident specifico a una particolare linea. Usa questi quando hai più linee e vuoi impedire a una linea debole di intercettare ECM che non può rispondere:

I: ( 0500:040810 )

Combinato con voci di priorità esplicite,P: puoi instradare ogni CAID/ident a esattamente una linea ed eliminare le condizioni di gara tra più voci CWS.

Passo 3: Diagnosi dal lato server (OSCam/CCcam)

A questo punto, se la tua configurazione sembra corretta, il problema potrebbe non essere affatto nella tua box. Ottenere visibilità dal lato server è ciò che separa una correzione di 20 minuti da una sessione di debug di 3 ore.

Server newcamd OSCam: [newcamd] chiave, porta e blocco utente

Se il server esegue OSCam, controlla/etc/oscam/oscam.conf e/etc/oscam/oscam.server. L'ascoltatore newcamd ha bisogno di una sezione dedicata inoscam.conf:

[newcamd]

Lachiave = qui deve corrispondere esattamente alla chiave DES nel tuonewcamd.list. L'associazione della porta opzionalmente aggiunge@CAID:ident per limitare ciò che questo ascoltatore serve. Se il CAID/ident nella tua box non corrisponde, OSCam potrebbe accettare l'ECM e scartarlo immediatamente.

Gli account utente si trovano in/etc/oscam/oscam.user. Conferma che il tuo nome utente abbia il corretto CAID e ident nei campicaid = eident = e chedisabilitato = 0 .

Stato webif OSCam: lettore, ecm e 'non trovato' vs 'timeout'

L'interfaccia web di OSCam (comunemente accessibile sulla porta 8888 o 8383) è lo strumento diagnostico più utile che hai. Sotto la scheda della cronologia ECM, vedrai uno dei tre risultati per le richieste ECM in arrivo:

• trovato — la scheda l'ha decifrata, un CW valido è tornato a MgCamd. Se la tua box è ancora nera, il difetto è locale.
• non trovato — OSCam ha ricevuto l'ECM ma nessun lettore ha potuto rispondere. Scheda mancante, CAID errato o nessun diritto.
• timeout — OSCam ha inoltrato l'ECM a monte ma non ha ricevuto risposta entro il timeout configurato. Problema di salto a monte.

Questa suddivisione in tre vie localizza il difetto con precisione. "Trovato ma nero" è un problema locale di PID/cam. "Non trovato" è un problema di scheda/diritto. "Timeout" è un problema della catena a monte.

CCcam nuova esportazione newcamd e condivisione visibilità

Per i server CCcam, controlla/etc/CCcam.cfg. La sezione di esportazione newcamd necessita di unPORTA DI ASCOLTO NEWCAMD: voce e corrispondentiN: host porta nome utente password chiave-DES definizioni client — o l'equivalente lato server per le condivisioni in uscita. Nelle pagine info di CCcam (di solito porta 16001), verifica che la scheda che ti aspetti sia effettivamente nella lista delle condivisioni e contrassegnata come disponibile localmente, non solo come una condivisione remota da un altro hop che potrebbe essere giù.

Disponibilità della scheda, AU e controlli dei diritti

Una configurazione tecnicamente perfetta può comunque produrre "condivisione non aperta" se la scheda stessa non ha diritti validi. Le schede scadono. I fornitori ruotano le chiavi con aggiornamenti EMM. Se AU (Aggiornamento Automatico) non funziona — la scheda deve essere fisicamente in un lettore collegato a un server che sta ricevendo attivamente EMM — i diritti diventano obsoleti e la decodifica si ferma anche se la scheda è presente e OSCam la mostra come attiva.

Su OSCam, controlla lo stato del lettore in webif: guarda la lista dei diritti e l'ultimo timestamp EMM. Una scheda che non ha ricevuto un EMM da giorni è sospetta.

Passo 4: Correggi i limiti di temporizzazione, cache e tasso ECM

Se la configurazione è corretta e la scheda ha diritti, ma continui a riscontrare schermi neri intermittenti o congelamenti dopo pochi secondi, il problema è legato alla temporizzazione. Questo copre la categoria più difficile dimgcamd: condivisione non aperta soluzione problemi perché sembrano diversi ogni volta.

Regolazione del timeout ECM in mg_cfg (M: / T: valori)

Il timeout di MgCamd per attendere una risposta dcw è controllato dalM: (tempo massimo ecm) valore in mg_cfg, spesso espresso in unità di 100ms. Un'impostazione come:

M: { 3 }

Significa che MgCamd attende 300ms prima di rinunciare a una risposta CW. Per un server a due hop di distanza con un po' di latenza, è stretto. Aumentalo a 6 o 8 (600–800ms) e testa. Andare troppo in alto crea un problema diverso — potresti perdere un periodo di rotazione CW e ottenere un congelamento invece di un'immagine fluida. Bilancialo in base alla tua latenza effettiva del server.

Il modello di congelamento dopo pochi secondi si verifica specificamente quando si verifica la rotazione CW (circa ogni 10 secondi) e il nuovo CW non arriva in tempo. Il CW precedente scade, l'immagine si congela e, a seconda della tua box, potrebbe o meno recuperare. Un controllo di temporizzazione più stretto sul lato server, o l'uso della cache CW di OSCamd, può smussare questo.

cache-ex / cache peer che causano CW obsoleti

La funzione cache-ex di OSCam consente a più istanze di OSCam di condividere CW decodificati. Questo è normalmente un vantaggio in termini di prestazioni — un CW che è stato appena decodificato da un server viene servito istantaneamente al successivo richiedente. Ma un peer di cache mal configurato può servire un CW obsoleto dal periodo crittografico precedente. La tua box riceve un CW che sembra valido, lo applica e l'immagine è spazzatura o congelata perché la crittografia è già ruotata.

Se stai vedendo un'immagine breve (1–2 secondi poi congelamento), disabilita temporaneamente cache-ex e vedi se si stabilizza. Se lo fa, il peer di cache sta restituendo dati errati.

Limitazione del tasso ECM e throttling 'troppi ecm'

I server sotto carico spesso implementano la limitazione del tasso ECM per account utente. Se la tua box sta inviando ECM troppo rapidamente (cambiando canale, cattiva analisi PMT che invia richieste duplicate), il server inizierà a scartare le richieste. Nei log di OSCam questo si mostra cometroppi ecm o semplicemente silenzio — l'ECM viene ricevuto e scartato senza risposta.

Gli schermi neri solo durante le ore di punta sono quasi sempre questo. Il lettore del server è sopraffatto. Non c'è molto che tu possa fare lato client se non ridurre il traffico ECM non necessario — non scansionare i canali rapidamente, assicurati che la tua box non stia inviando ECM duplicati per lo stesso PID e aspetta il periodo di punta.

Interferenza da un secondo cam (priorità softcam)

Questo è sottile e causa genuinamente lo scenario "funzionava ieri, rotto oggi". Se un secondo softcam è stato installato o abilitato — o se la tua immagine ha un decoder integrato che si attiva su determinati CAID — può afferrare l'ECM prima che MgCamd lo riceva. Il cam integrato non riesce a decodificare (nessuna scheda), non restituisce nulla e MgCamd non vede mai la richiesta perché l'ECM è stato consumato a monte.

Controlla le impostazioni di priorità cam della tua immagine e assicurati che MgCamd abbia la massima priorità per i CAID che stai condividendo. Disabilita completamente i cam concorrenti per quei CAID se la tua immagine lo supporta. Il sintomo è: il log ECM in MgCamd non mostra richieste per un canale che dovrebbe richiederle.

Affrontare questi passaggi in modo sistematico è l'unico percorso affidabile quando si affrontanomgcamd: condivisione non aperta soluzione errori — non c'è una soluzione unica perché il guasto può trovarsi in sei posti diversi. Inizia a livello locale (chiave DES, instradamento CAID), passa alla verifica lato server (interfaccia web OSCam, condivisioni CCcam), poi indaga su tempistiche e interferenze. La divisione "trovato / non trovato / timeout" di OSCam è lo strumento diagnostico più potente disponibile e la maggior parte delle persone non lo usa mai.