NCam EMM Error Solution: Fix OScam EMM Processing

If you're seeing EMM errors in your NCam or OScam logs, you already know the frustrating pattern: channels decode fine for a while, then start dropping — or worse, freeze days later when you're not watching. The right NCam EMM error solution isn't about randomly toggling flags. It's about reading what the log is actually telling you and fixing the specific layer that's broken. This guide assumes you already have a working cardsharing chain and are mid-troubleshoot, not starting from scratch.

What an EMM Error in NCam Actually Means

NCam handles two completely different types of messages from your operator, and mixing them up is the source of most confusion. ECM (Entitlement Control Message) is what decrypts the stream in real time — it runs constantly while you're watching. EMM (Entitlement Management Message) is different: it's the operator periodically writing new entitlement data, expiry dates, and keys to the physical smartcard itself.

AU — Auto Update — is the process by which NCam passes EMMs through to the card reader so the card stays current. Without it, your card's entitlements quietly expire and decoding stops, even though ECM was working perfectly up until that point.

EMM vs ECM: Why Entitlement Messages Matter

ECM is short-lived and stateless. Every few seconds, a fresh ECM arrives, gets decrypted using the card's current key, and the stream plays. EMM is the mechanism that keeps those keys valid. An operator might send EMMs every few hours, or once a day, or in a burst when your subscription renews. If those writes never reach the card, the card runs on borrowed time.

Most setups decode fine for days or weeks after AU breaks. Then one morning the card's entitlement period lapses and everything goes black simultaneously. That delayed failure is why EMM errors often get ignored until it's too late.

Reading the Exact NCam Log Line

NCam produces several distinct EMM log signatures. Here's what you'll actually see:

• emm reader [readername] CAID 0x0500 rejected (not written) — The reader received the EMM but the card rejected it. AU may be off, or the card doesn't hold the provider rights for this message.
• EMM_UNKNOWN — NCam received an EMM it couldn't classify. The CAID or provider ident doesn't match anything it knows how to handle.
• emmtype: unique / shared / global — Shows which EMM category arrived. Unique targets your specific card serial; shared targets a group; global goes to all cards on the network.
• no card support — The reader exists but no physical card is responding.

A single EMM_UNKNOWN line in the log is almost always harmless. What you're looking for is a pattern: hundreds of rejected lines with no successful writes, or the EMM write counter in the web interface showing zero for hours on a card that should be getting updates.

When an EMM Error Is Harmless vs When It Breaks Decoding

Operators commonly send EMMs for provider IDs the card doesn't hold. If you subscribe to a basic tier, you'll still receive (and legitimately reject) EMMs for premium packages you haven't paid for. That floods the log with rejected lines that are completely normal.

The failure case is different: the card receives EMMs for providers it does hold, they get rejected because AU is misconfigured, and the card's entitlement clock runs out. That's the one you need to fix.

Step-by-Step EMM Error Diagnosis

Before changing any config, get the logs talking. You can't diagnose what you can't see. Finding a working NCam EMM error solution always starts here.

Enable EMM Logging and Raise Debug Level

In /etc/oscam/oscam.conf, set the log file and raise the debug level:

[global]logfile = /var/log/ncam.logdebuglevel = 64

Debug level 64 enables EMM-specific output. If you want everything, use 255 — but that's very noisy. In the NCam web interface (typically at port 8888), go to Config → Logging and set the web interface debug level to 4 to see EMM counters per reader in real time.

Also set these in your reader block to save raw EMM data to files for inspection:

saveemm-u = 1saveemm-s = 1saveemm-g = 1saveemm-unknown = 1

This saves unique, shared, global, and unknown EMMs to files under your config directory (usually /etc/tuxbox/config/ or /var/keys/ depending on your Enigma2 image). Having the raw bytes lets you verify the EMM content independently of NCam's classification.

Confirm Whether AU Is Actually Enabled for the Reader

Check your reader block in /etc/oscam/oscam.server. AU must be explicitly enabled:

[reader]label = local_camprotocol = mousedevice = /dev/ttyUSB0caid = 0500ident = 050000:XXXXXXau = 1

And on the user account in /etc/oscam/oscam.user, the account that owns the session must point AU at that reader:

[account]user = localuserau = local_cam

Both sides need to match. A reader with au = 1 but no user pointing at it won't write anything. A user with au = local_cam but the reader set to au = 0 won't either.

Check CAID, Provider ID, and Box Type Match the Card

The caid and ident in your reader block must exactly match what the physical card reports. Pull the actual CAID and provider ident from the NCam web interface under Readers → your reader → Card Info. If what's in the config doesn't match what the card reports, ECM might still limp along on a cached key while every EMM gets rejected.

For cards that need a box key (Conax, Cryptoworks, some Irdeto variants), verify boxid, boxkey, and rsakey are present and correct. One wrong hex digit here silently breaks AU while leaving ECM functional — a deeply annoying failure mode.

Verify EMM Is Reaching the Reader, Not Just the Proxy

Watch the EMM counters per reader in the web interface. If the counter on a proxy reader is climbing but the local card reader shows zero, EMMs are stopping at the proxy layer and never reaching the physical card. That's expected behavior for most sharing protocols — and fixing it requires understanding the next section.

NCam EMM Error Solution: Fixing the Most Common EMM Errors

EMM Rejected / Not Written — AU and Rights Mismatch

This is the most common one. The fix checklist:

1. Set au = 1 on the reader in oscam.server
2. Set au = readerlabel on the user account in oscam.user
3. Confirm the card actually holds provider rights for the CAID/ident in question — if it doesn't, rejection is correct behavior
4. Check that aufilter and auprovid aren't incorrectly filtering out the EMMs you need

If you have two readers or two profiles both trying to do AU for the same card, they'll fight each other and produce inconsistent writes. Assign AU explicitly to a single reader and disable it on all others for that card.

EMM_UNKNOWN — Wrong CAID or Unsupported EMM Type

NCam logs EMM_UNKNOWN when it receives an EMM it can't classify against the configured CAID. This is usually a mismatch between what you've set in the config and what the operator is actually sending.

First, verify the CAID via the card info page. Then check whether your NCam build actually supports AU for that specific CAID/system. Not all builds support all conditional access systems equally. For testing only, you can set blockemm-unknown = 0 to let unknown EMMs through — but do not leave this on, and read section 4 before you do it.

No AU Over a Sharing Protocol (CCcam/Newcamd Proxy)

This is the one most guides miss entirely, and it wastes hours of troubleshooting time.

A pure CCcam or newcamd sharing connection does not carry EMM. The protocol is designed to forward ECM responses (decrypted control words), not to deliver management messages to a remote card. If your card is shared to a peer via /etc/CCcam.cfg and that peer is expecting AU, it won't get it — ever — through that connection.

The card must be physically present in the box doing AU. If you need entitlement updates, either the card stays local or the sharing peer runs its own local card. There's no workaround for this at the protocol level.

Wrong Box Key / Card Not Personalised

