Configuración de Compartición de Tarjeta Tricolor: CCcam& Guía de OScam
Obtener canales de Tricolor a través de un servidor de compartición de tarjetas es un proceso sencillo una vez que entiendes lo que cada parámetro de configuración realmente hace. Pero la mayoría de las guías solo pegan una línea C y dan por terminado el asunto, dejándote varado en el momento en que algo no funciona. Esta guía cubre la configuración completade compartición de tarjeta Tricolor (CCcam/OScam) — rutas reales de archivos de configuración, valores correctos de CAID/ident, sintaxis de bloque funcional y un camino de diagnóstico para cuando los canales se quedan en negro o se congelan. También cubriré los casos extremos que otras guías omiten por completo.
Tricolor en Compartición de Tarjeta: Lo Que Necesitas Antes de Comenzar
Antes de tocar un archivo de configuración, necesitas entender el sistema de encriptación, tener el hardware correcto en su lugar y poder leer la línea del servidor que te han dado. Saltarte cualquiera de estos pasos es cómo terminas pasando dos horas depurando un problema que nunca tuvo que ver con la configuración.
Sistema de Encriptación y CAID Usado por Tricolor
Tricolor TV transmite desdeEutelsat 36E (36.0° Este) y utilizaDRE Crypt encriptación — a veces escrito DGCrypt. El CAID principal es0x4AE1. Algunos paquetes o transpondedores pueden hacer referencia a0x4AE5. Esto importa porque cada línea que obtienes de una fuente de compartición de tarjetas solo es válida para los CAIDs que la tarjeta de esa fuente realmente posee. Una línea construida alrededor de un CAID diferente no solicitará ECMs de tu caja, o los solicitará y no obtendrá nada a cambio.
Para confirmar el CAID activo en tu caja Enigma2, sintoniza un transpondedor de Tricolor, abre el panel de información del servicio (generalmente presionando prolongadamente Info), y verifica el campo de descriptor de CA. Deberías ver4AE1 listado. Si no lo ves, o estás en la posición de satélite incorrecta o el transpondedor no está encriptado.
El ident (ID del proveedor) para las líneas estándar de DRE Crypt es típicamente4AE1:000000. Necesitarás este valor exacto en los bloques de lector y usuario de OScam.
Requisitos de Hardware y SO
Necesitas unsintonizador DVB-S2 bloqueado en Eutelsat 36E. Suena obvio, pero una caja apuntada a 13E o 19.2E nunca sintonizará el transpondedor encriptado sin importar cuán perfecta sea tu configuración de CCcam. Verifica con un medidor de señal: un bloqueo limpio en 36.0E con>70% de calidad en un transpondedor de haz de Tricolor es la base.
Para el SO, necesitas Enigma2 (OpenATV, OpenPLi, OpenVision, etc.) o cualquier receptor basado en Linux con soporte para softcam. CCcam y OScam funcionan como demonios en estas plataformas. El acceso SSH o Telnet a la caja es innegociable: estarás editando configuraciones y leyendo registros a través de la línea de comandos.
Tu caja también necesita una conexión a internet funcional. Prueba conping 8.8.8.8 antes que nada. El tráfico de compartición de tarjetas es de bajo ancho de banda pero sensible a la latencia, por lo que una conexión inestable causará congelamientos constantes incluso con una configuración perfecta.
Elegir CCcam vs OScam para Este Proveedor
CCcam es más simple de implementar: un archivo de configuración, pega tu línea C, reinicia el demonio, listo. OScam requiere más archivos y más conocimiento, pero te da un control granular sobre CAID/ident, un registro mucho mejor y una solución de problemas mucho más fácil.
Mi recomendación: usa OScam, especialmente si estás diagnosticando congelamientos o fallos de decodificación. La salida del registro de OScam te dice exactamente qué está sucediendo — si se solicitó un ECM, qué lector lo manejó, cuántos milisegundos tomó y por qué falló. CCcam te da casi nada de eso. Para DRE Crypt, donde los desajustes de CAID/ident son una fuente común de pantallas negras, la visibilidad de OScam vale el tiempo extra de configuración.
Cómo Leer una Línea de Servidor Que Te Han Dado
Una línea C de CCcam se ve así:C: nombre_de_host puerto nombre_de_usuario contraseña. El nombre de host es la dirección del servidor, el puerto es típicamente 12000, y las credenciales son específicas de tu cuenta. Una línea N (formato newcamd) añade una clave DES de 14 bytes al final:N: nombre_de_host puerto nombre_de_usuario contraseña 01 02 03 04 05 06 07 08 09 10 11 12 13 14.
Si te han dado una línea y ninguno de los campos tiene sentido, estás mirando la sintaxis del bloque de lector de OScam (formato completamente diferente) o un pegado desordenado. No adivines. Pregunta a quien te dio la línea para confirmar el formato antes de que gastes tiempo depurando un error tipográfico.
Configurando CCcam para Tricolor
La configuración de CCcam se encuentra en/usr/keys/CCcam.cfg en la mayoría de las imágenes de Enigma2. Algunas versiones más antiguas utilizan/etc/CCcam.cfg o/var/etc/CCcam.cfg. Verifica qué ruta utiliza tu imagen confind / -name CCcam.cfg 2>/dev/null antes de editar.
Editando CCcam.cfg y el Formato de la Línea C
El formato de la línea C es sencillo:
C: server.example.com 12000 miusuario mipasswordLas banderas opcionales en la línea C incluyen un límite de saltos y una directiva de servidor bloqueado, pero para una línea Tricolor básica no las necesitas. Pega la línea exactamente como se da, una línea por conexión de servidor.
Puedes añadir una ruta de registro de depuración:
LOGGER NOMBRE_DE_ARCHIVO : /tmp/CCcam.logEl nivel 1 es suficiente para ver eventos de conexión. El nivel 12 produce una pared de ruido — no lo uses en producción.
Configurando el Puerto de Escucha y Opciones de Conexión
Si tu caja actúa como un servidor CCcam (compartiendo una tarjeta local con otros clientes), configura el puerto de escucha:
PUERTO DE ESCUCHA DEL SERVIDOR : 12000Si solo eres un cliente — conectándote a la tarjeta de otra persona — no necesitas esto. El puerto solo necesita estar abierto/redirigido en tu enrutador si se esperan conexiones entrantes.
Para la resiliencia de la conexión, añade:
RECONEXIÓN EN TIEMPO DE ESPERA : síClave DES / Casos de Línea N y Cuándo Aplican
La mayoría de las líneas DRE Crypt modernas utilizan el protocolo de línea C de CCcam, que se basa en la conexión y no requiere una clave DES. Pero si te estás conectando a un servidor newcamd en su lugar, usarás una línea N con esa clave de 14 bytes. La clave se ve como una secuencia de pares hexadecimales:01 02 03 04 05 06 07 08 09 10 11 12 13 14. Estas deben coincidir exactamente con lo que el servidor espera. Un solo byte incorrecto significa un fallo de autenticación silencioso — sin mensaje de error, simplemente no se procesan ECMs.
Si no estás seguro de qué protocolo necesitas, pregunta a la fuente. Las líneas C de CCcam son más comunes para este proveedor.
Reiniciando el Demonio y Confirmando la Conexión
Después de editar, reinicia CCcam:
killall -9 CCcam&& sleep 2&& /etc/init.d/softcam restartO en imágenes con gestor de softcam:
/etc/init.d/softcam reiniciarDale de 10 a 15 segundos, luego verifica la página de información web enhttp://<box-ip>:16001. Una línea conectada muestra sus tarjetas activas y el conteo de saltos. Salto 1 significa una tarjeta directa; salto 2 significa que tu servidor la obtuvo de otro servidor. Si la tarjeta aparece pero los canales de Tricolor siguen en negro, el CAID no coincide — lo cual OScam maneja mucho mejor.
Configurando OScam para Tricolor
Los archivos de configuración de OScam se encuentran en una de tres rutas dependiendo de tu imagen:/etc/tuxbox/config/,/var/etc/oscam/, o/etc/oscam/. Los archivos con los que trabajarás sonoscam.conf,oscam.server,oscam.user, y opcionalmenteoscam.dvbapi. Cada uno maneja una parte distinta del sistema.
Bloque de lector oscam.server para un par de protocolo CCcam
Este es el bloque que define tu conexión a la fuente de intercambio de tarjetas:
[reader]Elcccversion campo debe coincidir con lo que el servidor CCcam remoto espera. La discrepancia de versión causa un fallo silencioso en el apretón de manos — la conexión parece completarse pero nunca se responden ECMs. Si sabes que el servidor ejecuta CCcam 2.1.4, establececccversion = 2.1.4. En caso de duda, 2.3.0 funciona con la mayoría de las implementaciones modernas.
Elinactivitytimeout de 30 segundos activará una reconexión si no fluye tráfico ECM. Eso está bien para la visualización activa. Establece un valor más alto (120–300) si ves bucles de reconexión innecesarios en los canales que miras continuamente.
oscam.user y configuración de cuenta
Si OScam también está sirviendo a clientes locales de Enigma2 a través de dvbapi, necesitas una cuenta de usuario. Enoscam.user:
[account]Restringiendo la cuenta al CAID4AE1 y ident4AE1:000000 impide que esta cuenta solicite ECMs para sistemas de cifrado que no debería tocar. Mantiene los registros limpios y hace que la solución de problemas sea más rápida.
oscam.conf Webif, Puertos y Configuraciones Globales
La configuración principal enoscam.conf:
[global]La webif es tu interfaz de diagnóstico principal. Accede a ella enhttp://<box-ip>:8888. La pestaña Live Log muestra la actividad de decodificación de ECM en tiempo real. La pestaña Readers muestra el estado de conexión para cada entrada en oscam.server. Restringehttpallowed a tu rango de LAN.
Una cosa que molesta a la gente: si el reloj de la caja está mal, la lógica de keepalive de OScam y el apretón de manos adyacente a TLS pueden romperse silenciosamente. Los lectores parecen conectados pero los ECMs se agotan. Ejecutadate en la caja y verifica que coincida con UTC. Agrega una sincronización NTP a tus scripts de inicio si es necesario.
Mapeo de los CAID y IDs de Proveedor de Tricolor
Enoscam.dvbapi (si usas dvbapi para la integración de Enigma2):
[dvbapi]LaP: línea establece la prioridad — OScam usará el lector que coincida con el CAID4AE1 y ident000000 primero. Si tienes tanto una tarjeta local como un lector remoto que reclaman este CAID, este archivo determina cuál recibe la solicitud de ECM. Sin una prioridad explícita, OScam toma su propia decisión, que a menudo es la incorrecta cuando también hay una tarjeta local presente.
Leyendo el Registro de OScam para Confirmar la Decodificación de ECM
Monitorea el registro en vivo:
tail -f /tmp/.oscam/oscam.logUna decodificación de ECM que funciona se ve así:
2026/06/24 14:23:01 s ECM 4AE1/000000 por tricolor_reader (125 ms)Ese número de 125 ms es tu tiempo de ida y vuelta de ECM. Menos de 300 ms está bien para la mayoría del contenido. Más de 600 ms causará congelamientos visibles. Más de 1000 ms y los canales se vuelven inobservables. Si vesECM no encontrado en su lugar, el lector tiene la conexión pero la tarjeta remota no tiene ese paquete — desajuste de CAID o problema de derecho de paquete.
Solucionando Pantallas Negras, Congelamientos y Sin Decodificación
La forma más rápida de diagnosticar un problema es mapear tu síntoma a una causa. Aquí está la tabla con la que trabajo:
| Síntoma | Causa probable | Dónde buscar |
|---|---|---|
| Pantalla negra, sin ECM en el registro | La caja no sintoniza el transpondedor encriptado / filtro CAID incorrecto | Información del servicio en el receptor, configuraciones de dvbapi |
| Pantalla negra, "ECM no encontrado" en el registro | La tarjeta remota carece de paquete / desajuste de CAID o ident | CAID/ident del lector en oscam.server, preguntar a la fuente |
| Congelamiento cada 3–10 segundos | Alta latencia de ECM o configuración de intervalo/cache de ECM | valores de ms en oscam.log, ping de red al servidor |
| Bucle de reconexión constante | inactivitytimeout demasiado bajo / fallo de keepalive | inactivitytimeout en oscam.server, sincronización del reloj de la caja |
| Intermitente negro en un CAID | Dos lectores compitiendo, dvbapi elige el incorrecto | reglas de prioridad de oscam.dvbapi |
| Todos los canales de Tricolor en negro, otros funcionan | Cambio de versión/clave de CAID por parte del proveedor | Verificar noticias del proveedor, actualizar ident |
El canal permanece negro: ECM no encontrado vs no solicitado
Estos son dos problemas diferentes. Si no aparece ninguna solicitud de ECM en el registro cuando sintonizas un canal de Tricolor, la caja no está enviando la solicitud en absoluto. Verifica que dvbapi esté habilitado, que el filtro CAID no esté bloqueando4AE1, y que estés sintonizando la posición de satélite correcta (36E, no 19.2E o 13E).
Si el registro muestra solicitudes de ECM pero regresan "no encontrado", la tarjeta de upstream no tiene ese paquete. No tiene nada que ver con tu configuración: la fuente simplemente no lo tiene. Verifica que tu línea cubra el paquete específico de Tricolor que intentas ver.
La imagen se congela cada pocos segundos
El congelamiento que se alinea con el intervalo de ECM (cada 8–12 segundos es típico para DRE Crypt) casi siempre significa que la decodificación está ocurriendo demasiado lentamente. Observa la cifra de ms en el registro de OScam durante unos minutos. Si ves consistentemente 800 ms+, el problema es la latencia de red hacia el servidor. Un servidor geográficamente más cercano solucionará esto más rápido que cualquier cambio de configuración.
Si la latencia parece bien pero aún así se congela, verifica la configuración de caché de ECM en oscam.conf:
[cache]Habilitar la caché significa que un ECM repetido del mismo canal se responde desde la memoria en lugar de ir por la red nuevamente. Reduce significativamente la frecuencia de congelamiento en líneas estables.
Caídas de conexión y bucles de reconexión
Si el registro muestra ciclos repetidos de conexión/desconexión cada 30–60 segundos, elinactivitytimeout se activa en un canal que no estás viendo activamente. Aumenta a 120 o 300. Si las reconexiones ocurren en medio de la visualización, tienes un problema de red: pérdida de paquetes, tiempo de espera de NAT o un servidor sobrecargado.
La sincronización del reloj de la caja es otro asesino silencioso aquí. Si/etc/localtime está incorrecto por más de un minuto o dos, alguna lógica de apretón de manos del lado del servidor interpreta las marcas de tiempo como inválidas y corta la conexión. Un reloj incorrecto que causa esto es frustrante de diagnosticar porque el error no aparece en el registro de OScam.
Prioridad de CAID incorrecta y lectores en competencia
Este problema afecta a las personas con una tarjeta local y una línea remota que cubren el mismo CAID. OScam elige el lector basado en las reglas de prioridad, y si esas reglas no están establecidas explícitamente, podría preferir consistentemente la línea remota (que es más lenta) sobre la tarjeta local. Peor aún, si la línea remota tiene el CAID en su perfil pero la tarjeta remota no tiene el paquete específico de Tricolor, obtienes "ECM no encontrado" mientras tu tarjeta local permanece inactiva.
Conjuntopreferlocalcards = 1 en[global] y usa prioridad explícita enoscam.dvbapi. Si quieres que la línea remota sea primaria y la tarjeta local como respaldo, invierte los números del grupo de lectores y configura la prioridad de dvbapi en consecuencia.
Problemas con Firewall, NAT y Port-Forwarding
La mayoría de los usuarios domésticos son clientes de CCcam: su caja se conecta saliendo a un servidor. Las conexiones salientes no requieren reenvío de puertos. Pero si tu caja es el servidor y otro dispositivo se conecta entrante, el puerto 12000 (o el que hayas configurado) debe ser reenviado a través de tu router a la IP LAN de la caja.
El problema más grande es el CGNAT del ISP. Si tu ISP te asigna una IP pública compartida (común con operadores móviles y algunos ISPs de fibra), las conexiones entrantes son imposibles sin un túnel VPN o un servicio de retransmisión. Verifica sitraceroute a tu IP pública muestra más de un salto de direcciones privadas RFC1918: eso es CGNAT. Las configuraciones de cliente solo salientes funcionan bien detrás de CGNAT. Las configuraciones de servidor entrantes no, punto.
Cómo evaluar una fuente de compartición sin quemarse
La configuración técnica es solo la mitad de la historia. Una configuración perfecta de OScam conectada a una fuente basura seguirá produciendo pantallas negras y congelamientos. Aquí hay lo que debes buscar antes de comprometerte a cualquier línea para elconfiguración de compartición de tarjetas Tricolor (CCcam/OScam) que estás ejecutando.
Criterios genéricos: Tiempo de actividad, Tiempo de ECM, Ubicación del servidor, Conteo de saltos
El tiempo de ECM es la medida más objetiva de calidad. Menos de 200 ms es excelente. 200–400 ms es aceptable. Más de 600 ms causa problemas visibles. Ejecuta un canal durante una hora y observa los valores de ms en tu registro de OScam: no solo lo verifiques durante 30 segundos.
La ubicación del servidor importa debido a la latencia física. Un servidor en Europa del Este tendrá tiempos de ida y vuelta más bajos a una caja en Rusia o países de la CEI que un servidor en América del Norte. La geografía supera al ancho de banda cada vez para la compartición de tarjetas.
Conteo de saltos: el salto 1 significa que la propia tarjeta del servidor está respondiendo a tus ECM. El salto 2 significa que los está obteniendo de otro servidor. Cada salto añade latencia y un posible punto de fallo. Prefiere fuentes de salto 1. Cualquier cosa por encima del salto 2 es una señal de alerta.
Señales de alerta en ofertas y líneas
Si una línea afirma cubrir cada paquete de satélite a través de múltiples proveedores a un costo increíblemente bajo, sé escéptico. Una sola tarjeta solo cubre los paquetes a los que esa tarjeta está realmente suscrita. Una línea que promete Tricolor full HD, además de varios otros proveedores importantes, más actualizaciones gratuitas está compartida entre docenas de usuarios (lo que destruye el tiempo de ECM bajo carga) o es simplemente fraudulenta.
También presta atención a: no se ofrece período de prueba, negativa a compartir la ubicación/región del servidor, y líneas que requieren que configures puertos inusuales o ejecutes scripts que no escribiste. Las fuentes legítimas te permiten probar antes del pago y no te piden que ejecutes código desconocido.
Probando una línea antes de confiar en ella
Configura la línea en OScam como un solo lector. Abre el registro contail -f /tmp/.oscam/oscam.log. Sintoniza cinco canales diferentes de Tricolor a través de diferentes transpondedores. Registra el tiempo de decodificación de ECM para cada uno. Luego deja un canal funcionando durante 60 minutos y cuenta cuántos eventos de reconexión aparecen en el registro.
Haz una prueba de estrés de cambio de canal: pasa rápidamente por 10 canales. Cada cambio activa una nueva solicitud de ECM. Si obtienes decodificaciones consistentes por debajo de 400 ms en todos los canales, la línea es sólida. Si ves congelamientos de 3 segundos en cada cambio de canal, el servidor está sobrecargado o geográficamente inadecuado.
Una sesión de prueba no es suficiente. Los proveedores a veces limitan IPs desconocidas durante los períodos de evaluación. Realiza la prueba en diferentes momentos del día, incluyendo las horas pico de la tarde cuando el servidor está bajo carga máxima.
Hecho correctamente, el proceso completo deconfiguración de compartición de tarjetas Tricolor (CCcam/OScam) — desde la verificación de hardware hasta la configuración y evaluación de la línea — toma un par de horas la primera vez. Después de eso, la mayoría de los problemas se reducen a tres cosas: CAID/ident incorrecto, alta latencia de ECM, o una fuente que simplemente no tiene el paquete que necesitas. El registro de OScam te dice cuál es en segundos.
¿Qué CAID usa Tricolor y por qué importa para mi configuración?
Tricolor utiliza cifrado DRE Crypt / DGCrypt en Eutelsat 36E. El CAID principal es0x4AE1, con algunos transpondedores usando0x4AE5. Cada solicitud de ECM que envía tu caja incluye este CAID: si el lector en tu configuración de CCcam o OScam no coincide, la caja nunca envía la solicitud o la envía a un lector que no puede responderla. Para confirmar el CAID activo en tu caja, sintoniza un transpondedor de Tricolor y abre el panel de información del servicio (mantén presionado el botón de información). El campo de descriptor de CA mostrará4AE1 si estás en el servicio correcto. Si muestra algo diferente, estás en la posición de satélite incorrecta o mirando un transpondedor de acceso libre.
¿Debería usar CCcam u OScam para compartir la tarjeta Tricolor?
Para la configuración inicial, CCcam es más rápido: pega una C-line, reinicia, listo. Pero para cualquier cosa que implique solución de problemas, OScam es la mejor herramienta por un amplio margen. OScam registra cada solicitud de ECM con tiempos, atribución de lector y razones de fallo. Cuando los canales de Tricolor se congelan o se ponen en negro, OScam te dice en el registro si el problema es un desajuste de CAID, un paquete faltante, alta latencia o un problema de reconexión. CCcam casi no te da esa visibilidad. Si ya estás experimentando fallos de decodificación o congelaciones, cambia a OScam. El tiempo extra de configuración se recupera inmediatamente en capacidad de diagnóstico.
¿Cuál es el puerto predeterminado y dónde se encuentra el archivo de configuración?
CCcam escucha en el puerto12000 por defecto, configurado a través deSERVER LISTEN PORT : 12000 en la configuración. La página de información web se ejecuta en el puerto16001. El archivo de configuración está en/usr/keys/CCcam.cfg en la mayoría de las imágenes de Enigma2, con/etc/CCcam.cfg como alternativa. La interfaz web de OScam tiene como puerto predeterminado8888, configurado en el[webif] bloque deoscam.conf. Los archivos de configuración de OScam se encuentran en/etc/tuxbox/config/ en imágenes más antiguas o/var/etc/oscam/ en las más nuevas. Si no estás seguro de qué ruta utiliza tu imagen, ejecutafind / -name oscam.conf 2>/dev/null.
¿Por qué mis canales de Tricolor se congelan cada pocos segundos?
Casi siempre es latencia de red o un alto tiempo de ida y vuelta de ECM. Abre tu registro de OScam y observa la cifra en milisegundos en cada línea de decodificación de ECM: cualquier cosa por encima de 500–600 ms causará congelaciones visibles. Menos de 300 ms está bien. La solución suele ser un servidor geográficamente más cercano, no un cambio de configuración. Si la cifra de ms parece aceptable pero aún así se congela, verifica la configuración de caché de ECM enoscam.conf y asegúrate de que no haya lectores en competencia que estén ralentizando el despacho de ECM. Un conteo de saltos superior a 2 también añade latencia acumulativa: cada salto adicional añade el tiempo de ida y vuelta de ese enlace a tu tiempo total de ECM.
El canal está en negro pero otros canales encriptados funcionan — ¿qué está mal?
Tres causas probables. Primero, verifica el registro de OScam para "ECM no encontrado": esto significa que la solicitud salió, pero la tarjeta remota no tiene ese paquete específico de Tricolor. Segundo, busca que no haya solicitud de ECM en absoluto: esto significa que dvbapi no está enrutando la solicitud a ningún lector, a menudo debido a un desajuste de filtro de CAID/ident en tu bloque de lector o usuario. Tercero, si tienes múltiples lectores cubriendo CAID4AE1, dvbapi puede haber enviado la solicitud a un lector muerto o incorrecto. Establece una prioridad explícita enoscam.dvbapi con unaP: 4AE1:000000 línea para controlar qué lector lo maneja.
¿Cómo confirmo que mi línea está realmente conectada antes de probar los canales?
Para CCcam, abre la página de información web enhttp://<box-ip>:16001. Una línea conectada muestra el servidor remoto, las tarjetas activas y el conteo de saltos. No hay tarjeta listada significa que la conexión falló o que las credenciales son incorrectas. Para OScam, abre el webif enhttp://<box-ip>:8888 y verifica la página de Lectores — la columna de estado muestra si el lector está conectado y cuándo tuvo actividad por última vez. También puedes ejecutartail -f /tmp/.oscam/oscam.log y observar una entrada de registro de apretón de manos exitoso inmediatamente después de reiniciar. Un apretón de manos exitoso de CCcam en los registros de OScam muestra el nombre del servidor remoto y el conteo de tarjetas. Si ves ciclos de conexión/desconexión repetidos, revisa nuevamente las credenciales y elcccversion parámetro.