Best OScam Reader Setup: oscam.server Config Guide 2026

If you've ever stared at a fresh oscam.server file wondering why half the parameters even matter, you're not alone. Most guides just paste a working block and tell you to swap in your own credentials. That gets you connected. It doesn't get you decoding reliably, and it definitely doesn't explain why your reader shows "CARD OK" while every channel still throws an ECM error.

This is my attempt at an actual oscam reader setup best walkthrough — not a copy-paste block, but the reasoning behind each line so you can debug it yourself six months from now when something breaks at 2am. I've run OScam on everything from a Raspberry Pi 3 to a dedicated VPS, and the failure patterns repeat themselves constantly. Let's get into the file structure first, because that's where most confusion starts.

What an OScam Reader Actually Is (and How It Differs From an Account)

People throw around "account," "line," and "reader" like they're interchangeable. In OScam they're not. A reader is a source of ECM/EMM decoding — full stop. It can be a physical smartcard sitting in a Phoenix or Smargo device plugged into your box, or it can be a remote connection to someone else's card over a network protocol. Either way, from OScam's perspective, a reader is just something it can ask "can you decode this ECM for me?"

The confusion usually comes from mixing up the three config files that make an OScam install work. oscam.conf holds global settings — load balancing mode, logging, webif ports, that kind of thing. oscam.user defines the clients you serve, meaning the boxes or software connecting to your OScam instance. And oscam.server is where readers live — every card source, local or remote, gets a [reader] block in this file. Get this separation wrong and you'll spend hours editing the wrong file wondering why nothing changes.

Reader vs. account vs. user: the three config files

Think of it as a pipeline. A client connects using credentials defined in oscam.user. That user is assigned to a group. OScam then looks at oscam.server for any reader that shares that same group number and is capable of decoding the requested caid. If it finds one, the ECM gets forwarded to that reader — whether it's a local card or a peer three hops away — and the decoded CW comes back down the chain to the client.

That group linkage is the single most overlooked piece in every "oscam reader setup best" tutorial I've read. People configure a perfect reader block, forget to set the group number to match their user, and then spend an hour troubleshooting a phantom connection issue that was never a connection issue at all.

Local card readers vs. network (proxy) readers

A local reader talks to physical hardware — device = /dev/ttyUSB0 for a serial Phoenix reader, for example, with detect=CD or similar. A network reader, sometimes called a proxy reader, connects over TCP/IP to a remote OScam or CCcam server using a protocol like cccam, newcamd, or cs378x. Most people setting up cardsharing today are dealing almost entirely with network readers, since actual physical smartcard hardware has become less common outside of dedicated card farms.

Where readers live: oscam.server and its role in the pipeline

Every reader gets its own [reader] section in oscam.server, identified by a unique label. OScam parses this file at startup (or on reload via webif) and attempts to establish each reader connection independently. The "best" setup here isn't about cramming in every optional parameter — it's about writing tight, minimal, correctly scoped entries so OScam never wastes time or bandwidth querying a source that can't possibly answer.

Building the Ideal Network Reader in oscam.server

Here's a full annotated example for a cccam-protocol reader. I'll break down every line after.

[reader]label = provider1_hdprotocol = cccamdevice = 185.23.xx.xx,12000user = myusernamepassword = mypasswordgroup = 1caid = 0100,0500,0B00ident = 0100:XXXXXX,0500:YYYYYYcccversion = 2.3.2cccmaxhops = 2cccwantemu = 0inactivitytimeout = 30reconnecttimeout = 15ecmtimeout = 3000audisabled = 1

The device line is host,port — and I want to be clear, there's no universal standard port for cardsharing protocols. You'll see 12000 used commonly for cccam and something in the 5000s or 8000s range for newcamd or cs378x, but these are entirely operator-defined. Whoever runs the source tells you the port. Don't assume 12000 works everywhere just because it's common.

Full [reader] block: label, protocol, device, user, password, key