Some conditional access systems require the card to be paired with a specific box. Conax and certain Irdeto implementations use a boxid (the box's hardware serial) and a boxkey derived during pairing. If you've moved the card to a different STB or entered the wrong values, AU will fail while ECM might still function using a cached key.

Re-enter boxid and boxkey from the original pairing data. For Conax, the boxid is 8 hex digits; the boxkey is 16 hex digits. Get these from the actual hardware or the original pairing exchange — there's no recovering them from a bad config entry.

EMM Flooding and Reader Timeouts

Some operators blast hundreds of EMMs per minute. A reader that can't process them fast enough will queue, timeout, and start producing errors that look like AU failures but are actually throughput problems.

Use emmcache to deduplicate identical EMMs before they hit the reader:

emmcache = 1,3,20

This caches EMMs and only sends a new unique one to the reader (format: enabled, maxemms, initial_wait). Also use blockemm-bylen to drop EMMs of specific byte lengths that you know aren't relevant to your card. And ratelimitecm can help if a client is hammering the reader with ECM requests during the same window.

EMM Filtering and Throttling for Card Safety

This section matters more than most guides admit. Accepting all EMMs without filtering is not a debugging strategy — it's how cards get bricked.

Why Uncontrolled EMM Writes Can Brick or Lock a Card

Global and shared EMMs can overwrite key entitlement data on a card. A malformed global EMM, or one targeted at a different card profile, can corrupt the card's entitlement structure or trigger a lock state that requires the operator to re-initialise the card. With a legitimately owned subscription card, this is a recoverable situation if you contact your provider — but it's still a mess you want to avoid.

The risk goes up significantly if you're receiving EMMs from multiple sources or if the sharing chain passes messages through without filtering.

Using blockemm Flags to Protect Entitlements

These go in your reader block in oscam.server:

blockemm-unknown = 1blockemm-u = 0blockemm-s = 0blockemm-g = 1

This configuration accepts unique and shared EMMs (which are normally what a subscription card needs) while blocking global and unknown ones. The exact combination depends on your operator — some only use unique EMMs, some use shared. Watch the web interface counters for a few hours after configuring to confirm you're accepting the right types and seeing successful writes.

Whitelisting Only the EMMs Your Card Needs

Use auprovid in the reader block to restrict AU to specific provider IDs:

auprovid = 050000

This means EMMs for any other provider ID on the same CAID get dropped at the reader, not written to the card. Clean and safe. If your operator sends EMMs for multiple sub-providers, list them comma-separated. Get the exact provider IDs from the card info page — don't guess.

Monitoring EMM Write Counts in the Web Interface

The NCam web interface at port 8888 shows EMM statistics per reader: written, skipped, error, blocked. A healthy AU setup shows a steadily climbing "written" count and a stable or zero "error" count. If "written" is stuck at zero and "blocked" is climbing, your filter settings are too aggressive. If "error" is climbing with nothing written, the card is rejecting messages — that's an AU or rights issue, not a filter issue.

Check these counters after every config change. They're the ground truth.

When EMM Errors Are Not the Real Problem

Sometimes you spend an hour on EMM only to realize the actual fault is somewhere else entirely. Misdiagnosis here is common.

Decoding Works but the Card Silently Expires

This is the delayed-failure case. ECM decoding works fine, but AU has been broken for days or weeks. The card's entitlement period eventually lapses — which might be one day after a subscription renews, or three months later at natural expiry — and everything stops simultaneously. Because the failure is immediate and complete, it looks like an ECM problem at first glance.

Check the card's validity date in the NCam web interface under Readers → Card Info. If the expiry date is in the past, your NCam EMM error solution needs to focus on getting AU working again, then getting the card's subscription revalidated with your provider.

Mistaking ECM Failures for EMM Failures

An ECM timeout or wrong CAID priority in oscam.dvbapi produces channel drops that look just like an AU failure if you don't read the logs carefully. ECM errors appear as ECM timeout or invalid CW in the log; EMM errors appear as EMM rejected or not written. They're different log lines — look at both before concluding which layer is broken.

Also watch the ECM response time in the web interface. A working card with broken AU will show fast ECM response times right up until it expires. A card with ECM problems shows slow or failed responses immediately.

Image-Specific NCam Quirks and Log Differences

Config paths vary between Enigma2 images. On OpenATV, oscam config typically lives at /etc/tuxbox/config/. On OpenPLi it's often /etc/oscam/. On some builds, the default NCam binary doesn't compile in support for all CA systems, so EMM handling for certain CAIDs is simply absent — no amount of config changes will fix that.

After an image update, always verify that your config paths still apply. An update that moves oscam.server to a new location will silently invalidate your AU settings while leaving ECM working from a cached or hardcoded location. The saveemm files will also stop populating if the path moves.

Log date formats and field ordering also differ between NCam and OScam builds. If you're copying log analysis from a guide written for OScam 11.x and you're running an NCam fork from 2024, some field names will differ. Check your actual log output against the format, not just against what a tutorial says it should look like.