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

Once the reader connects and decodes, the next layer is tuning — this is where a merely functional setup becomes an actually reliable oscam reader setup best configuration that survives peak hours and channel-hopping without stuttering.

ecmtimeout / ecmwhitelist and why 3000ms is a starting point

ecmtimeout controls how long OScam waits for a reader to respond before giving up and trying a fallback. 3000ms is a sane starting point for most remote sources. Set it too low and you'll get premature fallback — the reader was about to respond but got cut off, causing unnecessary zapping delays and wasted CPU as OScam retries elsewhere. Set it too high and you get the opposite problem: visible on-screen freezes while OScam patiently waits out a slow or dead reader before finally falling back.

fallback and fallback_percaid for redundancy

A fallback reader only gets queried after the primary fails or times out — it's not used for load balancing, it's insurance. Configure this in oscam.user or via lb_mode-aware fallback settings, and use fallback_percaid when you want different fallback behavior per encryption system rather than a single blanket fallback reader for everything.

cacheex modes 1/2/3 and when a reader should push vs. pull

Cache exchange is genuinely useful for speeding up repeat decodes across a network of boxes, but it's also where I've seen setups implode completely. The modes: 1 is push-only, 2 is pull-only, 3 is push-and-pull both directions. The mistake people make constantly is setting cacheex mode 3 on both ends of a peer relationship — this creates a loop where each side keeps re-pushing the same cache entries back and forth, flooding logs and sometimes freezing the whole chain.

The correct pattern is asymmetric. If box A is your primary and box B wants A's cache, B should run cacheex mode 2 (pull) toward A, and A should not simultaneously be set to pull from B for the same caid/data. If you're not actively solving a specific latency problem, leave cacheex off. It's not a default-on feature — it's a targeted optimization for specific network topologies.

lb_weight, lb_force_fallback and the global loadbalance strategy

Load balancing itself is configured globally in oscam.conf with lb_mode — mode 1 selects the fastest reader based on measured response time. But individual readers carry lb_weight, which biases how often OScam picks that reader relative to others serving the same caid. If you've got two readers both capable of decoding the same caid and both roughly similar in speed, you can end up with OScam ping-ponging between them, which shows up as wildly inconsistent decode times in the webif from one zap to the next. Setting a clear lb_weight difference — say 100 on your preferred reader and 50 on the secondary — tells OScam which one to actually prefer rather than treating them as equals.

audisabled, aureader and EMM handling

audisabled=1 tells OScam not to process EMM updates through that reader — meaning it won't attempt to write update packets back to the card. This matters a lot with local physical cards: if you've got multiple readers somehow pointed at the same physical card (unusual, but happens with certain multi-client setups), letting more than one process EMM writes simultaneously can genuinely corrupt the card's internal state. The fix is simple — pick one reader as the EMM writer and set audisabled=1 on every other reader touching that same card.

Verifying and Troubleshooting a Reader That Won't Decode

Here's the diagnostic order I actually use, every time, before touching a single config value.

Reading oscam.log and the webif Readers/Status page

First stop is always the Readers tab in webif. Status shows green for connected, red for not connected. If it's red, this is purely a connection-layer problem — don't waste time checking caid filters yet. Check host/port reachability, confirm the firewall allows outbound TCP on that port, verify username/password, and confirm protocol version matches what the peer expects.

Connected but 'CARD OK' with no decode: caid/ident filter mismatch

If status shows connected and even "CARD OK," but specific channels still won't decode, this is almost never a connection problem. Go back to your caid= and ident= lines and check you haven't accidentally excluded the caid that channel uses. Also double-check the group number actually matches between the reader and the requesting user — I've fixed this exact issue more times than I can count, and it's always one of these two things.

'connected' flapping: version or password/DES key mismatch

A reader that connects, then drops, then reconnects a few seconds later — repeatedly — usually points to a cccversion mismatch or, on newcamd, a malformed DES key. Check the key length carefully; it should be exactly 14 hex bytes with no stray characters. If the reader only stays connected right after an OScam restart and then drops shortly after, look at your reconnecttimeout and inactivitytimeout values — too aggressive a timeout will tear down connections that are actually fine, just momentarily idle.

ECM errors, ECM timeouts, and 'no matching reader' diagnosis

"No matching reader" in the log means OScam couldn't find any reader in the right group with the right caid/ident scope for that ECM — go check your filters again. An actual ECM timeout in the log (versus a rejection) means the reader was reachable and in scope but didn't answer in time, which points back to ecmtimeout tuning or genuine network latency to that source.

Using oscam.log loglevel and the -d debug flags safely

loglevel in oscam.conf controls verbosity — bump it up temporarily when chasing a specific issue, but don't leave debug-level logging running permanently, since it'll balloon your log files and can obscure the actual error line in noise. Use the -d flags (like -d 1 for client debug, -d 2 for reader debug) from the command line for a short diagnostic session, then turn it back down once you've found what you're after.

How to Evaluate a Card Source Generically (No Names)

I'm not going to tell you which provider to use — that's not really the point of good technical writing, and frankly it wouldn't age well anyway. What I will tell you is exactly what to measure so you can judge any source yourself, using nothing but your own OScam webif.

Signals of a stable source: consistent decode time, low ECM error %

Open the Readers status page and watch the average decode time column over an evening of actual use, not just a five-minute test. Anything consistently under 300ms is solid. If you're seeing wild swings — 150ms one moment, 2000ms the next — that's a source with unstable backend capacity, and it'll show up as freezing during fast channel changes even if it "works" in a quick test.

Protocol/version transparency and matched cccversion

A well-run source tells you exactly what protocol, port, and version to use — no guesswork required. If a source is vague about which cccversion to set, or you constantly have to trial-and-error the port, that's already a signal about how the whole operation is run.

Hop count, sharing depth, and why fewer hops decode faster

Hop count tells you how many times a card has been reshared before reaching you. Hop 1 means you're talking to something close to the actual card. Higher hop counts mean more resharing layers between you and the source, which generally means more latency and more points of failure. This is genuinely one of the more useful, measurable numbers you have available, and it's visible right in the webif reader details.

Red flags: forced high hops, unstable reconnects, EMM disabled everywhere

Watch for sources that force unusually high hop counts with no explanation, readers that reconnect constantly without a clear network cause on your end, or setups where EMM handling appears completely disabled across the board with no card update path at all. None of these are automatically disqualifying on their own, but together they paint a picture worth paying attention to before you commit real config time.