```html

Canales del Servidor CCcam: Configuración, Configuración y Solución de Problemas

Si estás mirando una pantalla negra o una imagen congelada después de que tu configuración de CCcam esté funcionando, estás en el lugar correcto. Comprender cómo funcionan realmente los canales del servidor cccam a nivel de protocolo — no solo "agrega una C-line y espera lo mejor" — es lo que separa una configuración confiable de una frustrante. Esta guía asume que tienes CCcam instalado, tienes al menos una C-line o una tarjeta local configurada, y canales específicos están faltando, congelados o se niegan a descifrar.

Cómo CCcam Asigna Tarjetas a Canales

Aquí está la cosa que la mayoría de las guías omiten por completo: CCcam no tiene concepto de "canales" de la manera que lo hace tu EPG. No almacena una lista de "Sky Sports HD, BBC One, Eurosport." Lo que almacena es un conjunto de tuplas numéricas — CAID, ID de proveedor y SID — y las compara con las solicitudes de ECM. Si la tupla coincide y la tarjeta puede descifrar, obtienes una palabra de control. Si no, pantalla negra.

Qué Significa un 'Canal' a Nivel de Protocolo

A nivel de DVB, cada canal encriptado transmite un paquete ECM (Mensaje de Control de Derechos) junto con la transmisión de vídeo. Ese ECM contiene el CAID que identifica qué sistema de CA lo encriptó. Tu receptor envía ese ECM a CCcam, que lo enruta a una tarjeta que reconoce el CAID. La tarjeta lo descifra y devuelve una palabra de control. Esa palabra de control descodifica el vídeo.

Entonces "canal no funciona" casi siempre significa que el enrutamiento de ECM falló en algún lugar — ya sea que el CAID no coincidió, la tarjeta no tenía los derechos, o la respuesta tardó demasiado. Ese es el modelo mental que necesitas.

CAID, ID de Proveedor y SID: Los Tres Identificadores que Importan

Estos tres números definen completamente el acceso al canal en CCcam:

• CAID — ID de Acceso Condicional. Identifica al proveedor de CA. Por ejemplo, 0x0500 es Viaccess, 0x0600 es Irdeto, 0x1800 es Nagravision. Este es el primer filtro en la cadena de enrutamiento.
• ID de Proveedor — Un subnombreespacio dentro del sistema de CA. Una sola tarjeta con CAID 0x0500 podría llevar IDs de proveedor 032830, 042800 y 040810 — cada uno representando un operador diferente o un paquete.
• SID — ID de Servicio. El identificador de canal real dentro de un transpondedor. Esto es lo que se asigna a "ese canal específico" en la lista de canales de tu receptor.

CCcam enruta una solicitud de ECM haciendo coincidir primero CAID, luego ID de proveedor, luego intentando el descifrado. El SID no se usa para enrutamiento — es el nivel de suscripción de la tarjeta lo que determina si la palabra de control vuelve válida para un SID determinado.

Cómo CCcam Construye su Lista de Canales Interna desde Tarjetas Conectadas

Cuando CCcam se inicia y se inserta una tarjeta (o una C-line se conecta), CCcam lee el ATR de la tarjeta y realiza una verificación de derechos inicial. Construye una tabla interna de qué CAIDs e IDs de proveedor responde esa tarjeta. Esta tabla es lo que ves en t

```la interfaz web en el puerto 16001.

Importantemente, CCcam no pre-enumera cada SID que una tarjeta puede desencriptar. Solo lo descubre dinámicamente cuando llega una solicitud ECM. Así que la interfaz web te muestra CAIDs y proveedores — no una lista de canales pre-construida. No sabrás que un SID específico está roto hasta que intentes sintonizarlo.

Diferencia Entre el Nivel/Paquete de una Tarjeta y Acceso CAID Sin Procesar

Esto atrapa a mucha gente. Una tarjeta puede presentar CAID 0x0919 (Nagravision) y tener una ID de proveedor 000000 visible — pero solo tener un nivel de suscripción básico. Los canales premium en ese mismo CAID y proveedor devolverán una palabra de control inválida, o ninguna respuesta en absoluto, porque la tarjeta simplemente no tiene el derecho.

CCcam no puede decirte de antemano qué SIDs están dentro de la suscripción de una tarjeta. Intentará desencriptar y registrará un fallo. Esa es la única forma de averiguarlo — intentar desencriptar y leer la respuesta ECM en el registro.

Configurando CCcam para Compartir Canales Específicos

