Guía de configuración de OScam para Zgemma H9S - Config& Ajuste

Configurar oscam zgemma h9s correctamente es una de esas tareas donde la precisión importa. Si configuras mal, pasarás horas persiguiendo timeouts y errores de SID. Si lo haces bien, tienes una configuración de cardsharing estable y receptiva que realmente funciona. He visto suficientes implementaciones fallidas para saber qué falla y qué no.

El Zgemma H9S es un receptor capaz, pero no es una potencia. Tiene RAM limitada, un procesador ARM de gama media y limitaciones de almacenamiento que te muerden si no tienes cuidado. Eso significa que la forma en que configures oscam zgemma h9s importa más aquí que en hardware más potente. Esta guía cubre los pasos exactos, las trampas y el ajuste que necesitas para hacerlo funcionar correctamente.

Descripción general del hardware Zgemma H9S& Compatibilidad con OScam

Especificaciones del procesador y RAM

El H9S generalmente funciona en un procesador basado en ARM, generalmente una variante de doble núcleo cronometrada alrededor de 1.5GHz. La RAM es la verdadera limitación: estás mirando 512MB en la mayoría de las configuraciones, a veces ampliable a 1GB dependiendo de la revisión de la placa. Esos 512MB suenan bien hasta que comienzas a cargar listas de SID grandes y ejecutar múltiples lectores de red simultáneamente.

Cuando OScam arranca, analiza tu base de datos de SID en memoria. Una lista con 5,000+ SIDs puede consumir 100-150MB dependiendo de cómo la configures densamente. Agrega tres lectores de red con manejo de timeout, conexiones de cliente activas y logging: estás consumiendo la mitad de tu RAM solo para OScam. En hardware H9S específicamente, esto importa porque aún necesitas espacio libre para el SO principal del receptor y cualquier otro servicio.

Tipos de imagen y versiones de firmware soportadas

El H9S puede ejecutar múltiples tipos de imagen, pero las imágenes basadas en Enigma2 son donde OScam se ajusta más naturalmente. OpenPLi, variantes basadas en Openpli y compilaciones comunitarias típicamente incluyen OScam en sus repositorios de paquetes. Las imágenes más antiguas, particularmente las construidas antes de 2020, pueden carecer de las dependencias necesarias (versiones libc, bibliotecas SSL) para binarios OScam modernos.

Antes de instalar cualquier cosa, verifica qué versión de firmware estás ejecutando. SSH en la caja y verifica/etc/issue o mira el nombre de la imagen en el menú de configuración. Si tu imagen tiene más de tres años, probablemente encuentres errores de desajuste de arquitectura al intentar instalar OScam. El hardware es el mismo, pero las bibliotecas libc y tiempo de ejecución han avanzado.

Por qué H9S funciona bien con OScam

A pesar de las limitaciones de RAM, el H9S es sólido para OScam. El procesador ARM maneja solicitudes ECM lo suficientemente rápido para ver TV en tiempo real. El rendimiento de la red es decente para conexiones de lectores: Ethernet de gigabit significa baja latencia a tus fuentes de cardsharing. El almacenamiento, aunque limitado (generalmente 4-8GB), es suficiente para los binarios, configuración y registros de OScam si los administras adecuadamente.

El punto dulce es ejecutar oscam zgemma h9s con dos o tres lectores de red, 3,000-5,000 SIDs y caché activo. Si vas más allá, golpearás limitaciones de memoria. El hardware no se rompe en esos límites, es solo que H9S te obliga a ser selectivo acerca de lo que cargas.

Limitaciones de hardware a tener en cuenta

El slot CAM interno vale la pena mencionar. Si tu H9S tiene un lector de tarjeta inteligente física incorporada, necesitas decidir: usarlo con OScam o deshabilitarlo completamente. Dejarlo habilitado pero sin usar simplemente quema CPU y puede causar conflictos de lector si no tienes cuidado con la configuración. La mayoría de los usuarios en entornos donde ejecutarías oscam zgemma h9s usan configuraciones solo de red de todas formas.