label is just an internal identifier — make it descriptive, since you'll be reading it in logs constantly. protocol tells OScam which handshake to use. device is host,port for network readers. user and password are your login credentials. For newcamd readers you'll also need a key= line holding the DES key, which I'll get to in a second because it trips up a lot of people.

Choosing protocol: cccam vs. newcamd vs. cs378x vs. mgcamd

cccam is the most common protocol for peer-to-peer sharing because so many boxes and panels speak it natively. newcamd is older but still widely supported, and it requires a DES key exchange — typically a 14-byte hex key, and if you paste it wrong (too short, extra whitespace, wrong case) the reader will often just sit there failing silently instead of throwing an obvious error.

cs378x is worth knowing about specifically if you're connecting two OScam boxes together — it's essentially camd35 over TCP with added message integrity checking, versus the older UDP-based camd35 which has none. If both ends run OScam, cs378x or newcamd tend to be cleaner and lower-overhead than cccam. mgcamd support exists mostly for backward compatibility with older boxes that only speak newcamd/cccam variants — you won't set protocol=mgcamd in oscam.server itself, since mgcamd is a client-side application, not an OScam reader protocol.

group, caid, ident and label routing for clean decode paths

This is the part almost every guide skips, and it's exactly why so many people end up with a reader that connects fine but never decodes anything. group ties the reader to specific users — if your user in oscam.user has group = 1 and your reader has group = 1, OScam considers that reader eligible to serve that client. No shared group number, no ECM ever reaches that reader, regardless of how correctly everything else is configured.

caid restricts which encryption systems the reader gets queried for. If you know your source only carries Viaccess (0500) and Nagravision (0100), don't leave caid blank — set it explicitly. ident goes a level deeper, narrowing to specific provider IDs within a caid, formatted as caid:ident pairs. Filtering aggressively here isn't just tidy configuration — it directly reduces ECM errors, because OScam stops wasting cycles asking a reader for channels it was never going to answer for in the first place.

cccversion, cccmaxhops, cccwantemu explained

cccversion needs to match what the peer expects — 2.3.0 and 2.3.2 are the common versions floating around. Mismatch this and you'll often see the reader connect successfully but report a wrong card count, or zero shares at all, which looks like a permissions problem but is actually a protocol handshake mismatch. cccmaxhops caps how many resharing hops away a card can be and still get accepted — lower values mean you're closer to the source card, generally faster and more stable. cccwantemu controls whether you want emulated/softcam-based cards included; leave it at 0 unless you specifically want those included in your feed.

Best-Practice Reader Tuning: Timeouts, Caching, Fallback, and Hops

Una vez que el lector se conecta y decodifica, la siguiente capa es el ajuste — aquí es donde una configuración meramente funcional se convierte en una configuración oscam reader setup best configuration realmente confiable que sobrevive las horas pico y el cambio de canales sin trabarse.

ecmtimeout / ecmwhitelist y por qué 3000ms es un punto de partida

ecmtimeout controla cuánto tiempo espera OScam a que un lector responda antes de darse por vencido e intentar un respaldo. 3000ms es un punto de partida sensato para la mayoría de fuentes remotas. Configúralo demasiado bajo y obtendrás un respaldo prematuro — el lector estaba a punto de responder pero fue cortado, causando retrasos innecesarios al cambiar de canal y desperdicio de CPU mientras OScam reintenta en otro lugar. Configúralo demasiado alto y obtienes el problema opuesto: congelamientos visibles en pantalla mientras OScam espera pacientemente a un lector lento o muerto antes de finalmente recurrir al respaldo.

fallback y fallback_percaid para redundancia

Un lector de respaldo solo se consulta después de que el primario falla o excede el tiempo de espera — no se usa para balanceo de carga, es un seguro. Configura esto en oscam.user o mediante ajustes de respaldo compatibles con lb_mode, y usa fallback_percaid cuando quieras un comportamiento de respaldo diferente por sistema de encriptación en lugar de un único lector de respaldo genérico para todo.

