CCcam DVBAPI Delayer: Solución de Congelamiento& Guía de Configuración

Si has llegado aquí porque tus canales se congelan cada 10 segundos en el momento exacto, estás lidiando con una carrera de temporización — no con una línea mala. Elconfiguración del delayer dvbapi de CCcam es el ajuste que lo soluciona. Esta guía cubre exactamente cómo configurarlo, cómo leer los registros para ajustarlo correctamente, y cuándo no ayudará para que no pierdas tres horas persiguiendo lo incorrecto.

Lo que realmente hace el Delayer DVBAPI

La interfaz DVBAPI es cómo tu decodificador (o receptor basado en Linux que ejecuta Enigma2, por ejemplo) expone su descrambler CA al software de espacio de usuario. En lugar de usar un CAM físico, un cliente DVBAPI como OScam o el plugin DVBAPI integrado de CCcam escribe palabras de control (CWs) directamente en el demuxer a través de/dev/dvb/adapterX/caY.

El delayer inserta una pausa — medida en milisegundos — entre el momento en que el software recibe un CW descifrado y el momento en que escribe ese CW en el hardware. Sin esa pausa, el CW puede llegar más rápido de lo que el demuxer está listo para consumirlo. El resultado: una pantalla negra, un congelamiento, o un breve tartamudeo en cada cambio de clave.

Temporización de ECM a palabra de control en CCcam DVBAPI

Definiciones rápidas para que estemos en la misma página. UnECM (Mensaje de Control de Derecho) es un paquete corto cifrado transmitido en el flujo DVB. Tu cliente de compartición lo envía río arriba, la tarjeta lo descifra, y devuelve unapalabra de control — la clave real de 8 bytes que tu descrambler necesita para decodificar el video. Ese viaje completo toma algunos milisegundos dependiendo de tu línea.

La mayoría de los proveedores de televisión de pago rotan sus claves en unperíodo de criptografía de aproximadamente 10 segundos. Cuando el período cambia, llega un nuevo ECM, se obtiene un nuevo CW, y el cliente DVBAPI necesita escribirlo en el demuxer en el momento exacto. Demasiado pronto y el hardware lo descarta. Demasiado tarde y obtienes un intervalo de congelamiento.

Por qué se necesita un retraso antes de escribir el CW en el demuxer

El hardware del demuxer en muchos receptores — especialmente en unidades Dreambox más antiguas y cajas Enigma2 económicas — tiene una pequeña ventana donde aceptará un nuevo CW. Si tu cliente de compartición es rápido (lo cual suele ser algo bueno), puede ganar la carrera contra el hardware y escribir antes de que el demuxer haya terminado de cambiar al nuevo período de criptografía.

El delayer obliga al software a esperar en el CW durante N milisegundos antes de escribir. Ese margen de maniobra permite que el hardware se ponga al día. Suena contraintuitivo — ralentizar la respuesta para solucionar un problema — pero funciona, y funciona de manera consistente cuando se ajusta correctamente.

Cómo CCcam difiere del manejo dvbapi de OScam

El soporte nativo de DVBAPI de CCcam es bastante básico. Funcionará, pero la configurabilidad es limitada — obtienes un retraso global, y eso es todo. La implementación dvbapi de OScam es considerablemente más madura: retrasos por CAID, sobrescrituras por SID, una interfaz web que muestra tiempos ECM en tiempo real, y mejor direccionamiento de adaptadores.

Por eso la mayoría de las configuraciones de producción conectan CCcam a OScam: CCcam maneja el protocolo y la red de compartición de tarjetas, pero OScam maneja el descrambling real. Si aún estás ejecutando CCcam DVBAPI de forma nativa y luchando contra los congelamientos, el camino de migración a OScam vale la pena considerar — más sobre eso en la última sección.

Configuración del Delayer Paso a Paso

Obtener laconfiguración del delayer dvbapi de CCcam correcta comienza con saber qué archivo editar. La ruta difiere dependiendo de tu imagen y si estás usando el DVBAPI integrado de CCcam o conectando a través de OScam.

Localizando la configuración: CCcam.cfg vs oscam.dvbapi

Para el DVBAPI puro de CCcam, la configuración principal se encuentra en/var/etc/CCcam.cfg en la mayoría de las imágenes de Enigma2 (OpenATV, OpenPLi, OpenViX). En configuraciones más antiguas o imágenes basadas en Gemini, podrías encontrarlo en/etc/CCcam.cfg. Revisa ambas si no estás seguro.

