Configuración de Focus SAT CCcam/OScam& Solución de Problemas

Si estás ejecutando un servidor softcam y tus canales de focus sat siguen apareciendo en una pantalla negra, congelándose cada pocos segundos, o mostrando errores ECM en el registro, el problema casi con seguridad no es tu antena. Nueve de cada diez veces es un bloque de lector mal configurado, un CAID desajustado, o un tiempo de espera que está estrangulando CWs válidos o esperando tanto que el canal ya está a medio congelarse antes de que llegue la clave.

Este artículo es para personas que ya están en medio de la configuración — tienes una línea, tienes un servidor funcionando, y algo específico está roto. El paquete de focus sat se encuentra principalmente en Hot Bird 13E y Thor 0.8W/1W dependiendo de tu región, y la configuración de encriptación tiene algunas peculiaridades que confunden incluso a configuraciones experimentadas.

Comienza capturando el CAID en vivo antes de tocar cualquier otra cosa. Los valores estáticos que encuentras publicados en foros son poco fiables — los operadores los rotan, y una configuración que funcionaba anteriormente puede fallar silenciosamente de la noche a la mañana.

Identificando el CAID de Focus SAT y los IDs de Proveedor

Aquí es donde la mayoría de la gente salta adelante y luego pasa horas solucionando lo incorrecto. El CAID y el ID de proveedor son la base — si los obtienes incorrectos, nada a continuación funcionará, sin importar cuán limpia se vea tuoscam.servidor.

Leyendo CAID/proveedor desde la pantalla de información del canal

Sintoniza un canal de focus sat encriptado que sabes que debería desencriptarse. En la mayoría de las imágenes de Enigma2, presiona el botón de Info dos veces o mantén presionado para obtener la vista de detalles técnicos. Quieres la línea del sistema CA — mostrará algo como0B00:000000 o un par hexadecimal similar. La primera mitad es el CAID, la segunda es el ID de proveedor.

En OpenPLi y OpenATV, la pantalla de información extendida (generalmente accesible a través del botón azul> Señal) listará los descriptores CA activos en el PMT. En imágenes de Vuplus que ejecutan Black Hole, los mismos datos están bajo Menú> Información> Estado de Sintonización. La ruta exacta varía según la piel, pero cada imagen moderna de Enigma2 expone esto en algún lugar.

Escribe los valores hexadecimales exactos. No asumas. El ID de proveedor en particular varía entre transpondedores que transportan el mismo paquete, y obtenerlo incorrecto es la causa más común de que un canal aparezca como FTA pero congelado.

Confirmando el CAID con OScam webif (Lector> Derechos)

Si tienes el OScam webif en funcionamiento (puerto predeterminado 8888), ve a Lectores y haz clic en tu lector activo. La pestaña de Derechos muestra lo que la tarjeta o línea realmente expone. Cruza esto con lo que reportó el receptor.

La herramienta de diagnóstico más útil es el registro en vivo. Busca en el registro de OScam la actividad ECM en ese canal:

grep -i ecm /var/log/oscam/oscam.log | tail -50

O si estás ejecutando oscam con el registro yendo a stdout a través de tu sistema init:

journalctl -u oscam -f | grep -i "ecm\|caid\|reader"

Cada línea de ECM te da el triplete completo CAID:provid:srvid — por ejemplo0B00:004A01:1234. El ID de servicio (srvid) es específico del canal. El provid es lo que necesitas en elident campo de tu lector.

Por qué el CAID incorrecto hace que los canales aparezcan como FTA-pero-congelados

Aquí hay un escenario que atrapa a la gente: el canal tiene un componente no encriptado (como una ventana de vista previa gratuita o una frecuencia de transpondedor diferente que transporta el mismo servicio FTA). El receptor se bloquea en él, el canal parece reproducirse, y luego se congela o pixeliza porque la transmisión principal está encriptada y no está llegando ninguna CW.

También observa los canales que son FTA en un transpondedor y encriptados en otro que transporta el mismo ID de servicio. Si tu escaneo captó primero la versión FTA, el receptor podría dirigir las solicitudes ECM a la entrada incorrecta en su lista de canales. Eliminar y volver a escanear solo el transpondedor encriptado generalmente soluciona esto.

Si el registro de OScam muestra que la solicitud ECM está llegando pero no se encuentra un lector coincidente, o muestra que el lector la rechaza, eso es un desajuste de CAID o ident — no un problema de red.

Configuración del Lector y ECM de OScam

Los archivos de configuración de OScam viven en diferentes lugares dependiendo de tu imagen. En OpenPLi, típicamente es/etc/tuxbox/config/oscam/. En imágenes que utilizan el diseño tuxbox, podría ser/var/config/oscam/. En algunas compilaciones de OpenATV lo encontrarás bajo/etc/oscam/. Verifica a dónde apunta tu instancia en ejecución con:

