NCam error ECM 28: causes and solutions in OScam/CCcam

If the status 28 appears in the NCam logs and the channel goes to a black screen — this is not a receiver glitch and not a reason to reflash the hardware. ECM 28 means strictly one thing: the control word request was sent, but a valid response did not return in the allotted time. It is important to understand this right away because most "advice" on the internet boils down to "increase the timeout" — and this is the worst thing you can do. Here we will break down NCam: ECM 28 solution step by step: from reading the log line to editing configs and choosing a normal key source.

What does ECM 28 mean in NCam and why it is not a bug of the receiver

ECM 28 is an internal status of NCam indicating a timeout when receiving CW (control word). NCam sent an ECM request to the reader or remote server, but either the response came later than the set limit, or it came invalid and did not pass the check. The channel is not decoded, the screen is black.

Important: this is a problem at the intersection of NCam and the key source. The receiver itself is not involved at all — it simply does not receive the CW, which has no one to give it to.

Decoding status 28: ECM sent, but valid response not received in time

In the NCam protocol, the status of the ECM request is encoded as a number. 28 (or in hex 0x1C) meansE_NOTFOUND with a timeout indication — that is, the request was formed and sent, the reader accepted it (or was supposed to accept it), but the CW in the response either did not come or came invalid. Do not confuse this with a situation where the reader did not respond to the connection at all.

How to read the log line: CAID, provider ID, PID, response time

Here is a typical NCam log line that signals a problem:

2026/03/15 21:43:07   7F2A ECM caid 0500 prov 042800 pid 0041 srvid 05A0 -- 28 (650 ms) by reader01

Breaking down the fields:

• caid 0500 — conditional access system identifier (here Viaccess)
• prov 042800 — provider ID of the specific package
• pid 0041 — PID of the stream in the transponder
• srvid 05A0 — service/channel ID
• 28 — status: timeout/no valid CW
• 650 ms — actual waiting time until timeout
• reader01 — which reader processed the request

A time of 650 ms with a limit of, say, 5000 ms — means the reader responded, but the CW turned out to be incorrect. If you see a value equal to your ctimeout (for example exactly 5000 ms) — there was no response at all.

How ECM 28 differs from 'card not found' and 'no matching reader'

card not found — NCam did not find a reader that claimed support for this CAID at all. Routing did not occur even at the level of reader selection.

no matching reader — there are readers, but none match by CAID/ident/group. The ECM did not go anywhere.

ECM 28 is a fundamentally different situation: a reader was selected, the request was sent, but there is no working CW at the output. This is already a problem either with the reader/source itself, or with the network between them, or with the timeout configuration.

Main causes of ECM 28 and quick diagnostics

Before changing anything in the configs — enable detailed logging. In/etc/tuxbox/config/ncam/ncam.conf set up:

[global]

Then watch the log in real time:tail -f /tmp/ncam.log | grep "ECM\|28". Already from the pattern of 28-errors, much becomes clear.

Symptom in the log	Probable cause
28 exactly every N ms (= ctimeout)	The reader does not respond at all, the network or server is down
28 with a time less than ctimeout	CW arrived, but invalid (desynchronization, overload)
28 only on one CAID/provider	Mismatch caid/ident or the source does not hold this packet
28 periodically, the rest is okay	Peak load on the source or unstable network
28 only in the evening 19:00–23:00	Source overload during prime time
28 after key changes on the channel	A restart of the reader is needed, the source has not yet synchronized
28 only over Wi-Fi	Unstable ping, disappears on cable
28 via VPN	Additional VPN delay exceeds rtimeout

Timeout: the response comes later than the limit in ncam.conf

The most common reason. If your ping to the source is 80 ms, and CW is processed on the server for another 200–300 ms — a total of 380+ ms. With ctimeout=300 this is a guaranteed 28. But raising ctimeout to 10,000 ms is a bad idea, more on that below.

Mismatch CAID/provider — ECM goes to the wrong reader

NCam builds ECM routes by CAID and ident (provider ID). If in the block[reader] an incorrect ident is specified or it is not specified at all — the request will either go to an unsuitable reader or not go anywhere. Result: 28 orno matching reader.

The server responded, but CW is incorrect

This happens during source overload or desynchronization: the server gives CW, but by the time of delivery it is already outdated. Especially noticeable on channels with frequent CW changes (interval 3–5 seconds instead of the standard 10). In the log, you will see 28 with a response time less than ctimeout.

Network losses and high ping

Check simply:ping -c 20 [source_address]. If you see packet loss or jitter under 50 ms — this is your reason. The problem is exacerbated over Wi-Fi, especially in an apartment building. Cable eliminates this instantly.

Incorrect connection protocol

CCcam and newcamd are different protocols with different ports. If the source expects a connection via newcamd on port 15000, and you connect as CCcam on 12000 — the connection may be established, but ECM requests will be ignored or return garbage. Always clarify with the source: protocol, port, key format.

Step-by-step solution: editing the configs of NCam and OScam/CCcam

NCam configs are located in/etc/tuxbox/config/ncam/ or/var/tuxbox/config/ncam/ — it depends on the firmware. Key files:ncam.conf,ncam.server,oscam.dvbapi. If you are using OScam on the client side — the equivalents:/etc/oscam/oscam.conf,/etc/oscam/oscam.server.

Increasing the timeout: parameters ctimeout, rtimeout, lb_reopen_seconds

Reasonable values for a normal source with a ping of up to 100 ms:

[global]

ctimeout — maximum waiting time for CW in milliseconds. 5000 ms is a working benchmark for most configurations.rtimeout in the[reader] block can be set individually: take the average ping to the source, multiply by 3, and add 500 ms of buffer.