El archivo de configuración principal está en /etc/CCcam.cfg en la mayoría de los equipos Linux y receptores Enigma2. Todo lo que controla qué canales se comparten, filtran o bloquean está aquí. Repasemos las directivas que realmente importan.

Sintaxis de CCcam.cfg para Filtrado de Canales y CAID

La estructura básica usa directivas en mayúsculas seguidas de dos puntos y el valor. El espacio en blanco es flexible. Los comentarios usan #. Aquí hay un ejemplo de trabajo mínimo que maneja control a nivel CAID:

# /etc/CCcam.cfg
PORT: 12000
NEWCAMD PORT: 15050 01020304050607080910111213141516
C: peer.example.com 12000 username password
IGNORE CAID: 0500
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0919 PROVID: 000001
SHARE LIMIT: 1
DEBUG: 1
HTTP PORT: 16001

La línea IGNORE CAID: 0500 le dice a CCcam que descarte cualquier solicitud ECM o compartición que involucre Viaccess (0500). Las líneas PROVIDE CAID incluyen en la lista blanca combinaciones específicas de CAID/proveedor. Si usas ambas, IGNORE tiene precedencia para sus CAIDs listados.

Usando Directivas IGNORE y PROVIDE para Incluir o Excluir CAIDs en la Lista

Si deseas permitir todo excepto un sistema CA, usa IGNORE. Si deseas una inclusión en lista blanca estricta, combina IGNORE CAID: ALL con líneas PROVIDE explícitas. La palabra clave ALL es una directiva real — le instruye a CCcam rechazar todos los CAIDs no explícitamente proporcionados.

IGNORE CAID: ALL
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0600 PROVID: 000000

Esto bloquea tu servidor solo a esas dos combinaciones de CAID/proveedor. Cualquier otra cosa — incluyendo un cliente que solicita canales Viaccess — se descarta silenciosamente. Útil cuando estás compartiendo una tarjeta específica y no deseas exponer CAIDs no relacionados de pares ascendentes.

Restringiendo la Compartición a IDs de Proveedor Específicos

El filtrado de ID de proveedor es más quirúrgico que el filtrado de CAID. Podrías tener una tarjeta con CAID 0x0500 y tres IDs de proveedor — uno para e

cada paquete de suscripción. Si solo deseas compartir un paquete, especifica solo ese ID de proveedor en la directiva PROVIDE e IGNORA el resto:

IGNORE CAID: 0500
PROVIDE CAID: 0500 PROVID: 032830

Esto expone solo el paquete del proveedor 032830 bajo Viaccess mientras bloquea los otros ID de proveedor de esa misma tarjeta. Limpio y efectivo para compartir suscripciones parciales.

Configurar SHARE LIMIT y Hop Count para Controlar la Propagación de Canales

La directiva SHARE LIMIT controla cuántos saltos corriente abajo puede viajar un compartir. Configurarlo a 0 significa que solo tu tarjeta local se comparte — sin recompartir de tarjetas que recibiste de pares corriente arriba. Configurarlo a 1 significa que compartes tu tarjeta local un salto corriente abajo. Los valores más altos permiten más saltos.

SHARE LIMIT: 1

La directiva RESHARE a nivel de usuario funciona diferente — controla si un cliente conectado específico puede recompartir lo que reciben de ti. Un valor de 0 significa no recompartir; 1 significa que pueden recompartir un salto. Esto importa si estás viendo tus canales del servidor cccam apareciendo en servidores que no autorizaste.

Los Archivos CCcam.providers y CCcam.channelinfo Explicados

Estos dos archivos confunden a la gente porque se ven funcionales pero no lo son. Ambos son solo cosméticos.

/usr/share/CCcam/CCcam.providers mapea ID de proveedor a nombres de operador legibles para humanos. Hace que tus registros digan "Viasat" en lugar de "042800." No hace absolutamente nada para afectar qué canales se descifran. La misma historia para /usr/share/CCcam/CCcam.channelinfo — mapea SID a nombres de canal para legibilidad de registros. Útil para depuración, irrelevante para desencriptación.

El formato de channelinfo es una entrada por línea: SID en hexadecimal, luego el nombre del canal. Por ejemplo:

1234 BBC One HD
5678 Sky Sports 1

Coloca el archivo donde tu CCcam.cfg lo referencia. Si falta, CCcam simplemente recurre a registrar valores hex sin procesar.

Verificar Qué Canales Puede Descifrar Tu Servidor

No deberías estar adivinando si tu servidor puede descifrar un canal. CCcam te proporciona una interfaz HTTP integrada y salida de registro que te dicen exactamente qué está pasando — si sabes cómo leerlos.

