Tiempo de espera de NCam ECM: Cómo solucionarlo (Guía completa)

Si estás buscando una solución para el tiempo de espera de NCam ECM, probablemente ya has mirado registros llenos de líneas comoECM (0x0963) tiempo de espera (3000 ms) mientras los canales se congelan o se ponen en negro a mitad de la transmisión. ¿La parte frustrante? La mayoría de los consejos en línea solo dicen "aumenta el valor de tiempo de espera", lo cual no soluciona nada y de hecho hace que los congelamientos se sientan más largos. Esta guía aborda las causas reales, desde lectores de upstream muertos hasta una ranura CI atascada en tu propia caja.

Antes de tocar cualquier configuración, entiende lo que realmente estás viendo. Un tiempo de espera no es lo mismo que un decodificado fallido, y tratarlos de la misma manera desperdicia horas.

Lo que realmente significa un tiempo de espera de ECM en NCam

Cada canal encriptado envía ECMs — Mensajes de Control de Derechos — aproximadamente cada 10 segundos. Tu cliente NCam captura uno, lo envía a un lector (una tarjeta local, un par de red, un emulador) y espera una palabra de control de vuelta. Esa palabra de control es lo que realmente desencripta la transmisión. Si no llega respuesta dentro de la ventana configurada, NCam registra un tiempo de espera y ya sea reintenta o falla a otro lector.

El ciclo de solicitud/respuesta de ECM explicado

El flujo es: dvbapi captura ECM del flujo → NCam lo dirige al mejor lector disponible basado en el balanceador de carga → el lector/servidor lo decodifica usando la tarjeta → palabra de control devuelta → dvbapi la pasa al decodificador. Todo el viaje de ida y vuelta en una configuración saludable con un lector local normalmente toma menos de 300 ms. En un par de red con un salto, podrías ver 400–800 ms. Si comienzas a ver 1500+ ms de manera consistente, los tiempos de espera se convierten en una cuestión de cuándo, no de si.

Ese valor de ecm-timeout (3000 ms por defecto en la mayoría de las versiones) es cuánto tiempo espera NCam antes de rendirse con un lector para esa solicitud específica de ECM. Tres segundos suena como mucho. Pero si tu período de criptografía es de 10 segundos y estás esperando 3 segundos, luego reintentando otro lector, y luego esperando 3 más — ya estás dentro del siguiente período de criptografía sin palabra de control. La pantalla se pone negra.

Leyendo la línea de tiempo de espera en tu registro de NCam

Una línea de tiempo de espera típica se ve algo así:

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

Desglosando eso:0963 es el CAID (el sistema de encriptación — Sky en este caso),000000 es el ID del proveedor,12AB es el ID del servicio (el canal específico), y3000 ms es la ventana de tiempo de espera que expiró. El nombre del lector (MyReader) te dice qué fuente de upstream no respondió. Esa es tu primera pista.

Tiempo de espera vs. 'No encontrado' vs. 'Rechazado' — Problemas diferentes

Esta es la cosa que casi nadie explica correctamente. Estos tres resultados tienen causas raíz completamente diferentes:

• Tiempo de espera — El lector era accesible, se envió la solicitud, pero no llegó respuesta a tiempo. Causas: alta latencia, servidor sobrecargado, conexión muerta, problema de señal local.
• No encontrado — El lector respondió, pero no tiene la tarjeta/derecho para ese CAID o proveedor. Tarjeta incorrecta, paquete incorrecto, o la tarjeta simplemente no está suscrita.
• Rechazado — El par rechazó activamente la solicitud. Generalmente filtrado SID/CHID en el lado del servidor, o un ECM falso/falsificado siendo bloqueado.

Si estás persiguiendo un tiempo de espera con soluciones destinadas a "no encontrado" — verificando derechos, cambiando servidores — estarás dando vueltas en círculos. La palabra clave del registro es todo. Léela primero.

Ajustando los parámetros de tiempo de espera y lector

Las ubicaciones de los archivos de configuración varían ligeramente según la versión, pero en la mayoría de las configuraciones de Linux embebido (cajas Enigma2, etc.) estás buscando/etc/tuxbox/config/ o/var/keys/. En un servidor independiente, típicamente es/etc/oscam/. Los archivos principales que tocarás sonoscam.conf,oscam.server, yoscam.dvbapi.