lb_reopen_seconds = 120 — how many seconds the load balancer will try the "bad" reader again. A value that is too small creates unnecessary attempts on a non-working source.

Checking and fixing the [reader] block

Example of a correct block for newcamd connection inncam.server:

[reader]

Critical fields:caid — must match what your channel is broadcasting.ident — provider ID in the formatCAID:PROVIDERID. These values are taken from the NCam log (fieldprov) or from databases of the typedvbapi. If the ident is not specified, NCam will send ECM to all readers with the required CAID, which is inefficient.

For the CCcam protocol, the block looks different:

[reader]

Configuring ECM routing and reader priority (lb_mode)

For diagnosing ECM 28, first disable the load balancer:

[global]

With LB disabled, NCam will use readers in the order they are listed inncam.server. This way, you can immediately see which reader is giving 28 — check the fieldby readerXX in the log. After diagnosis, you can returnlb_mode = 1 (round-robin) orlb_mode = 5 (by response time).

If several readers support the same CAID, LB will choose the fastest one. But if a "slow" reader consistently gets into the rotation under peak load, it will give 28. Uselb_weight to manage priority.

Correct ports and protocol

De facto standards used by most servers:

• newcamd: ports 15000–15010
• CCcam: 12000 (standard) or 12001–12010
• cs378x (Camd 3.5x): 15001 or custom
• radegast: 8000

The cs378x protocol is sometimes preferable to newcamd for specific CAIDs — it puts less load on the server's CPU and is faster with a stable network.

Checking caid/ident in oscam.dvbapi

The fileoscam.dvbapi controls which ECM requests NCam will generate at all. If it contains an incorrect CAID or does not include the required package, requests will either not be formed or go to the wrong place.

P: 0500:042800

Check: CAID and provider ID indvbapi must match what you see in the NCam log in lines 28. Restart after making changes:systemctl restart ncam or/etc/init.d/ncam restart, thentail -f /tmp/ncam.log.

What does not help with ECM 28 (typical mistakes)

I want to say right away: most of the things people do first are useless. Or even make it worse.

Endless increase of the timeout instead of searching for the cause

ctimeout = 30000 — this is not a solution, it's a disguise. Yes, the channels will stop "disappearing" immediately. But instead, you will get freezes of 10–15 seconds because the decoder is waiting for a CW that will not come anyway. Users complain about the "freezing" of the picture — this is your huge timeout in action.

A normal working ctimeout for a source with a ping of up to 50 ms is 3000–5000 ms. For sources via VPN or with a ping of 150+ ms — up to 7000 ms. More is not needed.

Blindly copying someone else's ncam.server

The internet is full of "working configs." The problem is thatdevice,user,password,key — these are the credentials of a specific user for a specific source. Even if you take the config of a person with the same receiver — you have a different account, a different IP, possibly a different CAID list.

Moreover,caid andident depend on what channels you are watching. In someone else's config, there are STRANGE channels listed.

Changing the receiver firmware

I've seen this many times: a person tries Enigma2, then OpenPLi, then OpenATV — ECM 28 remains everywhere. Of course. The firmware of the receiver does not affect how the remote server processes ECM requests. NCam is the same everywhere, the key source is the same, the network is the same.

Restarting the receiver as a universal solution

Helps in exactly one case: if the NCam process itself is stuck or memory has leaked. In other cases, you restart, NCam comes up, connects to the same non-working source — and you get the same 28. The only thing that sometimes makes sense is to restart NCam itself with the command/etc/init.d/ncam restart, not the entire receiver.

A separate case — 28 after changing keys on the channel (key change). Here, restarting the reader really helps:ncam -r readerlabel or through the NCam web interface. The key source may not have distributed new CW to all clients yet.

How to choose a stable key source so that ECM 28 does not repeat

NCam: ECM 28 solution at the config level works only if you have a normal source. If the source is overloaded or unstable — no timeouts will help. So choosing a source is half the battle.

Criteria: low ping, stable ECM response time

Look in the NCam logs for the average response time for your reader. Lines with successful ECM (statusfound) contain the time in ms. A normal source gives 100–350 ms consistently. If you see a range from 80 to 2000 ms — the source is unstable or overloaded.

Ping — a necessary but insufficient condition. Ping 20 ms, and ECM 800 ms — means there is a problem on the server side (weak hardware, many clients). Ping 80 ms and ECM 250 ms — this is normal.

Support for the required CAID/provider without reconnections

Before binding to a source — check that it actually supports your CAID and specific provider ID. Look in the NCam logs: upon successful connection, NCam writes a list of supported CAIDs from the reader. If yours is not there — the source is not suitable for you, no matter how much it costs.

Frequent reconnects in the log (connection lost,reconnecting) — a red flag. A normal source maintains the connection for hours without interruptions.

Transparent limits on the number of ECMs and channels

Each source has limitations: how many ECMs per second, how many simultaneous connections, how many channels in parallel. If these limits are not disclosed — you will not know why you periodically receive 28 during prime time (the answer: you are being cut off by the rate limiter).

Trial period to check on your channels

The only honest way to test a source is to run it on your real channels for at least 48–72 hours. Including prime time (19:00–23:00), when the load is maximum. Look in the NCam logs for the percentage of 28 from the total number of ECM requests. An acceptable level is less than 1–2%. Anything above that — the source is struggling.

For self-calculation:grep "reader01" /tmp/ncam.log | grep -c " 28 " andgrep "reader01" /tmp/ncam.log | grep -c "found". Divide the first by the sum — you will get the share of unsuccessful ECMs.

Here is the complete picture of NCam: ECM 28 solution — from log diagnostics to source selection.