Si estás usando OScam con un lector de CCcam (la configuración más común), el retraso se encuentra en/etc/tuxbox/config/oscam/oscam.dvbapi o/var/etc/oscam.dvbapi, nuevamente dependiendo de tu imagen. OpenATV tiende a usar/var/etc/. Las imágenes de OE-Alliance a veces lo colocan bajo/etc/oscam/. Ejecutafind / -name oscam.dvbapi 2>/dev/null si no puedes localizarlo.

Configurando el valor de retraso (parámetro DELAY y rangos en ms)

EnCCcam.cfg, la línea se ve así:

DELAY : 150

Eso son milisegundos. Comienza en100–300 ms y ajusta desde allí. Si los canales aún se congelan al cambiar de clave, aumenta en incrementos de 50 ms. Si el zapping se siente lento — presionas un botón y esperas un poco demasiado — has ido demasiado alto, bájalo en pasos de 25 ms.

Enoscam.dvbapi, el formato es diferente. Una línea de retraso global se ve así:

DELAY : 150

Pero también puedes apuntar a entradas específicas. El formato completo por entrada es:

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

Por ejemplo, para establecer un retraso de 200 ms para una combinación específica de CAID/proveedor mientras dejas todo lo demás en 100 ms:

DELAY : 100

Donde algunos receptores exponen una interfaz web para CCcam (el servidor HTTP integrado se ejecuta en el puerto 16001 por defecto), también puedes encontrar un campo "DVB API DELAY" allí. No confíes solo en eso — los cambios a través de la interfaz web no siempre sobreviven a un reinicio del daemon a menos que el archivo de configuración subyacente también se actualice.

Anulaciones de retraso por canal y por CAID

Esto es lo que la mayoría de las guías omiten. Un retraso global es impreciso — ralentiza cada cambio de canal en todos los CAID. Pero en la práctica, el problema de sincronización es casi siempre específico de CAID o incluso específico de transpondedor. El período de criptografía de un proveedor se sincroniza bien a 100 ms; otro necesita 250 ms porque sus ECM llegan ligeramente tarde en relación con el cambio de clave.

OScam'soscam.dvbapi te permite ajustar los retrasos de manera precisa. Si conoces el CAID (por ejemplo, 0963 o 1810) del paquete problemático, establece un retraso mayor solo para esa entrada y deja el global más bajo. Tu paquete de deportes cambia rápido; tu paquete de películas se mantiene estable. Ambos funcionan.

En un transpondedor con CAIDs mixtos — digamos, un paquete de libre acceso multiplexado con uno encriptado — asegúrate de que tu targeting de CAID sea preciso o ralentizarás el zapping en canales que no lo necesitan.

Reiniciando el daemon y confirmando que los cambios se cargan

CCcam no recarga la configuración en caliente. Después de editarCCcam.cfg, reinícialo:

killall -9 CCcam&& sleep 2&& CCcam

O a través de tu script de inicio si tienes uno configurado (/etc/init.d/CCcam reiniciar). Verifica/tmp/CCcam.log o cualquier ruta de registro que hayas configurado y busca la línea DELAY que se está analizando al inicio.

Para OScam, un reinicio suave es suficiente:

killall -HUP oscam

O usa la interfaz web de OScam en el puerto 8888 → Reiniciar. Verifica que la página de información confirme que el valor de retraso de tu dvbapi es el que esperas.

Leyendo los registros para encontrar el retraso correcto

Adivinar valores de retraso es una pérdida de tiempo. Los registros te dicen exactamente lo que está sucediendo, y cinco minutos leyéndolos superan una hora de prueba y error.

Habilitando el registro de depuración (loghistorysize, niveles de registro)

En eloscam.confde OScam, bajo[global]:

[global]

El nivel 64 te da detalles a nivel de ECM sin inundar el registro con ruido. Si necesitas más, combínalo:loglevel = 64+32 añade información de depuración del lector. Cualquier cosa más alta y necesitarás un mayorloghistorysize o la historia se llena antes de que puedas leerla.

Para CCcam, la verbosidad del registro se establece enCCcam.cfg:

NIVEL DE DEPURACIÓN : 1