ecm-timeout en [global] y Per-Reader

La configuración global se encuentra enoscam.conf bajo el[global] bloque:

[global]

Puedes anular esto por lector enoscam.server:

[reader]

Aumentar el ecm-timeout de 3000 a 5000 ms le da más tiempo a los pares lentos para responder. Esto te proporciona una decodificación estable en un servidor en el límite. Pero — y esto es importante — también significa que cada ECM fallido ahora toma 5 segundos completos antes de que se active el failover. Si tienes tres lectores y uno está muerto, cada cambio de canal potencialmente espera 5 segundos por cada lector muerto antes de aterrizar en el que funciona. Aumentar el tiempo de espera sin solucionar el problema subyacente empeora la experiencia del usuario, no la mejora.

lb_retrylimit y lb_reopen_seconds para Balanceo de Carga

El balanceador de carga de NCam rastrea qué lectores están funcionando bien y enruta nuevos ECMs en consecuencia. Dos configuraciones controlan cómo maneja a los lectores malos:

[global]

lb_retrylimit establece el tiempo de respuesta del ECM (en ms) por encima del cual un lector se desprioriza. A 900 ms, cualquier lector que consistentemente tome más tiempo que eso se empuja hacia abajo en la lista.lb_reopen_seconds controla cuánto tiempo espera NCam antes de darle a un lector malo otra oportunidad — 900 segundos (15 minutos) evita que esté golpeando un par muerto en cada solicitud de ECM y añadiendo retrasos de 3 segundos en general. Si esto se establece demasiado bajo (como 60 segundos) y tienes un upstream genuinamente muerto, NCam sigue intentando constantemente, y cada reintento es otro tiempo de espera que consume tu transmisión.

cccmaxhops, cccwantemu y Límites Específicos por Lector

ParaCCcam lectores de protocolo,cccmaxhops limita cuántos saltos puede ser compartida una tarjeta antes de que NCam la ignore. Mantén esto en 1 o 2 como máximo. Las tarjetas a 3–5 saltos de distancia son basura para el tiempo de ECM — estás añadiendo la latencia de múltiples servidores intermedios.

[reader]

Establececccwantemu = 0 a menos que realmente quieras tarjetas emuladas de ese par. Las entradas emuladas pueden aparecer en el balanceador de carga y fallar en canales encriptados reales, causando tiempos de espera espurios.

Dónde viven los archivos de configuración y cómo recargarlos

