OScam WebIf: How to Monitor Active Readers and Clients (2026 Guide)

If you've got OScam running and the WebIf open in a browser tab, but you still can't tell whether your readers are actually doing anything, you're not alone. This guide on oscam webif: how to monitor active readers and clients walks through every column on the Status page, what the log codes mean, and which config file to open when something's broken. I've run OScam on everything from a Raspberry Pi to an old Vu+ Solo2, and the WebIf tells you almost everything you need — you just have to know how to read it.

This isn't a setup tutorial. I'm assuming oscam.conf, oscam.server, and oscam.user already exist and the daemon is running. The goal here is diagnosis: mapping what's on screen to a specific line in a config file, so you can fix it instead of guessing.

Enable the OScam WebIf Before You Can Monitor Anything

A big chunk of people searching for this topic actually have a WebIf that won't load at all. So before we get into reading columns, let's make sure the page opens. Here's a minimal working [webif] block for oscam.conf:

[webif]httpport = 8888httpuser = adminhttppwd = your_password_herehttprefresh = 10httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

httprefresh controls how often the page auto-reloads, in seconds. Set it to 0 when you're reading a log or a status table and don't want the page jumping around under your cursor — I do this constantly when I'm trying to catch a reconnect in the act.

If you put a + in front of the port, like httpport = +8888, OScam switches to HTTPS. That requires an oscam.pem file sitting in the same config directory. Without it, the daemon will refuse to bind and the WebIf just won't come up — no error dialog, no obvious clue, just a connection refused in your browser.

Config paths are not universal, and this trips up more people than it should. On Enigma2 images you'll typically find things under /etc/tuxbox/config/ or /etc/tuxbox/config/oscam/. On a generic Linux box it's usually /usr/local/etc/. Some OpenWrt builds stash it in /var/etc/. Rather than guess, check the init script or systemd unit for the -c flag — that tells you exactly which directory OScam is actually reading. I've seen people edit oscam.conf for twenty minutes wondering why nothing changes, only to find the running process was started with -c /etc/oscam2/ instead.

Confirm your build actually has WebIf support compiled in:

oscam --build-info | grep -i webif

If that comes back empty, the daemon is running fine — it's just that the port never listens, because WEBIF wasn't included at compile time. This is a common cause of a "blank page" that people mistake for a config problem. The other common cause is the port already being in use by a second OScam instance (more on that later) or another service.

Reading the Status Page: What Each Column Actually Means

This is the part almost nobody explains properly. Most write-ups screenshot the Status page and say "here's your readers," without telling you what CARDOK versus CONNECTED versus IDLE actually implies. So let's go column by column, because this is the real answer to oscam webif: how to monitor active readers and clients.

Client vs reader vs proxy rows

Every row on the Status page has a type letter. c is a client — an entry from oscam.user connecting in to request ECMs. p is a proxy reader — a network connection out to another cardsharing server (cccam, newcamd, camd35, cs378x, gbox). r is a local reader — a physical card via PCSC or a serial reader like a Smargo. m is the monitor row, which is just OScam's own monitor port.

One thing that confuses people: a peer configured on both sides — you're feeding them and they're feeding you — shows up twice. Once as a client row, once as a reader row. If you count that as two separate people, you'll overcount your active connections.

The Status column

This is the field people stare at the longest. Here's what each state actually means in practice:

• CONNECTED — the socket is open and authenticated, but this alone doesn't tell you if data is flowing.
• LOGIN — mid-handshake, should be transient. If it sticks here, credentials or protocol version are likely wrong.
• IDLE — connected, authenticated, just not actively serving an ECM at this instant. Completely normal.
• OFF — not connected. For a reader, check the network path and credentials. For a local reader, check the card is actually seated.
• CARDOK — specific to local and proxy readers: the card was read successfully and OScam has its ATR and entitlements.
• DISCONNECTED — was connected, isn't now. Combined with a rising reconnect count, this points to a network or keepalive issue.

A reader sitting in CARDOK with a steadily rising ECM count is healthy — that's the picture you want. A reader stuck in CONNECTED with zero ECMs ever sent is reachable but never actually selected by the load balancer, usually because of a CAID or ident mismatch, or because another reader is faster and always wins the race. A reader that keeps flipping between CONNECTED and OFF every minute or two is a network or credential problem, not a card problem.

