Revisión de Solución de Problemas de CCcam: Soluciona los Congelamientos& Errores FBL

Si estás ejecutando una configuración de CCcam u OScam y la imagen se sigue congelando, esta revisión de solución de problemas de cccam te va a ahorrar mucho tiempo. El congelamiento no es un solo problema — es un síntoma con unas cinco causas raíz diferentes, y la mayoría de la gente pasa horas reiniciando su equipo en lugar de leer la única línea del log que les habría dicho exactamente qué está mal. He administrado servidores de share de forma intermitente durante años, y el proceso de diagnóstico de abajo es el mismo que uso cada vez que una línea falla.

Así que antes de tocar CCcam.cfg u oscam.server, establezcamos qué te está diciendo realmente el log. Esa es la parte que toda otra revisión de solución de problemas de cccam se salta.

Cómo Leer un Congelamiento de CCcam Antes de Tocar la Configuración

El congelamiento no es un diagnóstico. Es un síntoma. El equipo se congeló porque algo en la cadena de ECM tardó demasiado o falló por completo — pero el "congelamiento" por sí solo no te dice nada sobre si el fallo está en tu configuración, tu red, la tarjeta de tu peer, o una línea muerta. Primero tienes que revisar el log.

Congelamiento vs. pantalla negra vs. imagen distorsionada — tres fallos diferentes

Estos se agrupan constantemente y no deberían. Un congelamiento significa que se solicitó un ECM (Entitlement Control Message, Mensaje de Control de Derechos) y eventualmente llegó, pero tarde — el decodificador se quedó sin control word válido antes de que llegara el nuevo, así que mantiene el último cuadro. Una pantalla negra normalmente significa que no llegó ninguna respuesta de ECM, o que el CAID solicitado no está siendo servido por nada en tu lista de tarjetas. Una imagen distorsionada — ruido visible, no un cuadro congelado — normalmente significa que recibiste un DCW (control word) de vuelta, pero es el incorrecto, lo cual apunta a una discrepancia de CAID/proveedor o a una clave corrupta.

Si te equivocas en esta distinción, vas a pasar un fin de semana ajustando los límites de saltos (hop limits) cuando el problema real es tu cable LNB.

Habilitar el registro detallado: debug 4 y la ruta del log de CCcam

Tu configuración de CCcam se encuentra en/etc/CCcam.cfg (o/usr/keys/CCcam.cfg en algunas imágenes de enigma2). Para obtener una salida de diagnóstico útil, configura:

DEBUG : 4

El nivel de debug 4 te da el registro completo de solicitud/respuesta de ECM, no solo eventos de conexión. Sin él verás mensajes de conexión/desconexión de peers, pero nada sobre la entrega real de claves — lo cual es inútil para el diagnóstico de congelamientos.

En OScam, el equivalente se encuentra en/etc/oscam/oscam.conf bajo el bloque[global] :

logfile = /var/log/oscam.log

Si estás ejecutando el webif (normalmente en el puerto 8888 o el que hayas configurado bajo[webif]), la página de estado del reader te da los mismos datos de tiempos de ECM en una tabla mucho más legible — ahora reviso eso antes de siquiera hacer un tail a un archivo de log en bruto.

Leer los tiempos de respuesta de ECM en el log (cómo se ve lo 'bueno')

Una línea de registro CCcam saludable se ve más o menos así:

[03:14:22] ECM (0100:000000) from (CCcam) client PeerName, cw: 142 ms

Esos 142 ms son tu tiempo de respuesta ECM — el intervalo entre el envío de la solicitud y la llegada de la control word. Cualquier valor por debajo de aproximadamente 250-300 ms es cómodo. Entre 300-800 ms empezarás a ver micro-cortes ocasionales en canales con crypto-periodos cortos. Por encima de 800 ms, de forma constante, verás congelamiento visible — el decodificador simplemente se queda sin clave válida antes de que llegue la siguiente. Si el crypto-periodo de un canal es de 8-10 segundos y tu tiempo ECM supera eso, tendrás un congelamiento duro en cada ciclo, como un reloj.

Esta es la habilidad más útil en cualquier revisión de solución de problemas de cccam: correlacionar la marca de tiempo del congelamiento en tu TV con la línea ECM de ese mismo segundo en el registro. Nueve de cada diez veces el valor en ms te lo dice todo.