Leer la Interfaz Web de CCcam (Puerto 16001) para Inspeccionar CAIDs Activos

Por defecto, CCcam expone una interfaz web en el puerto 16001. Asegúrate de que tu CCcam.cfg tenga:

HTTP PORT: 16001

Luego visita http://<tu-ip-receptor>:16001 en un navegador. Verás secciones para tarjetas conectadas, clientes activos, compartires e historial de ECM. La sección de tarjetas es tu punto de partida — enumera el CAID de cada tarjeta, ID de proveedor, conteo de saltos y nivel de recompartir.

Un problema importante: si estás ejecutando CCcam detrás de NAT y has reenviado el puerto 12000 para conexiones de cliente, el puerto 16001 es separado y necesita su propia regla de reenvío. Muchas personas reenvían el puerto del cliente de CCcam pero olvidan

el puerto HTTP, y luego se preguntan por qué no pueden ver la interfaz web desde fuera de la LAN.

Interpretación de las secciones 'Tarjetas' y 'Recursos Compartidos' en la interfaz web

La sección de tarjetas muestra hop=0 para tarjetas físicas insertadas localmente. Hop=1 significa que la tarjeta está a una C-line de distancia, hop=2 significa dos saltos, y así sucesivamente. A medida que aumenta el número de saltos, la latencia aumenta y la confiabilidad tiende a disminuir.

La sección de recursos compartidos muestra qué clientes descendentes están conectados y a qué han estado accediendo. Si un cliente está conectado pero la tabla de recursos compartidos no muestra actividad en un CAID específico, entonces o no lo están solicitando o sus filtros lo están eliminando antes de que les llegue.

Usar la salida del registro de CCcam para rastrear una solicitud ECM fallida

Establezca DEBUG: 1 en CCcam.cfg para un rastreo ECM básico. Para obtener una salida más detallada, use DEBUG: 3, pero espere archivos de registro grandes. Una respuesta ECM exitosa se ve así:

ECM 0919/000000/1234 answered in 320ms by card 1

Un fallo se ve como uno de estos:

ECM 0919/000000/1234 - no card found
ECM 0919/000000/1234 - timeout after 3000ms
ECM 0919/000000/1234 - card returned error

"No card found" significa que ninguna tarjeta en su pool coincide con esa combinación CAID/proveedor — verifique sus filtros IGNORE/PROVIDE. "Timeout" significa que se encontró una tarjeta pero no respondió a tiempo — problema de latencia. "Card returned error" generalmente significa que falta el derecho de suscripción para ese SID.

Referencia cruzada de SID con una base de datos de canales DVB

Si no está seguro de qué CAID y SID utiliza un canal específico, debe mirar el PMT sin procesar. Las herramientas dvbsnoop y tzap (parte del paquete dvb-apps en Linux) le permiten sintonizar un transpondedor y volcar la información del servicio.

tzap -c /etc/channels.conf "BBC One HD"
dvbsnoop -s pmt 1234

El volcado de PMT mostrará las entradas del descriptor de CA, incluidos el CAID y el ECM PID. Compare esos valores con lo que CCcam muestra en la interfaz web. Si el CAID en el PMT no está en su tabla de tarjetas, ese es su problema.

Prueba de descifrado con un único canal conocido antes de escalar

Antes de agregar múltiples C-lines o reglas de filtro complejas, pruebe con un canal que sepa que debería funcionar. Elija un canal cuyo CAID pueda verificar desde el PMT, confirme que ese CAID aparece en la tabla de tarjetas de la interfaz web, e intente sintonizarlo. Consiga que un canal se descifre limpiamente, luego expanda. Esto aísla los problemas de configuración de los problemas de suscripción.

Razones comunes por las que faltan canales o no se descifran

Estos son los fallos que veo más a menudo, en orden aproximado de frecuencia con la que realmente ocurren. Cada uno tiene una ruta de diagnóstico específica.

La tarjeta no tiene el paquete de suscripción para ese canal

El CAID coincide, el ID de proveedor coincide, pero el canal está en negro. El registro dice "card returned error". Este es un problema de nivel de suscripción — la tarjeta simplemente no tiene derechos para ese SID. Th

No hay solución de configuración para esto. O bien la suscripción no incluye ese canal o las actualizaciones de EMM han caducado (véase más abajo).

Desajuste de CAID entre la solicitud del cliente y la tarjeta del servidor

