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

Sobald der Reader verbindet und dekodiert, ist die nächste Ebene das Tuning — hier wird aus einem bloß funktionierenden Setup tatsächlich ein zuverlässiges oscam reader setup best configuration, das Spitzenzeiten und Kanalwechsel ohne Ruckeln übersteht.

ecmtimeout / ecmwhitelist und warum 3000ms ein guter Ausgangspunkt sind

ecmtimeout legt fest, wie lange OScam auf die Antwort eines Readers wartet, bevor es aufgibt und einen Fallback versucht. 3000ms sind für die meisten Remote-Quellen ein vernünftiger Ausgangswert. Setzt man den Wert zu niedrig, kommt es zu verfrühtem Fallback — der Reader wollte gerade antworten, wurde aber abgeschnitten, was unnötige Zapping-Verzögerungen und verschwendete CPU-Last durch erneute Versuche bei anderen Readern verursacht. Setzt man ihn zu hoch, entsteht das gegenteilige Problem: sichtbare Bildaussetzer, während OScam geduldig auf einen langsamen oder toten Reader wartet, bevor es endlich auf den Fallback zurückgreift.

fallback und fallback_percaid für Redundanz

Ein Fallback-Reader wird erst abgefragt, nachdem der primäre Reader ausfällt oder ein Timeout auftritt — er dient nicht dem Lastausgleich, sondern als Absicherung. Konfiguriere dies in oscam.user oder über lb_mode-bewusste Fallback-Einstellungen, und nutze fallback_percaid, wenn du unterschiedliches Fallback-Verhalten je Verschlüsselungssystem willst, statt eines einzigen pauschalen Fallback-Readers für alles.

cacheex-Modi 1/2/3 und wann ein Reader pushen oder pullen sollte

Cache-Exchange ist wirklich nützlich, um wiederholte Dekodierungen über ein Netzwerk von Boxen hinweg zu beschleunigen, aber genau hier habe ich auch schon Setups komplett kollabieren sehen. Die Modi: 1 ist nur Push, 2 ist nur Pull, 3 ist Push und Pull in beide Richtungen. Der Fehler, den Leute ständig machen, ist cacheex-Modus 3 auf beiden Seiten einer Peer-Beziehung zu setzen — das erzeugt eine Schleife, in der jede Seite dieselben Cache-Einträge immer wieder gegenseitig zurückpusht, was Logs flutet und manchmal die gesamte Kette einfrieren lässt.

Das richtige Muster ist asymmetrisch. Wenn Box A deine primäre Box ist und Box B den Cache von A haben will, sollte B cacheex-Modus 2 (Pull) gegenüber A verwenden, und A sollte nicht gleichzeitig so eingestellt sein, dass es für dieselbe caid/Daten von B pullt. Wenn du nicht aktiv ein bestimmtes Latenzproblem löst, lass cacheex ausgeschaltet. Es ist keine standardmäßig aktivierte Funktion — es ist eine gezielte Optimierung für bestimmte Netzwerktopologien.

lb_weight, lb_force_fallback und die globale Loadbalance-Strategie

Der Lastausgleich selbst wird global in oscam.conf über lb_mode konfiguriert — Modus 1 wählt den schnellsten Reader anhand der gemessenen Antwortzeit. Aber einzelne Reader tragen lb_weight, was beeinflusst, wie oft OScam diesen Reader im Vergleich zu anderen wählt, die dieselbe caid bedienen. Wenn du zwei Reader hast, die beide dieselbe caid dekodieren können und beide ungefähr gleich schnell sind, kann OScam zwischen ihnen hin- und herspringen, was sich als wild inkonsistente Dekodierzeiten im webif von einem Zap zum nächsten zeigt. Ein klarer lb_weight-Unterschied — etwa 100 auf deinem bevorzugten Reader und 50 auf dem sekundären — sagt OScam eindeutig, welchen es tatsächlich bevorzugen soll, statt beide gleich zu behandeln.

audisabled, aureader und EMM-Behandlung

audisabled=1 sagt OScam, EMM-Updates über diesen Reader nicht zu verarbeiten — das heißt, es wird nicht versuchen, Update-Pakete zurück auf die Karte zu schreiben. Das ist bei lokalen physischen Karten sehr wichtig: Wenn mehrere Reader irgendwie auf dieselbe physische Karte zeigen (ungewöhnlich, kommt aber bei bestimmten Multi-Client-Setups vor), kann es den internen Zustand der Karte tatsächlich beschädigen, wenn mehr als ein Prozess gleichzeitig EMM-Schreibvorgänge durchführt. Die Lösung ist einfach — einen Reader als EMM-Writer festlegen und audisabled=1 auf jedem anderen Reader setzen, der dieselbe Karte anspricht.

Einen Reader überprüfen und Fehler beheben, der nicht dekodiert

Hier ist die diagnostische Reihenfolge, die ich tatsächlich jedes Mal verwende, bevor ich auch nur einen einzigen Konfigurationswert anfasse.

oscam.log und die webif-Seite Readers/Status lesen

Die erste Anlaufstelle ist immer der Readers-Tab im webif. Der Status zeigt Grün für verbunden, Rot für nicht verbunden. Wenn er rot ist, handelt es sich rein um ein Problem auf Verbindungsebene — verschwende noch keine Zeit damit, caid-Filter zu prüfen. Überprüfe die Erreichbarkeit von Host/Port, stelle sicher, dass die Firewall ausgehendes TCP auf diesem Port erlaubt, verifiziere Benutzername/Passwort und bestätige, dass die Protokollversion mit der des Peers übereinstimmt.

Verbunden, aber 'CARD OK' ohne Dekodierung: caid/ident-Filter-Fehlanpassung