modos cacheex 1/2/3 y cuándo un lector debería empujar (push) o extraer (pull)

El intercambio de caché es genuinamente útil para acelerar decodificaciones repetidas a través de una red de equipos, pero también es donde he visto configuraciones colapsar por completo. Los modos: 1 es solo push, 2 es solo pull, 3 es push y pull en ambas direcciones. El error que la gente comete constantemente es configurar el modo cacheex 3 en ambos extremos de una relación entre pares — esto crea un bucle donde cada lado sigue reenviando las mismas entradas de caché de un lado a otro, inundando los registros y a veces congelando toda la cadena.

El patrón correcto es asimétrico. Si el equipo A es tu primario y el equipo B quiere la caché de A, B debería ejecutar el modo cacheex 2 (pull) hacia A, y A no debería estar configurado simultáneamente para extraer de B para el mismo caid/dato. Si no estás resolviendo activamente un problema de latencia específico, deja cacheex desactivado. No es una función activada por defecto — es una optimización dirigida para topologías de red específicas.

lb_weight, lb_force_fallback y la estrategia global de balanceo de carga

El balanceo de carga en sí se configura globalmente en oscam.conf con lb_mode — el modo 1 selecciona el lector más rápido según el tiempo de respuesta medido. Pero los lectores individuales tienen lb_weight, que influye en la frecuencia con la que OScam elige ese lector en relación con otros que sirven el mismo caid. Si tienes dos lectores capaces de decodificar el mismo caid y ambos con una velocidad aproximadamente similar, puedes terminar con OScam saltando de uno a otro, lo que se manifiesta como tiempos de decodificación muy inconsistentes en el webif de un cambio de canal al siguiente. Establecer una diferencia clara de lb_weight — digamos 100 en tu lector preferido y 50 en el secundario — le indica a OScam cuál debe preferir realmente en lugar de tratarlos como iguales.

audisabled, aureader y el manejo de EMM

audisabled=1 le indica a OScam que no procese actualizaciones EMM a través de ese lector — es decir, no intentará escribir paquetes de actualización de vuelta a la tarjeta. Esto importa mucho con tarjetas físicas locales: si de alguna manera tienes varios lectores apuntando a la misma tarjeta física (inusual, pero ocurre con ciertas configuraciones multi-cliente), dejar que más de uno procese escrituras EMM simultáneamente puede corromper genuinamente el estado interno de la tarjeta. La solución es simple — elige un lector como el escritor de EMM y configura audisabled=1 en todos los demás lectores que toquen esa misma tarjeta.

Verificar y solucionar problemas de un lector que no decodifica

Este es el orden de diagnóstico que realmente uso, cada vez, antes de tocar un solo valor de configuración.

Leer oscam.log y la página Readers/Status del webif

La primera parada siempre es la pestaña Readers en el webif. El estado muestra verde para conectado, rojo para no conectado. Si está en rojo, esto es puramente un problema de capa de conexión — no pierdas tiempo revisando filtros de caid todavía. Verifica la accesibilidad de host/puerto, confirma que el firewall permite TCP saliente en ese puerto, verifica usuario/contraseña, y confirma que la versión de protocolo coincide con lo que espera el par.

Conectado pero 'CARD OK' sin decodificar: discrepancia de filtro caid/ident

Si el estado muestra conectado e incluso "CARD OK", pero canales específicos aún no decodifican, esto casi nunca es un problema de conexión. Vuelve a tus líneas caid= e ident= y verifica que no hayas excluido accidentalmente el caid que usa ese canal. También verifica que el número de grupo realmente coincida entre el lector y el usuario solicitante — he corregido este mismo problema más veces de las que puedo contar, y siempre es una de estas dos cosas.

'connected' parpadeando: discrepancia de versión o de contraseña/clave DES