Después de editar, no necesitas un reinicio completo. En la interfaz web de NCam (generalmente enhttp://your-box:8888), ve aConfig → Reiniciar o usa el botón Recargar Lectores. Alternativamente, envía un SIGHUP al proceso:killall -HUP oscam. Los cambios enoscam.server tienen efecto inmediato al recargar. Los cambios enoscam.conf [global] típicamente necesitan un reinicio completo delproceso oscam, no solo una recarga de lectores. process, not just a reader reload.

Latencia de Red y Causas del Lado del Servidor

Antes de cambiar un solo valor de configuración, averigua dónde está ocurriendo realmente el retraso. Cambiar el ecm-timeout cuando el problema es un lector upstream muerto no logra nada. Dedica 10 minutos a medir primero.

Midiendo el Tiempo de Ida y Vuelta al Par Upstream

Comienza con un ping básico a la IP o nombre de host del servidor. Si estás obteniendo tiempos de ping de más de 200 ms en un servidor que debería estar en Europa, ese es tu problema. Luego profundiza conmtr (Traceroute de Matt):

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

Esto te muestra la pérdida de paquetes y la latencia por salto. Un solo salto con un 40% de pérdida de paquetes en medio de la ruta causará tiempos de espera de ECM intermitentes incluso con un servidor saludable al otro lado. La solución está en la ruta de red, no en la configuración de NCam.

Ahora cruza referencias con la interfaz web de NCam. BajoEstado, la columna de tiempo de ECM muestra los tiempos de respuesta reales por lector. Si estás viendo consistentemente 1200–1800 ms allí con un tiempo de espera de 3000 ms, estás viviendo al límite. Un mal momento y se te acabará el tiempo.

MTU, Fragmentación y Problemas de Puerto (Rango Predeterminado 12000)

El protocolo CCcam generalmente se ejecuta en el puerto 12000 (configurable en la línea de dispositivo de tu lector). Camd35 generalmente usa 15000 o 15001. Estas son conexiones TCP, por lo que la fragmentación de MTU no debería ser un problema, pero las tablas de estado del firewall pueden eliminar conexiones inactivas silenciosamente.

Esta es la causa del problema de "tiempos de espera después de inactividad" que sorprende a la gente. Miras un canal durante 20 minutos, te detienes, vuelves una hora después y no se decodifica. La conexión está técnicamente "activa" desde la perspectiva de NCam, pero el NAT/firewall eliminó la entrada de estado. La solución: habilitar TCP keepalives a nivel de SO, o configurar tu router para usar un tiempo de espera de seguimiento de conexión más largo para esos puertos. En routers basados en OpenWrt, aumentanf_conntrack_tcp_timeout_established por encima de 7200 segundos.

Servidor Sobrecargado: Picos de Tiempo de ECM Bajo Carga Concurrente

Una sola tarjeta inteligente física solo puede responder a un ECM a la vez. Si un servidor tiene 50 clientes compartiendo una tarjeta y los 50 golpean un refresco de período criptográfico simultáneamente, esa tarjeta tiene una cola. El tiempo de ECM se dispara a 2000–3000 ms. En horas pico (noches, eventos deportivos de fin de semana), esto empeora drásticamente. La tarjeta no está rota, el servidor no está mal configurado, simplemente es matemáticas. Demasiados clientes por tarjeta.

Verás este patrón claramente: los tiempos de ECM en la interfaz web son estables en 400 ms toda la mañana, luego suben a 1800 ms a partir de las 19:00. Eso es sobre suscripción del servidor, punto final. Ninguna cantidad de ajuste local de NCam lo soluciona. La única solución real de tiempo de espera de ECM de NCam para esto es encontrar un servidor con menos clientes por tarjeta, o agregar un segundo par upstream con el mismo CAID como respaldo.

Problemas de Sintonizador/CI Local que Parecen Tiempos de Espera

Aquí está el que más tiempo de diagnóstico desperdicia: el problema no tiene nada que ver con la red en absoluto. Un slot CI (Interfaz Común) atascado, un lector de tarjetas interno degradado o una señal de satélite débil pueden producir entradas de tiempo de espera de ECM en los registros de NCam, porque el ECM fue capturado de un flujo malo, o el CI no devolvió ninguna palabra de control, y NCam lo registró como un tiempo de espera.

Verifica los niveles de señal en el menú de tu receptor. SNR por debajo de aproximadamente 12 dB en la mayoría de las configuraciones, o calidad de señal por debajo del 80%, comienza a producir paquetes corruptos. Eso incluye ECMs corruptos. NCam no puede decodificar un ECM distorsionado; se agota esperando una respuesta que no puede venir porque la entrada era basura desde el principio. Prueba el mismo canal en un transpondedor con una fuerza de señal conocida y buena y ve si los tiempos de espera desaparecen. Si lo hacen, el problema es tu antena, LNB o cableado, no NCam.

Flujo de Trabajo de Diagnóstico Paso a Paso

El mayor error que cometen las personas es cambiar dos o tres cosas a la vez y luego no saber cuál funcionó. Aquí está el manual que uso. Cambia una variable. Observa durante un mínimo de 15 minutos. Luego pasa al siguiente paso.

Habilitar Registro Detallado (Nivel de Depuración) de Forma Segura

Enoscam.conf [global], aumentar temporalmente el registro:

[global]

El nivel de depuración 64 te da detalles de enrutamiento ECM sin la verbosidad extrema de la depuración completa (255). No dejes la depuración completa activada permanentemente; en hardware embebido con almacenamiento lento, escribir megabytes de registro por hora en memoria flash acortará la vida del dispositivo y puede causar retrasos en I/O que afectan la decodificación misma. Actívalo, reproduce el problema y luego desactívalo.

Correlacionar las marcas de tiempo del registro con el congelamiento

Cuando un canal se congela, anota la hora exacta. Saca el registro y mira 5–15 segundos antes de esa marca de tiempo; los tiempos de espera de ECM aparecen antes del congelamiento visible porque la palabra de control se agota poco después de que la solicitud falla. Si ves un grupo de líneas de tiempo de espera a las 21:04:25 y la pantalla se volvió negra a las 21:04:33, ese es tu evento. Anota el CAID, PROVID y SID de esas líneas.

Probar un lector a la vez

Enoscam.server, desactiva todos los lectores excepto uno añadiendoenable = 0 a cada bloque que quieras omitir, luego recarga. Fuerza una sintonización al canal problemático. Observa la pestaña de estado en webif, específicamente la columna de tiempo ECM y los contadores ecmok/ecmnok para tu lector activo. Si ese lector se agota con carga cero (solo tu sesión única), el problema es la latencia de ese lector o tu conexión a él. Si responde bien, vuelve a habilitar el siguiente lector y prueba con ambos.

Este enfoque de un solo lector es el diagnóstico de solución de tiempo de espera de ECM más rápido de NCam que conozco. Elimina problemas de balanceador de carga y efectos de interacción de lectores de inmediato.

Confirma la solución sin falsos positivos

Un zap exitoso de canal no confirma una solución. NCam almacena en caché la última palabra de control válida brevemente, por lo que puedes zapear, obtener una imagen, pensar que está solucionado, y luego se congela 10 segundos después cuando comienza el siguiente período criptográfico y ocurre el mismo tiempo de espera nuevamente. Observa el contador ecmok en webif durante un mínimo de 15 minutos, en el canal específico que estaba fallando. Quieres ver que ecmok incremente cada 10 segundos con tiempos ECM muy por debajo de tu configuración de tiempo de espera, sin eventos ecmnok durante esa ventana. Esa es una solución confirmada.

Cómo elegir una fuente upstream confiable

Conseguir un par upstream sólido es la solución a largo plazo para el tiempo de espera de ECM de NCam que ninguna cantidad de ajuste de configuración local puede reemplazar. Aquí está lo que realmente importa al evaluar una fuente.

Criterios que correlacionan con bajo tiempo ECM

El tiempo de respuesta ECM es el mejor predictor de confiabilidad. Cualquier par decente debería estar entregando tiempos de respuesta por debajo de 700 ms para el CAID que necesitas, medido durante las horas pico, no solo a las 2 AM cuando el servidor está inactivo. La proximidad geográfica importa aquí: un servidor físicamente cerca de ti en un camino de red de baja latencia siempre superará a un servidor "premium" en una ruta transatlántica congestionada.

El conteo de saltos es el otro gran factor. Una tarjeta compartida a 1 salto de la fuente (el par está ejecutando la tarjeta real) siempre superará a una tarjeta a 3 saltos de profundidad a través de una cadena de re-compartición. Cada salto añade latencia y un posible punto de fallo. Pregunta específicamente cuántos saltos recorre tu solicitud ECM desde la tarjeta física. Cualquier cosa por encima de 2 es una señal de alerta.

Señales de alerta que predicen tiempos de espera frecuentes

Los tiempos ECM por encima de 1200 ms durante un período de prueba deberían descalificar una fuente de inmediato. Eso ya es el 40% de tu presupuesto de tiempo de espera por defecto gastado, sin margen para variaciones. Los servidores sin límite de clientes tienden a empeorar progresivamente con el tiempo a medida que incorporan más usuarios; observa si los tiempos ECM son estables durante una ventana de observación de 30 minutos o si están aumentando lentamente.

Ningún período de prueba ofrecido es en sí mismo una señal de alerta. Cualquier operador confiado en el rendimiento de su servidor te permitirá probarlo. Si no puedes verificar el tiempo ECM antes de comprometerte, estás volando a ciegas.

Pruebas antes de comprometerse

Configura el nuevo par como un solo lector enoscam.server con todos tus otros lectores desactivados. Pruébalo durante un período pico de la tarde; ahí es cuando aparecen las sobrecargas. Observa la columna de tiempo ECM en webif. Un servidor que muestra 350 ms al mediodía y 2400 ms a las 20:00 está sobrecargado y causará tiempos de espera regularmente. Un servidor que mantiene 400–600 ms durante las horas pico vale la pena mantener. La relación ecmnok/ecmok debería mantenerse muy por debajo del 5% en una fuente confiable; si ves un 15% de fallos ECM incluso cuando los tiempos de respuesta parecen estar bien, hay un problema de filtrado o de derechos que investigar por separado.