NCam ECM Timeout: How to Fix It (Full Guide)

If you're hunting for an NCam ECM timeout fix, you've probably already stared at logs full of lines like ECM (0x0963) timeout (3000 ms) while channels freeze or go black mid-stream. The frustrating part? Most advice online just says "raise the timeout value" — which doesn't fix anything and actually makes freezes feel longer. This guide works through the actual causes, from dead upstream readers to a stuck CI slot right on your own box.

Before touching any config, understand what you're actually looking at. A timeout is not the same as a failed decode, and treating them the same wastes hours.

What an ECM Timeout Actually Means in NCam

Every encrypted channel sends out ECMs — Entitlement Control Messages — roughly every 10 seconds. Your NCam client catches one, sends it to a reader (a local card, a network peer, an emulator), and waits for a control word back. That control word is what actually decrypts the stream. If no answer comes back inside the configured window, NCam logs a timeout and either retries or fails over to another reader.

The ECM Request/Response Cycle Explained

The flow goes: dvbapi captures ECM from the stream → NCam routes it to the best available reader based on the load balancer → reader/server decodes it using the card → control word returned → dvbapi passes it to the decoder. The whole round trip on a healthy setup with a local reader typically runs under 300 ms. On a network peer with one hop, you might see 400–800 ms. Start seeing 1500+ ms consistently and timeouts become a matter of when, not if.

That ecm-timeout value (default 3000 ms in most builds) is how long NCam waits before giving up on a reader for that specific ECM request. Three seconds sounds like a lot. But if your crypto period is 10 seconds and you're waiting 3 seconds, then retrying another reader, then waiting 3 more — you're already into the next crypto period with no control word. The screen goes black.

Reading the Timeout Line in Your NCam Log

A typical timeout line looks something like this:

2026/03/15 21:04:33 c (ecm) r=MyReader CAID: 0963 PROVID: 000000 SID: 12AB PID: 0200 LEN: 183 READER: timeout (3000 ms)

Breaking that down: 0963 is the CAID (the encryption system — Sky in this case), 000000 is the provider ID, 12AB is the service ID (the specific channel), and 3000 ms is the timeout window that expired. The reader name (MyReader) tells you which upstream source failed to answer. That's your first clue.

Timeout vs. 'Not Found' vs. 'Rejected' — Different Problems

This is the thing almost nobody explains properly. These three outcomes have completely different root causes:

• Timeout — The reader was reachable, the request was sent, but no answer came back in time. Causes: high latency, overloaded server, dead connection, local signal issue.
• Not found — The reader answered, but doesn't have the card/entitlement for that CAID or provider. Wrong card, wrong package, or the card simply isn't subscribed.
• Rejected — The peer actively refused the request. Usually SID/CHID filtering on the server side, or a fake/forged ECM being blocked.

If you're chasing a timeout with fixes meant for "not found" — checking entitlements, swapping servers — you'll go in circles. The log keyword is everything. Read it first.

Tuning the Timeout and Reader Parameters

Config file locations vary slightly by build, but on most embedded Linux setups (Enigma2 boxes, etc.) you're looking at /etc/tuxbox/config/ or /var/keys/. On a standalone server it's typically /etc/oscam/. The main files you'll touch are oscam.conf, oscam.server, and oscam.dvbapi.

ecm-timeout in [global] and Per-Reader

The global setting lives in oscam.conf under the [global] block:

[global]ecm-timeout = 3000

You can override this per-reader in oscam.server:

[reader]label = MyNetworkPeerprotocol = camd35device = 192.168.1.50,15000ecmnotfound-reinit = 0

Raising ecm-timeout from 3000 to 5000 ms gives slow peers more time to respond. This buys you stable decoding on a borderline server. But — and this matters — it also means every failed ECM now takes 5 full seconds before failover triggers. If you have three readers and one is dead, every channel zap potentially waits 5 seconds per dead reader before landing on the working one. Raising the timeout without fixing the underlying problem makes the user experience worse, not better.

lb_retrylimit and lb_reopen_seconds for Load Balancing

NCam's load balancer tracks which readers are performing well and routes new ECMs accordingly. Two settings control how it handles bad readers:

[global]lb_mode = 1lb_retrylimit = 900lb_reopen_seconds = 900