Un lector que se conecta, luego se desconecta, y luego se reconecta unos segundos después — repetidamente — usualmente apunta a una discrepancia de cccversion o, en newcamd, a una clave DES malformada. Verifica la longitud de la clave cuidadosamente; debe ser exactamente 14 bytes hexadecimales sin caracteres extraños. Si el lector solo permanece conectado justo después de un reinicio de OScam y luego se desconecta poco después, revisa tus valores de reconnecttimeout e inactivitytimeout — un tiempo de espera demasiado agresivo derribará conexiones que en realidad están bien, solo momentáneamente inactivas.

Errores ECM, tiempos de espera ECM, y diagnóstico de 'no matching reader'

"No matching reader" en el registro significa que OScam no pudo encontrar ningún lector en el grupo correcto con el alcance correcto de caid/ident para ese ECM — ve a revisar tus filtros de nuevo. Un tiempo de espera ECM real en el registro (en contraste con un rechazo) significa que el lector era alcanzable y estaba en alcance pero no respondió a tiempo, lo cual apunta de vuelta al ajuste de ecmtimeout o a una latencia de red genuina hacia esa fuente.

Usar el loglevel de oscam.log y las banderas de depuración -d de forma segura

loglevel en oscam.conf controla la verbosidad — súbelo temporalmente cuando estés persiguiendo un problema específico, pero no dejes el registro a nivel de depuración corriendo permanentemente, ya que inflará tus archivos de registro y puede ocultar la línea de error real entre el ruido. Usa las banderas -d (como -d 1 para depuración de cliente, -d 2 para depuración de lector) desde la línea de comandos para una sesión de diagnóstico corta, y luego bájalo de nuevo una vez que hayas encontrado lo que buscabas.

Cómo evaluar una fuente de tarjeta de forma genérica (sin nombres)

No voy a decirte qué proveedor usar — eso realmente no es el punto de una buena escritura técnica, y francamente no envejecería bien de todos modos. Lo que sí te voy a decir es exactamente qué medir para que puedas juzgar cualquier fuente por ti mismo, usando nada más que tu propio webif de OScam.

Señales de una fuente estable: tiempo de decodificación consistente, % bajo de errores ECM

Abre la página de estado de Readers y observa la columna de tiempo promedio de decodificación durante una noche de uso real, no solo una prueba de cinco minutos. Cualquier cosa consistentemente por debajo de 300ms es sólida. Si estás viendo oscilaciones salvajes — 150ms en un momento, 2000ms al siguiente — eso es una fuente con capacidad de backend inestable, y se manifestará como congelamiento durante cambios de canal rápidos incluso si "funciona" en una prueba rápida.

Transparencia de protocolo/versión y cccversion coincidente

Una fuente bien administrada te dice exactamente qué protocolo, puerto y versión usar — sin necesidad de adivinar. Si una fuente es vaga sobre qué cccversion configurar, o constantemente tienes que probar y errar con el puerto, eso ya es una señal sobre cómo se maneja toda la operación.

Número de saltos, profundidad de compartición y por qué menos saltos decodifican más rápido

El número de saltos te indica cuántas veces se ha reenviado una tarjeta antes de llegar a ti. Un salto de 1 significa que estás hablando con algo cercano a la tarjeta real. Números de saltos más altos significan más capas de reenvío entre tú y la fuente, lo que generalmente implica más latencia y más puntos de fallo. Este es genuinamente uno de los números más útiles y medibles que tienes disponibles, y es visible directamente en los detalles del lector de la webif.

Señales de alerta: saltos altos forzados, reconexiones inestables, EMM desactivado en todas partes

Presta atención a fuentes que fuerzan números de saltos inusualmente altos sin explicación, lectores que se reconectan constantemente sin una causa de red clara de tu lado, o configuraciones donde el manejo de EMM aparece completamente desactivado en todos los ámbitos sin ninguna vía de actualización de tarjeta. Ninguno de estos descalifica automáticamente por sí solo, pero juntos pintan un panorama que vale la pena tener en cuenta antes de invertir tiempo real de configuración.