AU: the column everyone misreads

AU stands for Auto Update — whether this connection is allowed to push EMMs to keep a card's subscription current. ON means EMMs are permitted. OFF means they're blocked entirely. If you see a CAID value instead, AU is restricted to just that CAID — useful when a client has multiple cards behind it but you only want automatic updates for one. This is set with au = 1 in oscam.user, or au = to bind updates to a specific reader.

ECM Time, Last Channel, and the LB indicator

ECM Time is measured in milliseconds and it's the single most useful performance number on the page. Under roughly 300 ms and zapping feels instant. Between 300 and 800 ms it's usable but you'll notice a beat before the picture clears. Past 1000 ms consistently, you'll see visible freezing on channel change, and if it climbs past your ecmtimeout setting (commonly 3000 ms by default), OScam abandons that ECM outright.

Comparing ECM Time across readers that carry the same CAID is exactly how you decide reader priority for the load balancer — the fastest one should be preferred, and OScam's stats engine tracks this automatically if lb_mode is enabled (more on that in a minute).

Last Channel shows as CAID:provid:sid in hex. Without an oscam.srvid file in your config directory, that's all you'll ever see — raw numbers, no channel names. Drop a proper oscam.srvid (or oscam.srvid2) file in there and the WebIf resolves those IDs to actual channel names. I've seen people assume the WebIf is broken simply because this file was never added.

Idle timer and why a client can be connected with zero ECMs

The Idle column counts seconds since the last request from that connection. A client can sit at CONNECTED for hours with an Idle timer climbing and zero ECMs processed — that just means they haven't changed the channel or aren't currently watching anything decrypted through your box. That's not a fault, it's just quiet.

Cache hits and cache-ex readers

This is the piece almost every other guide skips, and it causes real confusion. If you're running cache exchange (cacheex), some readers exist purely to share cached ECM answers between servers — they may legitimately never process a single "real" ECM against a card. Their counters sit at zero forever, and that's by design, not a broken reader. Don't chase a phantom problem on a cacheex-only reader that shows zero ECMs; check its cacheex mode setting in oscam.server instead of assuming it's dead.

Live Log Monitoring: Filtering the Noise to Find the Failing ECM

The Status page tells you the state of things right now. The log tells you why. Here's a real annotated ECM line, format-wise (values are illustrative placeholders, not tied to any real card system):

2026/07/14 21:14:02 c (client) username ECM 0100:000000 sid 4A21 pid 0834 from reader1 (0 ms) rc=1 (found)

Breaking that down: caid is 0100, provid is 000000, sid is the service ID 4A21, pid is the elementary stream PID 0834, the reader that answered was reader1, and rc=1 (found) is the return code — meaning the ECM was decrypted successfully. The number in parentheses before rc is the response time in milliseconds, which is the same number reflected on the Status page's ECM Time column for that reader.

Return codes you'll actually see

• found — successfully decrypted, all good.
• not found — every reader you tried does not carry that CAID/provid combination. Check the Entitlements page to confirm.
• cache1 / cache2 / cache3 — the answer came from cache, not from touching a card at all. This is normal and fast — it's also why a reader can look "idle" on Status while the channel decrypts fine.
• timeout — the reader took too long to answer. Don't just raise ecmtimeout to paper over this — check actual network latency to that reader and consider whether ecmtimeout (default often 3000 ms) is realistic for that connection.
• rejected — almost always a group, CAID, or ident mismatch between oscam.user and oscam.server. The client's group in oscam.user has to overlap the reader's group, or the request never gets forwarded.

Debug levels — use the bitmask, not 255

OScam's debug levels are a bitmask, and setting debug to 255 dumps everything at once. On a busy server that's a flood, and on a low-RAM box writing to flash storage, it can genuinely fill the disk or trip a watchdog reboot. I've bricked a session this way on an old set-top box with a 512 MB flash chip — don't do that.

Use the specific bits you need: 2 for reader/ATR activity, 4 for client connections, 16 for EMM handling, 64 for ECM flow. If you're chasing a channel that won't decrypt, debug = 64 alone is usually enough. Set logfile to point somewhere on a real filesystem, not flash, set maxlogsize to cap it, and drop debug back to 0 the moment you've found your answer.