El almacenamiento lleno es real. La partición /var donde viven los registros es a veces diminuta (100-200MB). El logging de OScam, si se configura en nivel DEBUG, puede llenarla en horas. Necesitarás rotación de registros o límites de tamaño en tu oscam.conf. De lo contrario, verás que OScam falla sin una razón clara: sistema de archivos lleno, no puede escribir registros, el proceso muere.

El throttling de CPU en H9S ocurre bajo carga sostenida. No es un problema fatal, pero si ejecutas muchas solicitudes ECM simultáneas (docenas de usuarios golpeando la caja), verás que el tiempo de respuesta sube. El caché ayuda aquí: más aciertos de caché significan menos viajes de solicitud ECM a tus lectores.

Instalación de OScam en Zgemma H9S paso a paso

Requisitos previos y herramientas necesarias

Necesitas acceso SSH a tu H9S. Eso es innegociable. Si SSH no está habilitado en la configuración, habilítalo ahora: Configuración de red → Servidor SSH. Las credenciales predeterminadas son generalmenteroot con contraseñadreambox, pero verifica la documentación de tu imagen porque algunas compilaciones cambian esto.

También necesitas saber qué gestor de paquetes usa tu imagen. Las imágenes basadas en OpenPLi usanopkg. Algunas otras compilaciones de Enigma2 usanapt. Comprueba ejecutando SSH y ejecutandoopkg --version oapt-get --version. Si ninguno funciona, tu imagen es demasiado antigua, necesitarás flashear una más nueva.

Finalmente, verifica que tengas espacio en disco. Ejecutadf -h / y verifica que /root o /home tenga al menos 20MB libres. Si tienes poco espacio, limpia logs antiguos o archivos temporales primero.

Acceso SSH y preparación del sistema de archivos

SSH con tus credenciales. Una vez conectado, crea los directorios de OScam si no existen. Para la mayoría de imágenes Enigma2 ejecutando oscam zgemma h9s, las rutas estándar son:

mkdir -p /etc/oscam

Establece propiedad y permisos para que OScam pueda escribir en estos directorios:

chown -R root:root /etc/oscam

Verifica que los directorios existan ejecutandols -la /etc/oscam/. Deberías ver un directorio vacío listo para archivos de configuración.

Descarga e instalación de binarios de OScam

El método más fácil es a través del gestor de paquetes de tu imagen. Intenta instalar desde el repositorio primero:

opkg update

Si eso tiene éxito, OScam se instala en la ruta del binario del sistema (generalmente/usr/bin/oscam o/usr/local/bin/oscam). Verifica conwhich oscam.

Si el paquete no está disponible en tu repositorio, necesitarás descargar el binario manualmente. Visita el repositorio oficial del proyecto OScam y descarga el binario ARM que coincida con la arquitectura de tu H9S. Extrae e coloca en/usr/local/bin/oscam. Hazlo ejecutable:

chmod +x /usr/local/bin/oscam

Prueba el binario ejecutando/usr/local/bin/oscam -h. Si ves el texto de ayuda, el binario es compatible. Si obtienes "command not found" o "cannot execute", tienes un desajuste de arquitectura: el binario fue compilado para una variante ARM diferente. Reflashea con una imagen más nueva e intenta de nuevo.

Verificación de instalación y verificación de registros del sistema

Antes de ejecutar OScam, verifica si hay instancias anteriores aún en ejecución. Múltiples procesos antiguos causan conflictos de puerto que son enloquecedores de depurar:

ps aux | grep oscam

Si ves procesos de OScam listados, mátalos:

killall -9 oscam

Ahora inicia OScam manualmente para detectar errores inmediatos:

/usr/local/bin/oscam -c /etc/oscam

Verifica los registros del sistema para mensajes de inicio:

tail -f /var/log/messages

Deberías ver a OScam inicializándose, vinculándose a puertos y cargando archivos de configuración. Si sale inmediatamente, verifica/var/log/oscam.log para detalles de error. Fallos de inicio comunes: archivos de configuración faltantes (oscam.server no encontrado), puerto ya en uso (otro servicio ejecutándose en 988) o errores de permisos (no puede escribir en /var/oscam).