lb_retrylimit sets the ECM response time (in ms) above which a reader gets deprioritized. At 900 ms, any reader consistently taking longer than that gets pushed down the list. lb_reopen_seconds controls how long NCam waits before giving a bad reader another shot — 900 seconds (15 minutes) stops it from hammering a dead peer on every single ECM request and adding 3-second delays across the board. If this is set too low (like 60 seconds) and you have a genuinely dead upstream, NCam keeps retrying it constantly, and every retry is another timeout eating into your stream.

cccmaxhops, cccwantemu and Reader-Specific Limits

For CCcam protocol readers, cccmaxhops limits how many hops a card can be reshared through before NCam ignores it. Keep this at 1 or 2 maximum. Cards 3–5 hops away are garbage for ECM time — you're adding the latency of multiple intermediate servers.

[reader]label = CCcamPeerprotocol = cccamdevice = yourpeer.example.com,12000cccmaxhops = 2cccwantemu = 0

Set cccwantemu = 0 unless you actually want emulated cards from that peer. Emulated entries can show up in the load balancer and fail on real encrypted channels, causing spurious timeouts.

Where the Config Files Live and How to Reload

After editing, you don't need a full reboot. In the NCam webif (usually at http://your-box:8888), go to Config → Restart or use the Reload Readers button. Alternatively, send a SIGHUP to the process: killall -HUP oscam. Changes to oscam.server take effect immediately on reload. Changes to oscam.conf [global] typically need a full restart of the oscam process, not just a reader reload.

Network Latency and Server-Side Causes

Before you change a single config value, figure out where the delay is actually happening. Changing ecm-timeout when the problem is a dead upstream reader achieves nothing. Spend 10 minutes measuring first.

Measuring Round-Trip Time to the Upstream Peer

Start with basic ping to the server's IP or hostname. If you're getting 200+ ms ping times on a server that should be in Europe, that's your problem right there. Then go deeper with mtr (Matt's Traceroute):

mtr --report --report-cycles 100 yourpeer.example.com

This shows you per-hop packet loss and latency. A single hop with 40% packet loss in the middle of the route will cause intermittent ECM timeouts even with a healthy server on the other end. The fix there is the network path, not NCam config.

Now cross-reference with the NCam webif. Under Status, the ECM time column shows actual response times per reader. If you're consistently seeing 1200–1800 ms there with a 3000 ms timeout, you're living on the edge. One bad moment and you're timing out.

MTU, Fragmentation and Port Issues (Default 12000 Range)