Algunos canales se transmiten en múltiples CAID simultáneamente (llamado overcrypt). Su receptor puede solicitar el canal usando CAID 0x0606 mientras que su tarjeta solo maneja CAID 0x0600. El registro mostrará "no card found" aunque conceptualmente tenga una tarjeta para ese canal. La solución es verificar el PMT actual para todos los descriptores CA y confirmar qué CAID maneja su tarjeta. En configuraciones bridged de OScam puede configurar la prioridad de CAID — en CCcam puro puede que necesite forzar al cliente a solicitar un CAID específico.

ID de proveedor filtrado en CCcam.cfg

Verifique sus reglas IGNORE/PROVIDE. Si ha utilizado IGNORE CAID: ALL y olvidó agregar una línea PROVIDE para un ID de proveedor, ese paquete completo se descarta silenciosamente. El registro no mostrará ningún intento de ECM llegando a ese proveedor. Cruce el ID de proveedor de la interfaz web con sus líneas PROVIDE en la configuración.

Contador de saltos o nivel de redistribución establecido demasiado bajo

Si agregó una línea C a un peer y las tarjetas de ese peer aparecen en su interfaz web en hop=1, pero sus clientes downstream no pueden acceder a ellas, verifique su SHARE LIMIT. Un SHARE LIMIT de 0 significa que solo comparte tarjetas hop=0 (locales) — las tarjetas del peer nunca se redistribuyen a sus clientes. Establézcalo en 1 para permitir un nivel de redistribución:

SHARE LIMIT: 1

También verifique el valor RESHARE asignado al peer en su configuración de línea C. Algunas compilaciones soportan el nivel de redistribución por peer en la sintaxis de línea C.

Actualizaciones de EMM bloqueadas — Derechos de tarjeta no actualizados

Este mata configuraciones lentamente. Si RECEIVE EMM: no está en su configuración (o ausente en algunas compilaciones que tienen deshabilitado por defecto), la tarjeta deja de recibir mensajes de actualización de derechos de la transmisión. Con el tiempo, los derechos de suscripción caducan y los canales dejan de desencriptarse — a menudo comenzando primero con paquetes premium.

RECEIVE EMM: yes

Establezca esto y reinicie CCcam. Dependiendo de cuánto tiempo EMM estuviera deshabilitado, puede tomar varios minutos a una hora para que la tarjeta reciba y procese todas sus actualizaciones de derechos. Los derechos de tiempo limitado son particularmente vulnerables aquí — una tarjeta que funcionaba bien puede dejar de desencriptar canales silenciosamente a mitad de sesión cuando sus derechos almacenados caducan sin renovación.

Latencia de red causando tiempos de espera de ECM en canales de cambio rápido

El tiempo de espera de ECM predeterminado de CCcam es 3000ms. En un receptor de cambio rápido o cuando cambia entre canales rápidamente, las solicitudes de ECM necesitan completarse antes del tiempo de espera o obtiene un error "timeout". Si su conexión peer tiene una latencia de ida y vuelta de 150-200ms y el procesamiento de tarjeta agrega otros 200-300ms, está muy ajustado.

Puede ajustar el tiempo de espera en CCcam.cfg:

ECM TIMEOUT: 5000

Aumentar esto da más ti a los peers lentos

me pero puede hacer que el cambio de canal se sienta lento. Una solución mejor es reducir la latencia real — elige pares geográficamente más cercanos o en conexiones de menor latencia.

Diferencias de Protocolo Newcamd o CS378X al Puente a OScam

Si estás haciendo puente de CCcam a OScam vía protocolo Newcamd (configurado con NEWCAMD PORT: 15050 <DES key> en CCcam.cfg), los desajustes de versión o desajustes de clave DES causarán fallos silenciosos en CAIDs específicos. La entrada /etc/oscam/oscam.server de OScam para la conexión de CCcam necesita coincidir exactamente con la versión del protocolo:

[reader]
label = cccam_bridge
protocol = cccam
device = 127.0.0.1,12000
user = username
password = password
caid = 0919,0500

Si ciertos CAIDs funcionan a través del puente y otros no, verifica el filtrado de CAID en ambos lados. OScam tiene su propio filtro de CAID por lector que puede bloquear CAIDs independientemente de los propios filtros de CCcam. También cuidado con los desajustes de versión de CCcam entre servidor y cliente — las versiones más antiguas de CCcam a veces fallan en la negociación de compartición para sistemas de CA específicos cuando el manejo del protocolo diverge.

Evaluación de una Conexión de Par Remoto de CCcam para Cobertura de Canal