Establecimiento de permisos de archivo correctos

OScam necesita leer configuraciones y escribir registros. Después de que los archivos de configuración estén en su lugar, verifica los permisos:

chmod 644 /etc/oscam/oscam.conf

Si OScam se ejecuta como root (que típicamente lo hace en H9S), los permisos de archivo son menos críticos, pero conseguirlos bien evita dolores de cabeza futuros si alguna vez cambias el usuario del servicio. Los archivos de registro deben ser legibles:

chmod 644 /var/log/oscam.log

Prueba ejecutandooscam -c /etc/oscam de nuevo. Si inicia limpiamente y se mantiene ejecutando durante 30 segundos sin salir, los permisos son probablemente correctos.

Archivos de configuración de OScam para H9S: configuración esencial

oscam.conf: configuración de puerto y protocolo del servidor

El archivo de configuración principal es/etc/oscam/oscam.conf. Aquí hay una línea base de trabajo para H9S:

[global]

El puerto 988 es el predeterminado para la escucha del protocolo CCcam. Aquí es donde los lectores remotos y clientes se conectan a tu H9S. Si algo más está usando el puerto 988, cámbialo, pero asegúrate de que tus lectores conozcan el nuevo puerto.

La clave es tu clave de cluster: una cadena hex de 32 bytes. La anterior es un ejemplo e insegura. Genera una real o déjala en blanco si usas protocolo newcamd exclusivamente. El directorio de caché almacena caché ECM: crucial para el rendimiento de H9S. Configúralo a /var/oscam que creaste anteriormente.

Maxlogsize limita el tamaño del archivo de registro en megabytes. En H9S con su pequeña partición /var, establecer esto a 1024MB es razonable. OScam rotará los registros cuando excedan este tamaño, evitando que se llene el sistema de archivos.

oscam.server: configuración de lector y filtrado de SID

Este archivo define tus lectores: las fuentes que suministran claves ECM. Aquí hay una plantilla con dos lectores de red:

[reader]

Reemplaza remote_ip y remote_port con direcciones reales de lectores. El campo de prioridad es crítico: los números más bajos se intentan primero. Si reader_primary es lento o está inactivo, OScam regresa a reader_backup (prioridad 2).

Los números de grupo mantienen lectores organizados. Mismo grupo significa que son pares para equilibrio de carga. Diferentes grupos significa jerarquía. Para H9S con conexiones limitadas, usar dos grupos (primario y respaldo) es limpio y simple.

CAID (ID de acceso condicional) filtra qué estándares de cifrado maneja el lector. CAID comunes: 0100 (Seca), 0500 (Viaccess), 1700 (NDS), 1801 (Nagravision). Lista los que tus lectores realmente proporcionan. Si listas CAID que el lector no tiene, verás errores de timeout cuando OScam solicita claves para esos CAID.

Timeout está en segundos. En H9S, lectores lentos sobre una red congestionada podrían necesitar timeouts de 8-10 segundos. Los lectores más rápidos y locales pueden usar 4-5 segundos. Si los timeouts son demasiado cortos, verás errores "CW not found". Demasiado largo y tu experiencia de TV se siente lenta.

Para filtrado de SID, agrega esto a oscam.server:

[reader]

El campo sids restringe cuál SIDs proporciona este lector. Sin él, se pregunta al lector por todos los SID que conoce. En H9S, estrechar esto por lector es inteligente: reduce el tráfico ECM y acelera los tiempos de respuesta. Si reader_primary solo maneja canales de HBO (SID específicos), lista solo esos.

oscam.user: control de acceso del cliente

Define cuáles clientes pueden conectarse a tu caja oscam zgemma h9s. Crea/etc/oscam/oscam.user:

[account]