Mapeando el congelamiento a un CAID/provider ID

Cada línea ECM incluye un par CAID:providerID — en el ejemplo anterior,0100:000000. Anota qué combinaciones de CAID/provider se congelan y cuáles no. Si siempre es el mismo CAID (digamos, 0100 para Cryptoworks o 0500 para Viaccess), eso indica que el problema es específico del peer o de la tarjeta local que sirve ese CAID — no de toda tu configuración. Esta es la diferencia entre "mi línea está muerta" y "una tarjeta específica detrás de mi línea está sobrecargada", y cambia lo que debes arreglar.

Las Causas Raíz Más Comunes (Ordenadas por Frecuencia)

En el orden en que realmente veo esto en la práctica, esto es lo que está rompiendo tu señal.

Líneas C muertas o limitadas y cómo se forma el FBL (Freeze Box Loop)

Esta es la causa número uno, por un margen amplio. Una línea C en tu CCcam.cfg:

C: 185.xx.xx.xx 12000 myuser mypass

...puede estar "activa" a nivel TCP (el socket conecta bien) mientras la tarjeta detrás de ella está completamente sobrecargada o el peer ha limitado tu cuenta. Tu equipo solicita un ECM, no recibe una DCW válida a tiempo, solicita de nuevo, sigue sin recibirla, y solicita otra vez. Eso es FBL — Freeze Box Loop — y se ve idéntico a una línea muerta desde afuera, excepto que la conexión nunca se cae realmente. Revisa el registro: si ves solicitudes ECM repetidas para el mismo CAID sin la línea de respuesta "cw:" correspondiente, o tiempos de respuesta que no dejan de subir, la tarjeta de ese peer está muerta, sobrecargada, o ha dejado de servir silenciosamente ese provider ID.

los límites de hop y reshare matando silenciosamente la visibilidad de tu tarjeta

CCcam.cfg te permite limitar cuántos hops puede ser rescompartida una tarjeta:

F: friendname 12000 user pass 1 0 { 1,2,3 }

Los números entre llaves son los límites de hop de reshare por CAID. Una tarjeta en hop 0 es local — está físicamente en tu equipo. Hop 1 significa un peer de distancia. Al llegar a hop 3 o más, esa clave ha sido retransmitida a través de tres servidores separados antes de llegar a ti, y cada hop añade latencia y un nuevo punto de fallo. He visto tarjetas en hop 4 "funcionar" técnicamente, pero con tiempos ECM superiores a 1200 ms — completamente inútiles para cualquier cosa con un crypto-periodo rápido.

Discrepancia de CAID/provider y falta de ecm.info

A veces el lector cree que está sirviendo el CAID 0500 pero el provider ID real por debajo ha cambiado, o tu archivo CCcam.providers lista un ident que ya no coincide con lo que devuelve la tarjeta. En OScam, revisaecm.info en el directorio de logs — registra cada solicitud ECM con el CAID, el provider ID, y si llegó una respuesta válida. Si ves constantemente "not found" contra un CAID que creías cubierto, tu archivo de providers está desactualizado.

Jitter de red, MTU, y la trampa del tiempo de espera NAT del router

CCcam usa por defecto el puerto TCP 12000. OScam comúnmente corre su propio protocolo en rangos cercanos a 8888 para el webif, con newcamd típicamente en puertos 988x si estás haciendo puente entre protocolos. Si la tabla NAT de tu router agota el tiempo de espera de una conexión TCP inactiva (el valor por defecto común está en algún punto entre 300-600 segundos en routers domésticos) y CCcam no está enviando keep-alives con suficiente frecuencia, la línea se cae silenciosamente — tu equipo cree que sigue conectado, el router no, y los ECMs no llegan a ningún lado hasta que ocurre una reconexión. En líneas PPPoE/ADSL específicamente, las discrepancias de MTU (el overhead de PPPoE consume 8 bytes, así que a menudo necesitas 1492 en lugar de 1500) pueden fragmentar paquetes y corromper datos ECM de forma intermitente — esto se manifiesta como congelamiento esporádico que no tiene nada que ver con tu proveedor.

Tarjeta sobrecargada: profundidad de cola ECM y asignación de 'sid'