CCcam protocol typically runs on port 12000 (configurable in your reader's device line). Camd35 usually uses 15000 or 15001. These are TCP connections, so MTU fragmentation shouldn't be a killer — but firewall state tables can drop idle connections silently.

This is the cause of the "timeouts after idle" problem that catches people off guard. You watch a channel for 20 minutes, stop, come back an hour later, and it won't decode. The connection is technically still "up" from NCam's perspective, but the NAT/firewall dropped the state entry. The fix: enable TCP keepalives at the OS level, or configure your router to use a longer connection tracking timeout for those ports. On OpenWrt-based routers, bump nf_conntrack_tcp_timeout_established above 7200 seconds.

Overloaded Server: ECM Time Spikes Under Concurrent Load

A single physical smart card can only answer one ECM at a time. If a server has 50 clients sharing one card and all 50 hit a crypto period refresh simultaneously, that card has a queue. ECM time spikes to 2000–3000 ms. At peak hours (evenings, weekend sports events), this gets dramatically worse. The card isn't broken, the server isn't misconfigured — it's just math. Too many clients per card.

You'll see this pattern clearly: ECM times in webif are stable at 400 ms all morning, then climb to 1800 ms from 19:00 onwards. That's server oversubscription, full stop. No amount of local NCam tuning fixes it. The only real NCam ECM timeout fix for this is finding a server with fewer clients per card, or adding a second upstream peer with the same CAID as a failover.

Local Tuner/CI Issues That Look Like Timeouts

Here's the one that wastes the most diagnostic time: the problem has nothing to do with the network at all. A stuck CI (Common Interface) slot, a degraded internal card reader, or a weak satellite signal can all produce ECM timeout entries in NCam logs — because the ECM was captured off a bad stream, or the CI returned no control word, and NCam logged it as a timeout.

Check signal levels in your receiver's menu. SNR below about 12 dB on most setups, or signal quality below 80%, starts producing corrupted packets. That includes corrupted ECMs. NCam can't decode a garbled ECM; it times out waiting for a response that can't come because the input was garbage to begin with. Try the same channel on a transponder with known-good signal strength and see if timeouts disappear. If they do, the problem is your dish, LNB, or cable run — not NCam.

Step-by-Step Diagnostic Workflow

The biggest mistake people make is changing two or three things at once and then not knowing which one worked. Here's the runbook I use. Change one variable. Observe for 15 minutes minimum. Then move to the next step.

Enable Detailed Logging (Debug Level) Safely

In oscam.conf [global], bump up logging temporarily:

[global]loghistorysize = 2000debuglevel = 64

Debug level 64 gives you ECM routing detail without the extreme verbosity of full debug (255). Do not leave full debug on permanently — on embedded hardware with slow storage, writing megabytes of log per hour to flash memory will shorten the device's life and can cause I/O lag that affects decoding itself. Enable it, reproduce the issue, then drop it back.

Correlate Log Timestamps with the Freeze

When a channel freezes, note the exact time. Pull the log and look 5–15 seconds before that timestamp — ECM timeouts show up before the visible freeze because the control word runs out slightly after the request fails. If you see a cluster of timeout lines at 21:04:25 and the screen went black at 21:04:33, that's your event. Note the CAID, PROVID, and SID from those lines.

Test One Reader at a Time

In oscam.server, disable all readers except one by adding enable = 0 to each block you want to skip, then reload. Force a tune to the problematic channel. Watch the webif Status tab — specifically the ECM time column and the ecmok/ecmnok counters for your active reader. If that reader times out with zero load (just your single session), the problem is that reader's latency or your connection to it. If it responds fine, re-enable the next reader and test with both.

This single-reader approach is the fastest NCam ECM timeout fix diagnostic I know. It eliminates load balancer issues and reader interaction effects immediately.

Confirm the Fix Without False Positives

One successful channel zap does not confirm a fix. NCam caches the last valid control word briefly, so you can zap, get a picture, think it's fixed — and then it freezes 10 seconds later when the next crypto period hits and the same timeout happens again. Watch the ecmok counter in webif for 15 minutes minimum, on the specific channel that was failing. You want to see ecmok incrementing every 10 seconds with ECM times well below your timeout setting, with zero ecmnok events during that window. That's a confirmed fix.

How to Choose a Reliable Upstream Source

Getting a solid upstream peer is the long-term NCam ECM timeout fix that no amount of local config tuning can replace. Here's what actually matters when evaluating a source.

Criteria That Correlate with Low ECM Time

ECM response time is the single best predictor of reliability. Any decent peer should be delivering sub-700 ms response times for the CAID you need, measured during peak hours — not just at 2 AM when the server is idle. Geographic proximity matters here: a server physically close to you on a low-latency network path will always outperform a "premium" server on a congested transatlantic route.

Hop count is the other big one. A card shared 1 hop from the source (peer is running the actual card) will always beat a card 3 hops deep through a resharing chain. Each hop adds latency and a potential failure point. Ask specifically how many hops from the physical card your ECM request travels. Anything above 2 is a red flag.

Red Flags That Predict Frequent Timeouts

ECM times above 1200 ms during a test period should disqualify a source immediately. That's already 40% of your default timeout budget spent, with zero margin for variance. Servers with no client limit tend to get progressively worse over time as they onboard more users — watch whether ECM times are stable over a 30-minute observation window or slowly climbing.

No test period offered is itself a red flag. Any operator confident in their server's performance will let you test it. If you can't verify ECM time before committing, you're flying blind.

Testing Before Committing

Configure the new peer as a single reader in oscam.server with all your other readers disabled. Run it through an evening peak period — that's when oversubscription shows up. Watch the ECM time column in webif. A server showing 350 ms at noon and 2400 ms at 20:00 is oversubscribed and will cause timeouts regularly. A server holding 400–600 ms through peak hours is worth keeping. The ecmnok/ecmok ratio should stay well below 5% on a reliable source — if you're seeing 15% ECM failures even when response times look okay, there's a filtering or entitlement issue to investigate separately.