El campo de grupo otorga acceso a lectores en esos grupos. Client1 puede usar lectores de los grupos 1 y 2. Client2 solo accede a lectores del grupo 1. Uniq = 0 significa que el mismo cliente puede iniciar sesión desde múltiples IPs. Uniq = 1 obliga una conexión por cliente, útil si quieres evitar compartir credenciales.

Cambia las contraseñas. No uses placeholders en producción. Si esta es una configuración personal de H9S, incluso la protección básica está bien. Si compartes acceso, contraseñas únicas y fuertes por usuario evitan accidentes.

oscam.srvid: asignaciones de ID de servicio

Este archivo asigna SID a nombres de canal legibles por humanos e información de CAID. Es opcional pero útil para la depuración. Crea/etc/oscam/oscam.srvid:

0100:0001:HBO East

El formato es CAID:SID:name. Cuando verificas logs o la interfaz web, verás "HBO East" en lugar de "0100:0001". En H9S, esto es principalmente cosmético, pero ahorra tiempo solucionando problemas. Puedes generar este archivo desde la lista de canales de tu imagen si está disponible.

Números de puerto y configuración de seguridad

El puerto 988 (CCcam) es el estándar. El protocolo Newcamd usa puertos en el rango 1024-1030. Si tu imagen H9S ya usa estos puertos para algo más, obtendrás errores "Address already in use".

Comprueba si hay conflictos:

netstat -tlnp | grep LISTEN

Si el puerto 988 está listado, cambia el puerto de escucha de OScam en oscam.conf a otra cosa (por ejemplo, 989). Asegúrate de que lectores y clientes remotos conozcan el nuevo puerto.

Seguridad: No expongas OScam directamente a internet sin firewall. Usa iptables para limitar conexiones o ejecuta OScam solo en tu LAN. Si debes exponerlo, usa contraseñas fuertes y considera whitelist de IP en tu firewall o router.

Selección de protocolo (CCcam vs. Newcamd vs. Radegast)

El protocolo CCcam es el más común para conectarse a lectores remotos. Es eficiente y ampliamente compatible. Úsalo a menos que tengas una razón específica para no hacerlo.

Newcamd es más antiguo pero sigue siendo confiable. Algunos lectores heredados solo lo soportan. Si tu lector dice "newcamd only", configura un lector de protocolo newcamd y especifica un puerto en el rango 1024-1030 en oscam.server.

Radegast es menos común. Algunos proveedores especializados lo usan, pero si estás comenzando con oscam zgemma h9s, quédate con CCcam o newcamd. La configuración de Radegast es más delicada y lenta en hardware H9S.

Solución de problemas& Ajuste de rendimiento para Zgemma H9S

OScam no inicia: códigos de error comunes y soluciones

Inicia OScam en primer plano para ver errores inmediatamente:

/usr/local/bin/oscam -c /etc/oscam

Escucha la salida. Fallos comunes:

"Address already in use": Otro proceso posee el puerto 988. Comprueba connetstat -tlnp | grep 988 y mata el proceso conflictivo. A veces las instancias antiguas de OScam no cierran limpiamente. Mata todas conkillall -9 oscam, entonces reinicia.

"Config file not found": oscam.conf u oscam.server faltante. Verifica que los archivos existan:ls -la /etc/oscam/. Si está vacío, copia o recrea desde ejemplos.

"Cannot bind to socket": Error de permisos o puerto debajo de 1024 sin root. Asegúrate de ejecutar como root:whoami debería mostrar "root". Si ejecutas como usuario de servicio, agrega ese usuario a sudoers o ejecuta OScam como root.

"libc not found": Desajuste de arquitectura binaria. Descarga el binario ARM correcto para tu variante H9S. Comprueba los detalles de tu imagen:cat /etc/issue debería decirte si es ARMv6, ARMv7 o ARMv8.

Uso alto de CPU/memoria en hardware H9S limitado

Monitorea el uso de recursos con:

top -n1 | head -20

O para monitoreo continuo:

htop

Si OScam consume 70%+ CPU consistentemente, estás sobrecargado. Causas: demasiados clientes activos, lista de SID demasiado grande o un lector atascado (no responde a solicitudes).