Si estás compartiendo tu propia tarjeta con varios usuarios adicionales, una tarjeta física solo puede decodificar cierta cantidad de solicitudes ECM concurrentes antes de que la cola se acumule. Observa cuántos SIDs activos (IDs de servicio/stream) están llegando a un solo lector en tu registro o en la página de estado del webif. Una sola tarjeta sobrecargada sirviendo 15 canales concurrentes a distintos usuarios mostrará tiempos ECM en aumento para todos — esto suele estar detrás de congelamientos que solo ocurren en ciertas horas del día, como las horas pico de la noche cuando todos están viendo a la vez.

Solucionándolo: Cambios de Configuración Que Realmente Detienen el Congelamiento

Una vez que sabes lo que muestra el registro, esto es lo que realmente marca la diferencia.

Ajustando CCcam.cfg: CACHE EX, GHOST CARDS OFF, y tiempos de espera recomendados

Algunas directivas en CCcam.cfg realmente ayudan:

CACHE EX : 1GHOST CARDS OFFMINIMUM CW : 1NODE ID : 0102030405060708

CACHE EX enables ECM caching so repeated requests for the same key within a short window don't hammer the peer again. GHOST CARDS OFF stops CCcam from advertising cards it can see reshared through a peer but that aren't actually reliable — ghost cards are a huge contributor to FBL because your box thinks it has a fast path to a CAID that's actually three hops deep and slow. MINIMUM CW : 1 just enforces that a control word must be non-empty before it's accepted, filtering out garbage responses from a flaky peer.

OScam equivalents: [cache] and dvbapi settings that matter

OScam's real advantage here is the loadbalancer. In oscam.conf:

[global]lb_mode = 1lb_nbest_readers = 2lb_nfb_readers = 1lb_retrylimit = 800lb_max_ecmcount = 5

lb_mode = 1 is "fastest reader" mode — OScam actively tracks response times per CAID/provider across every reader you have and routes requests to whichever one is fastest right now, instead of blindly hammering whatever's listed first. lb_retrylimit (in ms) tells it to give up on a slow reader and fail over to the next-best one rather than sitting there waiting. This one setting fixes more freezing than any CCcam.cfg tweak I've ever made, because CCcam has no equivalent — it just keeps asking the same peer regardless of how slow it's been historically.

Rate-limiting a bad peer instead of dropping it

If a peer serves a CAID nobody else does but it's slow, don't drop it outright — throttle your reliance on it. In OScam, lower its priority under [reader] with the lb_weight parameter so the loadbalancer only falls back to it when nothing faster is available, rather than treating it as an equal option.

Migrating a freezing line from CCcam to OScam protocol

This is the cleanest way to isolate whether the fault is the protocol or the peer itself. Add a cccam-type reader in oscam.server pointing at the exact same host and credentials:

[reader]label = peer1protocol = cccamdevice = 185.xx.xx.xx,12000user = myuserpassword = mypasscaid = 0500group = 1

If the same physical line now behaves better under OScam's loadbalancer than it did under raw CCcam, the fault was never the peer — it was CCcam retrying a bad reader with no backoff logic. That's a genuinely useful data point in any cccam troubleshooting review, because it tells you whether to fix your protocol stack or go find a different card source entirely.

Verifying the fix with a controlled channel-zap test

Don't trust a "feels better" impression. Pick two channels known to be heavy on ECM traffic (fast crypto-period, high viewership), and zap between them 20 times in a row while watching the log or webif ECM timing column. Before your fix, note the average ms and freeze count. After, repeat the exact same test. If average ECM time dropped and freeze count hit zero across 20 zaps, the fix held. If it's still climbing past 800 ms on either channel, you haven't actually solved it yet — go back to the log.

How to Judge Whether a Line or Provider Is Worth Keeping

Part of any real cccam troubleshooting review is deciding whether to keep fighting a bad line or cut it loose. Here's how to judge that objectively instead of on gut feel.

Objective metrics: uptime %, average ECM time, freeze frequency

Set a bar and hold every line to it. Sustained ECM response time should sit under roughly 400 ms on average for the CAIDs you actually watch. Uptime — meaning the connection stays established and actually serving valid DCWs, not just TCP-connected — should be somewhere above 99% measured over a week, not a single good evening. Freeze events on your heaviest channels should be a handful per day at most, not per hour. If a line can't hit those numbers over a sustained test period, it's not a config problem anymore — it's the line.

Señales positivas en una configuración de pares (tarjetas locales, salto bajo, IP estable)