ps aux | grep oscam

El-c argumento en la línea del proceso te indica el directorio de configuración.

bloque de lector oscam.server: caid, ident, grupo

Aquí hay un bloque de lector limpio como punto de partida para un protocolo remoto compartido — esto cubre newcamd ycccam lectores, ajusta la línea del protocolo según sea necesario:

[reader]

Elident línea es la que la mayoría de las configuraciones se equivocan. Necesita el prefijo CAID seguido de dos puntos y el ID del proveedor que capturaste del registro en vivo. Si el proveedor tiene múltiples ID activos, enuméralos separados por comas:ident = 0B00:004A01,004A02.

Elgrupo valor necesita coincidir con el grupo asignado al usuario en oscam.user — esa discrepancia de grupo es la otra causa principal de entradas de "no hay lector coincidente" que la gente persigue durante horas.

oscam.user con au y vinculación de grupo

Tu cuenta de usuario enoscam.user necesita el mismo número de grupo y el alcance CAID correcto:

[account]

Si tienes múltiples lectores en diferentes grupos, el usuario necesita estar en el grupo que contiene el lector que lleva este paquete. Si el lector está en el grupo 1 y el usuario está en el grupo 2, OScam registrará el ECM como entrante pero no tendrá dónde enrutarlo. La entrada del registro se ve como "no hay lector coincidente" o "rechazado" — no es un fallo de autenticación, solo un error de enrutamiento.

Configurando el tiempo de espera de ECM y el comportamiento de reintento lb_ en oscam.conf

Abreoscam.conf y encuentra la[global] sección. Los valores clave:

[global]

Ellb_mode = 1 habilita el balanceo de carga por tiempo de respuesta de ECM. Esto es lo que deseas cuando tienes múltiples lectores — preferirá el más rápido. Pero si configuraslb_nbest_percaid demasiado alto (3 o 4) comenzará a sondear lectores lentos o muertos innecesariamente, lo que en realidad aumenta la frecuencia de congelamiento durante la carga máxima. Comienza en 1 y súbelo solo si has confirmado que los lectores redundantes funcionan.

lb_retrylimit en milisegundos le dice a OScam cuándo considerar que un lector es demasiado lento y probar otro. 800 ms es razonable para un lector de red local de baja latencia. Para pares remotos con RTT variable, empuje esto a 1200–1500 ms. Configurarlo en 200 ms en un lector remoto hará que intente constantemente y alcance el tiempo de espera.

La anulación por CAIDlb_retrylimits = 0B00:1200 le permite ajustar específicamente para este paquete sin afectar a otros.

Manejo de caché y CW para salida estable

La caché de CW de OScam (cwcache) puede causar una clase específica de congelamiento: el receptor obtiene un CW válido, reproduce bien, cambias de canal y vuelves, y está negro durante unos segundos. Esa es la caché sirviendo un CW obsoleto de la sesión anterior en el mismo SRVID. La clave criptográfica ha rotado, pero la caché no ha expirado.

Si ves este patrón específicamente en cambios de canal, añade aoscam.conf:

[cache]

Un tiempo de vida de caché de 15 segundos suele ser seguro para períodos de rotación de CW estándar de 10 segundos. Ir más alto corre el riesgo de servir claves obsoletas.

Configuración de CCcam y Prioridad de Línea

Si estás usando CCcam en lugar de OScam como tu softcam principal, la configuración se encuentra en/etc/CCcam.cfg. La sintaxis es diferente, pero los conceptos son los mismos: necesitas decirle a CCcam qué CAID enrutar a través de qué conexión, y necesitas controlar el comportamiento de salto.

Conceptos básicos de C-line y F-line en CCcam.cfg

Una C-line es tu conexión de cliente saliente a un servidor de compartición. Una F-line es un par entrante que tiene permiso para conectarse a ti. Para decodificar el paquete necesitas una C-line:

# Conectar a un servidor de compartición

El puerto 12000 es el predeterminado de CCcam y la mayoría de los servidores lo utilizan. Si te estás conectando a unnewcamd servidor en su lugar, usa una N-line con el puerto 15050 (también un predeterminado común). Verifica que tu línea esté realmente conectada accediendo a la página de información de CCcam — típicamente enhttp://receiver-ip:16001 — y revisando la sección de Servidores Conectados. Verde significa conectado, rojo significa que la conexión falló.

Uso de prioridad de CAID/ident y líneas de ignorar

CCcam tiene directivas P: (prioridad) e I: (ignorar) que dirigen el enrutamiento para CAIDs específicos. Si tienes múltiples C-lines y una es claramente mejor para este paquete, usa:

# Priorizar este servidor para CAID 0B00

Sin estas directivas, CCcam hace un round-robin entre los servidores conectados y obtendrás tiempos de decodificación inconsistentes. Durante las horas pico, cuando un servidor se degrada, esto causa congelamientos intermitentes que parecen aleatorios pero que en realidad están relacionados con la carga.

Forzar un salto de lector específico para el paquete

El conteo de saltos es muy importante para la fiabilidad de la decodificación. Un lector de salto-1 significa que la tarjeta está conectada directamente al servidor con el que estás hablando. Salto-2 significa un relé entre tú y la tarjeta. En mis pruebas, salto-1 y salto-2 son generalmente buenos para una decodificación estable. Salto-3 y superiores introducen variación de latencia que se manifiesta como congelamientos durante la rotación rápida de ECM.

CCcam expone información de salto en su página de estado. Bajo Tarjetas Conectadas, verás el conteo de saltos para cada entrada de CAID. Si el paquete muestra salto-4 o superior, ese servidor no está obteniendo su tarjeta directamente — está retransmitiendo a través de múltiples nodos. O encuentra una mejor fuente o acepta la inestabilidad.

También puedes limitar qué saltos usará CCcam:

ALLOW SIDMAPPING = no

ElIGNORE RESHARE DISTANCE ajuste le dice a CCcam que rechace los CW que llegan desde más de N saltos de distancia. Configurarlo en 2 filtra la basura de alto salto a costa de reducir tus opciones de respaldo.

Solución de problemas de Congelamientos, Pantallas Negras y Errores de ECM

Antes de culpar al softcam, siempre descarta la señal primero. Sintoniza un canal de libre acceso en el mismo transpondedor. Si eso también está pixelando o cayendo, tu problema es LNB/plato, no configuración. Solo comienza a depurar el softcam una vez que hayas confirmado que el transpondedor está bloqueado y los canales FTA están limpios.

Lectura de tiempos de respuesta de ECM en el registro

OScam registra los tiempos de respuesta de ECM en milisegundos en cada línea de CW. Una decodificación saludable se ve así:

2026/06/03 21:14:02 c [SRVID 1234] ECM respondió (0B00/004A01) por focus_peer1 (220ms)

Menos de 400ms es sólido. 400–1000ms es marginal pero generalmente está bien para una rotación de CW de 10 segundos. Cualquier cosa que golpee repetidamente 3000ms+ significa que el lector está teniendo problemas. Si ves 9000ms seguido de un tiempo de espera, el lector se rindió — ahí está tu congelamiento.

El patrón a observar es CW encontrado pero llegando tarde. El canal parece reproducir, luego se detiene cada vez que la clave rota. OScam encontró el CW, pero tomó 2800ms en una ventana de 2500ms. La solución es una fuente de lector más rápida o un ecmtimeout más alto para dar más tiempo a los lectores lentos.

Solucionando entradas recurrentes de 'sin lector coincidente' / 'rechazado'

Si el registro muestra consistentemente "sin lector coincidente" para un par específico de CAID:provid, trabaja en esto en orden:

1. Verifica que el bloque del lector en oscam.server tenga el correctocaid yident valores que coincidan con lo que capturaste en vivo
2. Verifica que elgrupo del lector coincida con elgrupo del usuario en oscam.user
3. Confirma que el lector esté realmente conectado — verifica la página de Lectores en webif para el estado "conectado"
4. Si usas cacheex, verifica si la caché está sirviendo un rechazo de un intento fallido anterior

"Rechazado" es diferente — generalmente significa que el lector se conectó pero la tarjeta o el servidor rechazaron activamente el ECM. Esto sucede cuando envías solicitudes de ECM para un CAID que el servidor no tiene, o cuando el filtro de ident en el extremo remoto está bloqueando tu solicitud.

Problemas de red y MTU sobre pares remotos

Este es fácil de pasar por alto. Si tus congelamientos ocurren específicamente en transmisiones HD y específicamente en pares remotos (no lectores de red local), la fragmentación de MTU es un fuerte candidato. Las transmisiones HD tienen cargas útiles de ECM más grandes, y un enlace remoto con MTU configurado en 1500 pero pasando por PPPoE o un túnel VPN con un MTU efectivo más bajo fragmentará esos paquetes. Los paquetes de CW fragmentados a menudo llegan incompletos, provocando un tiempo de espera.

Pruébalo:ping -M do -s 1472 your.peer.server. Si ves errores de "se necesita fragmentación", reduce tu MTU. En Linux, configúralo en la interfaz:

ip link set eth0 mtu 1400

O configúralo permanentemente en tu configuración de red. 1400 da suficiente margen para la mayoría de los sobrecostos de túnel. Después de cambiar, reinicia oscam y observa si los congelamientos solo en HD desaparecen.