Reduce carga por:

• Corta la lista de SID. Mantén solo SID que realmente ves. Elimina canales antiguos o sin usar. Una lista de 3,000 SID usa aproximadamente 150MB. Escala hacia abajo en consecuencia.
• Aumenta valores de timeout. Si OScam está reintentando repetidamente lectores lentos, sube timeout en oscam.server. Un timeout de 5 segundos significa OScam intenta 12 veces por minuto por solicitud. Configúralo a 8-10 segundos para reducir tormentas de reintentos.
• Limita máximo de solicitudes ECM. Agrega a oscam.conf:max_pending_ecm = 100. Esto limita solicitudes simultáneas, evitando inundaciones de ECM descontroladas.
• Habilita caché ECM. OScam cachea respuestas ECM en /var/oscam. Asegúrate de que este directorio tenga espacio. Un acierto de caché evita una solicitud de red: crítico en H9S.
• Desactiva características sin usar. Si no usas la interfaz web, comenta [webif] en oscam.conf. Cada característica desactivada ahorra RAM.

Si la memoria está maxed (el comando free muestra poco disponible), OScam puede fallar sin memoria. Comprueba syslog para mensajes de asesino OOM:tail /var/log/messages | grep OOM. Si se encuentra, necesitas reducir el tamaño de la lista de SID o la cantidad de lectores.

Tiempos lentos de respuesta ECM y optimización de caché

El tiempo de respuesta ECM es qué tan rápido obtienes claves al sintonizar un canal. En H9S, una respuesta ECM saludable es menor a 300ms. Encima de 500ms se siente lenta.

Verifica oscam.log para tiempos de ECM:

grep "ECM" /var/log/oscam.log | tail -20

Busca entradas como "ECM from reader_primary in 125ms". Si la mayoría son lentas (500ms+), tus lectores están sobrecargados o lejos (alta latencia).

La relación de aciertos de caché es tu mejor amigo. Ejecuta:

grep "cache hit" /var/log/oscam.log | wc -l

Compara con solicitudes ECM totales. Una relación de aciertos alta (70%+) significa que estás obteniendo claves del caché local, no viajes redondos de red. Aquí es donde brilla el rendimiento de H9S.

Para mejorar los aciertos de caché:

• Ajusta el timeout de caché ECM. En oscam.conf, agregaecmcache = 30 (30 segundos). Las claves se cachean durante esta duración. Más corto significa claves frescas pero más fallos. Más largo significa claves antiguas pero mejor aciertos de caché. 20-30 segundos es un buen equilibrio.
• Ve canales populares. Los canales que sintonizas a menudo deberían cachear bien. Los canales raramente vistos tendrán relaciones bajas de aciertos de caché: eso es normal.
• Monitorea el tamaño del caché. Compruebals -lah /var/oscam/. Si los archivos de caché crecen grandes, el tráfico ECM es alto. Esto es una señal de que tus lectores o lista de SID están bien ajustados.

Problemas de conectividad de red: lector inalcanzable

Si un lector deja de responder, OScam reintenta hasta timeout. Durante esa ventana (timeout predeterminado 5-10 segundos), los canales en ese lector rebotan o se congelan. Los registros muestran "reader not responding".

Diagnostica:

ping remote_ip

Si ping falla, la conectividad de red está rota. Verifica router, firewall, DNS. Si ping funciona pero OScam no puede alcanzar el puerto del lector:

telnet remote_ip remote_port

Si telnet se detiene o rechaza, el puerto está cerrado o bloqueado por firewall. Verifica las reglas del firewall del lector: puede requerir tu IP de H9S en una lista blanca.

Si la conectividad es intermitente, agrega keepalive. En oscam.server, agrega al bloque de lector:

keepalive = 1

Esto envía pings periódicos para mantener la conexión viva. Útil para lectores que cierran conexiones inactivas.

Si un lector está temporalmente inactivo, establece un timeout alto y agrega un lector de respaldo con prioridad más baja. OScam saltará el lector muerto rápidamente y usará el respaldo.