Una configuración confiable muestra tarjetas en el salto 0 o 1 — es decir, genuinamente local o a un salto de distancia, no revendida a través de cuatro capas de reshare. La IP del endpoint es estable durante semanas, no rotativa. Los CAID que se sirven están documentados y coinciden con lo que realmente aparece en tu registro ecm.info. Estas son las huellas técnicas de alguien que gestiona una configuración de tarjeta real y bien mantenida, en lugar de una granja de reshare.

Señales de alerta que predicen congelamientos futuros

Presta atención a las IP que cambian cada pocos días sin previo aviso, listas de tarjetas que parecen implausiblemente grandes para lo que debería ser una configuración personal o de pequeña empresa, y valores de salto que no cuadran — una tarjeta que dice ser salto 1 pero se comporta como si estuviera cuatro saltos de profundidad en el tiempo de tu ECM. Cualquiera de estos predice el congelamiento antes de que siquiera comience, porque todos apuntan a una inestabilidad aguas arriba sobre la que no tienes visibilidad ni control.

Cómo se ve técnicamente una relación legítima con un proveedor

Para ser claros, esto se trata de probar tus propias tarjetas de suscripción y la interoperabilidad legítima entre tu propio hardware — compartir entre una tarjeta que posees y una segunda caja en tu propia casa, o verificar una relación comercial con acceso a tarjetas documentado y con licencia. Una relación técnica legítima te da un único endpoint estable, una lista de CAID/proveedor documentada que puedes verificar contra tu propia salida de ecm.info, y un reporte de salto honesto que puedes confirmar de forma independiente a través de tus propios registros. Si nada de eso se puede verificar desde tu lado, esa es la verdadera señal de alerta — no el congelamiento en sí.

Lo que no funciona (deja de perder el tiempo con esto)

Estas son las cosas que la gente prueba primero, y casi nunca solucionan nada, porque no abordan lo que el registro realmente está mostrando.

Reiniciar la caja en bucle en lugar de leer el registro

Un reinicio limpia las conexiones activas y reinicia los temporizadores, así que a veces las cosas parecen mejorar durante diez minutos. Eso no es una solución — es una coincidencia de tiempos. La latencia de ECM subyacente o el peer muerto siguen ahí; solo has reiniciado temporalmente el ciclo de FBL. Si reinicias y no revisas el registro, estarás de vuelta aquí en una hora con exactamente el mismo problema y cero información adicional a la que tenías al principio.

Aumentar a ciegas los límites de salto/reshare

Aumentar tu límite de salto de 2 a 4 hace visibles más tarjetas, claro — pero cada una de esas tarjetas recién visibles está, por definición, más lejos y es más lenta. Esto es lo opuesto a una solución. Cambia "ninguna tarjeta disponible" por "una tarjeta lenta disponible", y las tarjetas lentas son exactamente lo que causa el congelamiento que intentas resolver. Si estás persiguiendo límites de salto, revisa primero el valor de ms del ECM — una tarjeta de salto 1 a 900 ms es peor que una tarjeta de salto 2 a 200 ms.

'Soluciones' de CCcam.cfg copiadas y pegadas de foros

El volcado de configuración de otra persona incluye sus C-lines, sus CAID, sus ajustes de salto ajustados a sus relaciones de pares — nada de lo cual corresponde a tu configuración. Pegar el CCcam.cfg de un desconocido sobre el tuyo simplemente reemplaza líneas que funcionaban por líneas muertas y CAID irrelevantes que no necesitas, sin hacer nada respecto al problema real de peer o de red que causa tu congelamiento.

Culpar a la antena/LNB cuando el registro muestra latencia de ECM

Este es el diagnóstico erróneo más grande que veo. El congelamiento durante mal tiempo, o el congelamiento que parece seguir a la lluvia, genuinamente puede ser un problema de señal — una caída real de SNR desde la antena o el LNB. Pero eso se manifiesta como una imagen distorsionada o completamente perdida, con las lecturas de intensidad/calidad de señal cayendo en el estado de tu sintonizador, no como ciclos limpios de congelamiento y reanudación con niveles de señal normales. Si tu registro muestra solicitudes de ECM que salen y regresan tarde — un valor de ms claro que sube por encima de 800 — tu antena está bien. No reposiciones un LNB por un problema de tiempos de card-sharing.