Obtener una C-line de un par es solo el comienzo. La C-line en sí te dice casi nada sobre qué canales del servidor cccam son realmente accesibles a través de ella.

Lo Que una C-Line Te Dice — y Lo Que No

Una C-line se ve así:

C: hostname.example.com 12000 myuser mypassword

Eso es todo. Cuatro campos: host, puerto, nombre de usuario, contraseña. La C-line contiene cero información sobre qué CAIDs, IDs de proveedor o SIDs comparte el par. Lo descubres solo después de conectar e inspeccionar la tabla de comparticiones de la interfaz web. Cualquiera que afirme ofrecer "X canales" en una descripción de C-line te está hablando sobre la cobertura de suscripción nominal de su tarjeta, no lo que realmente recibirás — esos números se degradan con el recuento de saltos, la carga del servidor y la configuración del filtro.

Cómo Probar una C-Line Antes de Comprometerse con Ella

Añade la C-line a tu CCcam.cfg, reinicia CCcam, e inmediatamente verifica el puerto 16001. En 30-60 segundos las tarjetas del par deberían aparecer en la tabla de tarjetas/comparticiones. Nota:

• Qué CAIDs aparecen — ¿coinciden con lo que necesitas?
• ¿A qué recuento de saltos vienen? Hop=1 es bueno; hop=3 o superior es una bandera roja.
• Verifica los tiempos de respuesta de ECM en el registro para un canal conocido. Consistentemente por debajo de 800ms es sólido; más de 1500ms causará problemas.
• Observa la estabilidad de la conexión durante 10-15 minutos. Si el par se desconecta y se reconecta repetidamente, eso es un problema de confiabilidad.

Criterios Genéricos para Evaluar la Calidad de Canal del Par/Servidor

No confíes simplemente en que un par es bueno porque se conectó. Evalúalo adecuadamente:

• Ping por debajo de 200ms al host del servidor desde tu red
• Tiempos de respuesta de ECM consistentemente por debajo de 1500ms en el registro de CCcam
• Las tarjetas apareceanillo en hop=1 (tarjetas directamente conectadas, no cadenas compartidas)
• Sin ciclado excesivo de conexión visible en el registro de CCcam durante una hora
• Si el par afirma servir a muchos clientes simultáneos, verifica si los tiempos de respuesta de ECM se degradan durante las horas pico — los servidores abarrotados lo muestran claramente

Un par que anuncia miles de canales a través de muchos saltos es casi siempre una cadena compartida con alta latencia y confiabilidad cuestionable. Las tarjetas locales en hop=0 o los pares directos en hop=1 son lo que deseas para canales de servidor cccam confiables.

Verificar el Tiempo de Actividad del Par y el Tiempo de Respuesta de ECM a través de la Interfaz Web de CCcam

La interfaz web de CCcam muestra estadísticas de ECM por conexión si has tenido el registro de depuración activo. Busca en la sección "clientes" el tiempo de conexión y la tasa de ECM/éxito. Un par que ha estado conectado durante 20 horas con 5,000 ECM y solo 3 fallos es sólido. Un par que muestra tasas de tiempo de espera del 40% en el historial de ECM es basura — continúa.

Entender el Acceso Compartido vs Dedicado a Tarjetas y Su Efecto en los Canales

El acceso compartido significa que una tarjeta física está sirviendo solicitudes de ECM para muchos clientes simultáneos. Cada solicitud de ECM es secuencial en la tarjeta — la tarjeta procesa una por una. Bajo carga pesada, los tiempos de respuesta aumentan y los tiempos de espera se incrementan. Por eso los canales de servidor cccam en un servidor compartido sobrecargado se congela durante las horas pico de visualización incluso cuando el CAID está presente y la suscripción es válida.

El acceso dedicado — donde una tarjeta sirve solo tu conexión — elimina la contención de cola. Las respuestas de ECM se mantienen rápidas sin importar qué más esté sucediendo. La compensación es costo y disponibilidad. Al evaluar un par, pregunta si la tarjeta se comparte entre muchos usuarios o se asigna específicamente para ti. La respuesta explica mucho sobre lo que experimentarás.

Una cosa más a vigilar: los canales DVB-S2 que utilizan modulación ACM o VCM requieren hardware que admita codificación variable. Si la tarjeta sintonizadora del servidor no maneja ACM, ni siquiera puede recibir esos transpondedores — lo que significa que la tarjeta es inalcanzable para esos canales incluso si el CAID y la suscripción son perfectamente válidos. Esta es una restricción de hardware en el extremo del servidor, no un problema de configuración de software.