SID no funciona o canales rebotando

Un canal "rebotando" es uno que constantemente alterna entre encriptado y desencriptado, o se congela intermitentemente. Generalmente significa que OScam no puede obtener un CW (palabra de control/clave) consistentemente.

Verifica oscam.log para el SID:

grep "0100:0001" /var/log/oscam.log | tail -50

Busca mensajes "CW not found", "no reader" o "timeout". Si el SID está listado en múltiples lectores, puede haber un conflicto. OScam intenta lectores en orden de prioridad. Si el lector de alta prioridad no tiene el SID, debería regresar al lector de respaldo, pero a veces falla si el lector no anunció el SID correctamente.

Solución:

• Verifica que el SID existe. Comprueba si los canales que usan ese SID se emiten realmente. Los canales removidos tienen SID muertos.
• Comprueba asignaciones de grupos de lectores. Asegúrate de que ambos lectores con el SID sean accesibles al cliente intentando verlo.
• Agrega filtrado de sids. Si reader_primary maneja el SID, agregasids = 0100:0001 al bloque de ese lector en oscam.server. Esto le dice a OScam que no pregunte a otros lectores por ello.
• Revisa logs para "CW error" o "bad CW". Si las claves no son válidas, el lector tiene un problema: no OScam.

Análisis de log: dónde buscar problemas

OScam registra todo en/var/log/oscam.log. Con logging verbose, es masivo: la rotación es obligatoria o tu disco se llena.

Patrones de búsqueda clave:

tail -f /var/log/oscam.log | grep -i "error"

Observa errores en tiempo real. Los errores de inicio, fallos de conexión de lector y errores de CW aparecen aquí.

grep "reader" /var/log/oscam.log | grep -i "timeout"

Esto muestra lectores que están agotando el timeout. Si es consistente, el lector es lento o inalcanzable.

grep "ECM" /var/log/oscam.log | grep -i "timeout"

Los timeouts de ECM significan que OScam esperó la ventana de timeout completa sin obtener una clave. Causas: lector sobrecargado, latencia de red o lector no tiene el SID.

grep "accepted\|connection" /var/log/oscam.log | wc -l

Cuenta conexiones activas. Si este número crece sin límite, tienes una fuga de conexión de cliente: clientes no desconectando limpiamente.

Para solución de problemas sostenida, establece el nivel de log a INFO en oscam.conf:

[global]

Esto reduce ruido en comparación con nivel DEBUG. Aún ves eventos importantes sin spam de log.

Procedimientos de reinicio y limpieza

Para reiniciar OScam con gracia, primero mata el proceso:

killall oscam

Espera unos segundos, luego reinicia:

/usr/local/bin/oscam -c /etc/oscam -d

El indicador -d daemoniza (ejecuta en segundo plano). Comprueba que inició:

ps aux | grep oscam

Si ves un proceso oscam, está ejecutándose. Comprueba los logs:

tail /var/log/oscam.log

Debería ver "OScam started" o similar.

Para reinicios automatizados, crea un trabajo cron. Si OScam tiende a atascarse después de horas, reinicialo noche:

0 2 * * * killall oscam 2>/dev/null; sleep 2; /usr/local/bin/oscam -c /etc/oscam -d

Agrega esto a crontab de root:crontab -e, pega la línea, guarda. Esto reinicia OScam a las 2 AM cada noche.

Para limpiar logs antiguos, usa logrotate. Crea/etc/logrotate.d/oscam:

/var/log/oscam.log {

This rotates logs daily, keeps 7 days of backups, and compresses old logs. OScam won't fill your disk.

Advanced: Multiple Readers & Load Balancing

Configuring Multiple Network Readers

Running three or more readers on H9S is possible but requires careful setup. Each reader consumes connection slots and memory. On limited hardware, more readers doesn't always mean better performance—diminishing returns kick in fast.

Here's a three-reader setup:

[reader]
label = primary
protocol = cccam
device = ip1,port1
username = user1
password = pass1
group = 1
priority = 1
timeout = 5
caid = 0100,0500
[reader]
label = secondary
protocol = cccam
device = ip2,port2
username = user2
password = pass2
group = 2
priority = 2
timeout = 8
caid = 0100,1700
[reader]
label = fallback
protocol = cccam
device = ip3,port3
username = user3
password = pass3
group = 3
priority = 3
timeout = 10
caid = 0500,1700

Each reader handles different CAIDs and has escalating timeouts. Primary (priority 1) is tried first. If it fails, secondary (priority 2) takes over. Fallback (priority 3) is a last resort—useful but slow.

Assign SIDs to specific readers to distribute load. If primary has HBO SIDs and secondary has Sky SIDs, OScam doesn't ask primary for Sky keys. This reduces cross-reader traffic and speeds up responses.

Priority and Fallback Settings

Priority controls which reader OScam asks first. Lower numbers = higher priority. For a given SID, OScam tries priority 1 first. If that times out, it tries priority 2, then 3.

Timeout is crucial here. If your primary reader consistently responds in 100ms, set timeout to 1-2 seconds. OScam will quickly determine it's not responding and try the next reader. Too long (10 seconds) and users experience lag while OScam waits.

For oscam zgemma h9s specifically, the priority mechanism is stable and works well. The challenge is matching timeout values to real network conditions. Start conservative: primary timeout = 3 seconds, secondary = 6 seconds, fallback = 10 seconds. Then monitor logs and adjust based on actual response times.

Add this to primary reader if it tends to be slow:

ignore_bad_cw = 1

This tells OScam to ignore occasionally bad keys from that reader. Helps when a reader has intermittent quality issues—OScam accepts most keys but filters obvious corruption.

SID Load Balancing Strategies

Two approaches: exclusive and shared SIDs.

Exclusive: Each SID is owned by one reader. In oscam.server, assign sids per reader. Primary handles SIDs 0001-0100, secondary handles 0101-0200. OScam never asks primary for a SID owned by secondary. This is the most efficient on H9S because it eliminates cross-reader queries.

Shared: Multiple readers can provide the same SID. OScam tries them in priority order. If primary fails, it asks secondary. This is more resilient if readers are flaky, but it costs more traffic and CPU. Avoid this on H9S unless readers are frequently unavailable.

For a balanced H9S setup with two readers, go exclusive:

[reader]
label = primary
sids = 0001,0002,0003,...,1000
[reader]
label = secondary
sids = 1001,1002,...,2000

Every SID is covered. OScam asks exactly one reader per request. Fast and lean.

Handling Reader Timeouts and Failover

When a reader times out repeatedly, OScam eventually marks it offline. During that window, failover to the next reader. The transition isn't instant—there's a timeout delay—but it works.

To test failover, simulate a reader outage:

iptables -A OUTPUT -d remote_ip -j DROP

This blocks traffic to the reader. OScam detects timeout, tries the backup reader, and channels should continue playing (with brief lag). Once you see failover working, undo the rule:

iptables -D OUTPUT -d remote_ip -j DROP

If failover doesn't work, check logs for fallback reader errors. Maybe it's not configured with the same SID. Add missing SIDs to the fallback reader block and restart OScam.

For production stability on H9S, keep timeouts reasonable (5-10 seconds) so failover happens before users notice. Overly short timeouts cause false positives—good readers get skipped due to network jitter.

Monitoring Reader Health

Check which readers are active via the web interface (port 8888 if enabled) or by scanning logs:

grep "reader" /var/log/oscam.log | grep -i "online\|offline" | tail -20

For continuous health monitoring, track response times:

grep "ECM from" /var/log/oscam.log | tail -100 | awk '{print $NF}' | sort -n

This shows ECM response times for the last 100 requests. If most are under 300ms, readers are healthy. If many exceed 1000ms, readers are overloaded or distant.

On H9S, automate this check with a cron job that restarts OScam if a reader hasn't updated in 10 minutes. Over-automation can cause instability, so use sparingly. A nightly restart is safer than minute-by-minute health checks.

FAQ Section