El nivel 1 suele ser suficiente para ver eventos de entrega de CW. El nivel 3 proporciona todo el tráfico ECM pero genera mucha salida.

Interpretando el tiempo de decodificación/congelación en el registro

Lo que buscas es el tiempo entre la llegada del ECM y la entrega del CW, y cómo eso se correlaciona con tus eventos de congelación. En los registros de OScam, cada línea de decodificación se ve aproximadamente así:

[reader] (tiempo ecm: 87 ms) CW encontrado [0963/000000/1234]

Esa cifra de 87 ms es tu tiempo de ida y vuelta del ECM. Si tu período de criptografía es de 10 segundos y tus ECM llegan a un tiempo de decodificación de 87 ms de manera consistente, un retraso de 100–150 ms cubre el hueco con margen. Si ese número se dispara a 400 ms ocasionalmente (problema de red, servidor ocupado), necesitas un retraso más alto o una mejor línea.

Compara las marcas de tiempo de congelación en el registro de tu receptor con el intervalo de cambio de clave. Si las congelaciones ocurren consistentemente en intervalos de 9.8–10.2 segundos, eso es un problema de sincronización y el retrasador lo solucionará. Si las congelaciones son aleatorias —cada pocos minutos, sin patrón— eso no es un problema de sincronización.

Herramientas: tail -f, página de estado de oscam, columna de tiempo ECM

La interfaz web de OScam enhttp://[receiver-ip]:8888 tiene una pestaña ECM/EMM que muestra los tiempos de decodificación en vivo por CAID. Esa columna "msec" es en la que basas tu ajuste de retraso. Se actualiza en tiempo real.

Para ver registros en bruto:

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

Ejecuta eso mientras cambias de canal y observas las congelaciones. El método práctico de ajuste: comienza alto (digamos, 300 ms), observa la lentitud al cambiar de canal, reduce en 50 ms cada pocos minutos mientras monitoreas los eventos de congelación. Cuando las congelaciones reaparezcan, añade 75 ms de nuevo como margen de seguridad y considera que está hecho.

Configuraciones incorrectas comunes y cómo solucionarlas

La mayoría de los problemas de congelación que la gente culpa al retrasador son en realidad otra cosa. Aquí está lo que veo consistentemente.

Retraso establecido globalmente cuando solo un CAID lo necesita

ConfiguraciónRETARDO : 300 globalmente para arreglar un paquete de canal obstinado significa que cada cambio de canal toma 300 ms más. Si estás saltando a través de un evento deportivo y tocando 15 canales en 30 segundos, eso se suma a un retraso notable.

Solución: identifica el CAID que causa problemas (verifica el registro ECM), establece el alto retraso solo para ese CAID enoscam.dvbapi, y vuelve a llevar el global a 100 ms o menos.

Índice de adaptador/demux incorrecto para cajas de múltiples sintonizadores

En un receptor de doble sintonizador — común con Vu+ Duo2, Dreambox DM920, o similar — tienes/dev/dvb/adapter0 y/dev/dvb/adapter1, cada uno con su propioca0 dispositivo. Si tu cliente DVBAPI está escribiendo enadapter0/ca0 pero el sintonizador activo esadapter1, obtendrás un fallo completo de descifrado independientemente de los valores de retraso.

En eloscam.dvbapi de OScam, configuras el adaptador con:

TIPODECAJA : dreambox

Y verifica la enumeración del adaptador en/proc/bus/pci/ o a través dels /dev/dvb/. Algunas imágenes numeran los sintonizadores de manera diferente después de una actualización del kernel. Si tu configuración no ha cambiado pero el descifrado dejó de funcionar repentinamente, verifica si los índices del adaptador se desplazaron.

Conflictos entre CCcam DVBAPI y una instancia paralela de OScam

Este es sorprendentemente común. Alguien instala OScam junto a una configuración de CCcam en funcionamiento sin desactivar el DVBAPI integrado de CCcam. Ambos intentan abrir/dev/dvb/adapter0/ca0 simultáneamente. El resultado es impredecible: a veces uno gana, a veces pelean, siempre causando inestabilidad.

Necesitas exactamente un cliente DVBAPI activo. Si estás usando OScam, desactiva DVBAPI en CCcam eliminando o comentando laDVBAPI : 1 línea (o equivalente) enCCcam.cfg. Si estás usando el DVBAPI nativo de CCcam, asegúrate de que OScam no esté configurado como un cliente dvbapi.