The Live Log page in the WebIf lets you filter by a single client or reader name instead of reading the entire stream, which is a lot faster than grepping a giant oscam.log file when you already know which connection is misbehaving.

Reader Health: Entitlements, Cards, and the Load Balancer View

The fastest way to answer "is my card actually alive" is the Entitlements view on the Readers page. It lists every CAID, provider ident, class, and expiry date the card reports. For a local reader — PCSC, an internal slot, a Smargo — this comes straight from the card itself. For a network reader (a cccam or newcamd proxy connection), you're seeing whatever the upstream server advertises, which may or may not correspond to a real physical card on their end.

I've seen a reader sit at CARDOK for weeks, ECM Time looking perfectly healthy, and the actual entitlement had expired two days earlier — the card just kept answering ECMs for CAIDs it no longer had rights to, returning not-found instead of an error you'd notice on Status. The only place that shows up is the Entitlements page's expiry column.

The Load Balancer stats page is history, not a live view

This is the piece most competing guides skip entirely, and it's why a perfectly healthy-looking reader can sit at zero ECMs. The load balancer page shows accumulated performance stats per reader — average ECM time, failure count — and OScam uses that history to decide which reader gets tried first for a given CAID/provid combination. A reader that's fine right now but has a bad history from an hour ago will keep losing the race to a reader with a better track record, until enough data changes that.

Relevant keys in oscam.conf:

• lb_mode = 1 — enables load balancing, prioritizing the fastest reader.
• lb_save — persists stats to disk so they survive a restart.
• lb_nbest_readers — how many top readers to try per request.
• lb_retrylimit — milliseconds before OScam gives up on the first reader and tries the next one. This directly interacts with the ECM Time you see on Status: if lb_retrylimit is lower than a reader's typical response time, that reader will almost never win, even if it eventually would have answered fine.
• lb_stat_cleanup — hours before old stats age out.

If you fix a slow reader — say you moved it to a better network path — its old stats are still weighing against it. Reset the load balancer stats from the WebIf after the fix, otherwise OScam keeps avoiding a reader that's no longer actually slow. And if lb_save carried stats over from a previous hardware setup, you can end up with OScam still steering ECMs toward a reader that doesn't exist anymore — that shows up as ECMs quietly failing with no obvious cause until you check the load balancer page and see a phantom entry.

Automating Monitoring: HTTP API, JSON Status, and External Tools

Almost nobody covers this part, but OScam exposes a machine-readable API through the WebIf, so you don't have to scrape HTML to check reader state. Hit it with curl:

curl --user admin:your_password_here "http://192.168.1.50:8888/oscamapi.json?part=status"

The response is a JSON object with a client array — each entry carrying type, name, protocol, connection state, and last channel, structurally the same information as the Status page but parseable by a script. There's also part=readers for reader-specific data. This is genuinely useful if you want to poll reader state from cron every five minutes and fire off an alert when a reader drops.

Before you wire this into anything, lock it down: create a separate, restricted WebIf account rather than reusing your admin login, and restrict httpallowed to just the IP of the machine doing the polling. The WebIf can restart the daemon and rewrite config files — it's not something to expose broadly just because you want a dashboard.

For process-level monitoring — is OScam even running, not just "is the reader connected" — rely on systemd (systemctl status oscam) or your init.d script's restart-on-crash behavior rather than the WebIf, since the WebIf obviously can't tell you anything if the whole process is down.

Common Monitoring Symptoms and What They Actually Mean

Here's a symptom-to-fix table, because this is usually what people actually came here for when they searched oscam webif: how to monitor active readers and clients.

A couple of edge cases worth flagging directly. If you're running two OScam instances at once — one launched by the box's image, one you started manually — each has its own WebIf on a different port, and it's easy to monitor the wrong one entirely while wondering why your changes never seem to take effect. Check ps aux | grep oscam if the Status page seems stuck in time.

Also check your system clock. If NTP hasn't synced since the last reboot, you'll see bogus login times, negative idle timers, and — if you're running HTTPS on the WebIf — certificate validation failures, since oscam.pem's validity window depends on the clock being roughly correct.