Distinguiendo problemas de señal/LNB de problemas de softcam

Un árbol de decisiones rápido:

• Los canales FTA en el mismo transpondedor se congelan → problema de señal/LNB. Detente aquí, arregla tu antena.
• FTA bien, canales encriptados pantalla negra inmediatamente → softcam no conectando, probablemente desajuste de CAID o lector no conectado.
• Reproduce durante 10–30 segundos y luego se congela → tiempo de espera de rotación de CW. ECM es lento o falla en la rotación de la clave.
• Se congela solo durante la hora pico → servidor de origen sobrecargado. Fuera de pico está bien. Verifica los tiempos de ECM durante ambos períodos.
• Funciona después de reiniciar, se rompe después de cambios de canal → caché de CW obsoleta. Consulta la solución de cwcachetime arriba.

La propia caché de ECM del receptor también puede enmascarar problemas temporalmente. Algunos STB almacenan en caché el último CW válido durante unos segundos después de que expira. Esto hace que una configuración rota parezca funcionar justo después de un reinicio, y luego falle 10–15 segundos después una vez que la clave en caché expira y se necesita un ECM fresco.

Eligiendo una fuente de compartición confiable (Criterios genéricos)

Cuando evalúas cualquier fuente para el paquete focus sat — o cualquier paquete — los indicadores técnicos importan más que cualquier otra cosa. Una respuesta rápida de ECM a las 2 a.m. no significa nada si el servidor se derrite a las 8 p.m. cuando la mitad de sus suscriptores están en línea simultáneamente.

Indicadores de tiempo de actividad y estabilidad para probar

Ejecuta tu lector OScam durante al menos 24 horas antes de concluir que una fuente es estable. Observa los tiempos de respuesta ECM en estas ventanas específicas: 7–9am, 12–2pm, 6–10pm. La ventana de la tarde es donde las fuentes sobrecargadas muestran su verdadero rendimiento. Si ves que los tiempos ECM saltan de 180ms en horas no pico a 2400ms durante las horas pico, esa fuente te dará congelamientos cuando más importa.

OScam registra todo. Después de un día de funcionamiento, ejecuta:

grep "focus_peer1" /var/log/oscam/oscam.log | grep -v "not found" | awk '{print $NF}' | sort -n

Eso te da una distribución aproximada de los tiempos de respuesta para ese lector. Si el percentil 95 está por debajo de 800ms, estás en buena forma. Si está por encima de 2000ms, espera congelamientos.

Conteo de saltos y razonamiento de tarjeta local vs remota

Una fuente con acceso directo a la tarjeta (salto-1 en términos de CCcam) siempre superará a una cadena de reenvío bajo carga. La razón es simple: cada salto añade su propia latencia de procesamiento e introduce otro posible punto de falla. Durante la demanda máxima, una cadena de salto-3 podría estar esperando en dos nodos intermedios para procesar antes de que tu CW llegue.

Si tienes la opción, una fuente donde el operador tiene físicamente la tarjeta y el servidor está colocalizado con ella superará consistentemente a un reenvío. El RTT desde tu receptor hasta la tarjeta es lo que impulsa el tiempo ECM, y cada salto en la cadena se suma a eso.

Una configuración legítima significa que tú o tu fuente tienen derecho a la tarjeta que se está compartiendo. Ten eso en cuenta al evaluar opciones: usar una tarjeta a la que no tienes derecho es tanto un riesgo legal como técnico, ya que los operadores pueden detectar patrones de compartición e invalidar la tarjeta sin previo aviso.

Señales de alerta que predicen congelamientos

Aléjate de cualquier fuente que muestre estas:

• Tiempos de respuesta ECM que varían salvajemente — 150ms un minuto, 4000ms el siguiente — indica una conexión sobrecargada o inestable
• Conteo de saltos de 3 o más en el estado de CCcam
• Reconexiones frecuentes visibles en el registro de OScam (más de una vez por hora en condiciones normales)
• Sin respuesta a la combinación específica de CAID/provid que necesitas — el servidor está reenviando tarjetas que no cubren tu paquete
• Rendimiento que es estable durante una hora y luego se degrada — sugiere un límite de ancho de banda o un estrangulamiento de sesión que entra en acción

Y un caso extremo que vale la pena conocer: los operadores rotan periódicamente los IDs de proveedor para el paquete Focus sat y otros en Hot Bird. Si una configuración que funcionó bien durante meses de repente comienza a registrar "no hay lector coincidente" sin cambios de tu parte, verifica los valores CAID/provid en vivo nuevamente. Tu línea de ident puede estar apuntando ahora a un ID de proveedor obsoleto que el operador retiró.