Caché del lado del receptor enmascarando el verdadero problema

Algunas imágenes de Enigma2 — particularmente versiones más antiguas de OpenPLi — almacenan en caché el CW utilizado más recientemente brevemente. Esto puede hacer que parezca que el descifrado está funcionando cuando en realidad está sirviendo claves obsoletas durante uno o dos segundos antes de fallar. El síntoma: no hay congelamiento en la primera visualización, pero el zapping rápido causa breves pantallas negras que se resuelven por sí mismas.

Desactiva la caché de CW si tu imagen expone esa opción, o actualiza a una versión de imagen actual donde esto se maneje mejor. OpenATV 7.x y OpenPLi 9.x son ambos más confiables aquí que cualquier cosa de 2022 o anterior.

Cuando el Delayer No Ayuda (y Qué Sí)

Esta es la sección que la mayoría de las guías omiten, y es importante. Laconfiguración del delayer de CCcam dvbapisoluciona exactamente una cosa: una carrera de tiempo entre la entrega de CW y la preparación del demuxer. No soluciona problemas de red, líneas malas o limitaciones de hardware.

Congelaciones causadas por latencia de red, no por tiempo

Si tus tiempos de ida y vuelta de ECM en el registro de OScam están saltando entre 80 ms y 1200 ms de forma aleatoria, eso es inestabilidad de red. Tal vez el par de compartición esté sobrecargado. Tal vez tu conexión a Internet tenga pérdida de paquetes. El delayer no tiene nada que aportar aquí: no puedes configurarlo lo suficientemente alto como para cubrir un pico de 1.2 segundos sin hacer que el zapping se sienta roto.

Diagnostica problemas de red conping -i 0.2 [server-ip]ejecutándose mientras miras televisión. Si ves pings atípicos coincidiendo con eventos de congelación, la configuración de retraso es irrelevante. Arregla la red o encuentra una fuente de compartición más estable.

Problemas de período criptográfico / cambio de clave vs problemas de retraso

Las congelaciones relacionadas con el tiempo siguen un patrón: ocurren en intervalos predecibles que coinciden con el período criptográfico. Si notas una congelación a las 10:01:10 y otra a las 10:01:20 y otra a las 10:01:30, eso es un período criptográfico de 10 segundos y un problema de retraso. Soluciona esto con el delayer.

Si las congelaciones son a las 10:01:12, 10:04:47, 10:09:03 — sin patrón — eso no es un problema de sincronización de cambio de clave. No ajustes el delayer, investiga otra cosa.

Limitaciones de demux de hardware en receptores más antiguos

Algunos receptores más antiguos — Dreambox 500s, unidades AZBox de primera generación, ciertas cajas chinas sin nombre — tienen demuxers de hardware que simplemente no pueden aceptar CWs entregados por software lo suficientemente rápido, independientemente de cómo se ajuste el retraso. La ventana es demasiado estrecha, o el hardware tiene peculiaridades que ningún retraso de software puede compensar.

En estas cajas, la congelación suele ser de unos pocos fotogramas en lugar de una pantalla negra dura, y ocurre en cada cambio de clave sin importar lo que configures. Si esa es tu situación, el hardware es el cuello de botella. Un receptor moderno Vu+, Gigablue o AX manejará la misma configuración sin problemas.

Migrando de CCcam DVBAPI a OScam para estabilidad

Si estás utilizando el DVBAPI nativo de CCcam y te encuentras con limitaciones en las opciones de configuración, migrar a OScam como el manejador de DVBAPI mientras mantienes CCcam como el protocolo de compartición es el movimiento correcto. El puente es simple a un alto nivel: OScam se conecta a CCcam como lector a través del protocolo newcamd o CCcam en el puerto 10000 (o cualquier puerto que use tu servidor CCcam), y luego maneja toda la descramación local de DVBAPI por sí mismo.

Enoscam.servertu lector CCcam se ve así:

[reader]

OScam luego maneja el lado de DVBAPI con su control completo de retraso, targeting por CAID y la interfaz web para monitorear todo. Los problemas de congelación que provienen de la implementación básica de DVBAPI de CCcam suelen desaparecer inmediatamente cuando haces este cambio.