Wenn der Status "verbunden" und sogar "CARD OK" anzeigt, bestimmte Kanäle aber weiterhin nicht dekodieren, ist das fast nie ein Verbindungsproblem. Geh zurück zu deinen caid= und ident=-Zeilen und prüfe, ob du nicht versehentlich die caid ausgeschlossen hast, die dieser Kanal verwendet. Überprüfe außerdem doppelt, ob die Gruppennummer zwischen Reader und anfragendem Benutzer tatsächlich übereinstimmt — ich habe genau dieses Problem öfter behoben, als ich zählen kann, und es liegt immer an einem dieser beiden Punkte.

'connected' flackert: Version- oder Passwort-/DES-Schlüssel-Fehlanpassung

Ein Reader, der verbindet, dann trennt, dann ein paar Sekunden später wieder verbindet — wiederholt — deutet meist auf eine cccversion-Fehlanpassung hin oder, bei newcamd, auf einen fehlerhaft formatierten DES-Schlüssel. Prüfe die Schlüssellänge sorgfältig; sie sollte genau 14 Hex-Bytes ohne überzählige Zeichen betragen. Wenn der Reader nur direkt nach einem OScam-Neustart verbunden bleibt und dann kurz danach die Verbindung verliert, schau dir deine Werte für reconnecttimeout und inactivitytimeout an — ein zu aggressiver Timeout reißt Verbindungen ab, die eigentlich in Ordnung sind und nur gerade kurz inaktiv waren.

ECM-Fehler, ECM-Timeouts und die Diagnose von 'no matching reader'

"No matching reader" im Log bedeutet, dass OScam keinen Reader in der richtigen Gruppe mit dem richtigen caid/ident-Bereich für dieses ECM finden konnte — überprüfe deine Filter erneut. Ein tatsächlicher ECM-Timeout im Log (im Gegensatz zu einer Ablehnung) bedeutet, dass der Reader erreichbar und im Geltungsbereich war, aber nicht rechtzeitig geantwortet hat, was wieder auf ecmtimeout-Feintuning oder echte Netzwerklatenz zu dieser Quelle hinweist.

oscam.log loglevel und die -d-Debug-Flags sicher verwenden

loglevel in oscam.conf steuert die Ausführlichkeit — erhöhe ihn vorübergehend, wenn du ein bestimmtes Problem verfolgst, aber lass Debug-Level-Logging nicht dauerhaft laufen, da es deine Log-Dateien aufblähen und die tatsächliche Fehlerzeile im Rauschen verschleiern kann. Nutze die -d-Flags (wie -d 1 für Client-Debug, -d 2 für Reader-Debug) von der Kommandozeile für eine kurze Diagnosesitzung und dreh es dann wieder herunter, sobald du gefunden hast, was du gesucht hast.

Wie man eine Kartenquelle generisch bewertet (ohne Namen)

Ich werde dir nicht sagen, welchen Anbieter du verwenden sollst — das ist eigentlich nicht der Sinn guten technischen Schreibens, und es würde ohnehin nicht gut altern. Was ich dir sagen werde, ist genau, was du messen musst, damit du jede Quelle selbst beurteilen kannst, und zwar nur mit deinem eigenen OScam-webif.

Anzeichen für eine stabile Quelle: konsistente Dekodierzeit, niedrige ECM-Fehlerquote

Öffne die Readers-Statusseite und beobachte die Spalte der durchschnittlichen Dekodierzeit über einen ganzen Abend echter Nutzung, nicht nur bei einem fünfminütigen Test. Alles konstant unter 300ms ist solide. Wenn du wilde Schwankungen siehst — mal 150ms, mal 2000ms — dann handelt es sich um eine Quelle mit instabiler Backend-Kapazität, und das zeigt sich als Einfrieren bei schnellen Kanalwechseln, selbst wenn sie in einem schnellen Test "funktioniert".

Protokoll-/Versionstransparenz und passende cccversion

Eine gut geführte Quelle sagt dir genau, welches Protokoll, welchen Port und welche Version du verwenden sollst — kein Rätselraten erforderlich. Wenn eine Quelle vage bleibt, welche cccversion man einstellen soll, oder man ständig den Port per Trial-and-Error herausfinden muss, ist das bereits ein Signal dafür, wie der gesamte Betrieb geführt wird.

Hop-Anzahl, Sharing-Tiefe und warum weniger Hops schneller dekodieren

Die Hop-Anzahl gibt an, wie oft eine Karte weitergeteilt wurde, bevor sie dich erreicht. Hop 1 bedeutet, dass du mit etwas sprichst, das der eigentlichen Karte nahe ist. Höhere Hop-Zahlen bedeuten mehr Reshare-Ebenen zwischen dir und der Quelle, was in der Regel mehr Latenz und mehr Fehlerquellen bedeutet. Das ist wirklich eine der nützlicheren, messbaren Zahlen, die dir zur Verfügung stehen, und sie ist direkt in den Webif-Reader-Details sichtbar.

Warnsignale: erzwungene hohe Hops, instabile Reconnects, EMM überall deaktiviert

Achte auf Quellen, die ungewöhnlich hohe Hop-Zahlen ohne Erklärung erzwingen, auf Reader, die sich ständig neu verbinden ohne einen klaren Netzwerkgrund auf deiner Seite, oder auf Setups, bei denen die EMM-Verarbeitung durchgängig komplett deaktiviert erscheint, ohne jeglichen Karten-Update-Pfad. Keiner dieser Punkte disqualifiziert automatisch für sich allein, aber zusammen ergeben sie ein Bild, das Aufmerksamkeit verdient, bevor du echte Konfigurationszeit investierst.