Focus SAT CCcam/OScam Setup: Config & Troubleshooting

If you're running a softcam server and your focus sat channels keep landing on a black screen, freezing every few seconds, or spitting ECM errors in the log, the problem is almost certainly not your dish. Nine times out of ten it's a misconfigured reader block, a mismatched CAID, or a timeout that's either strangling valid CWs or waiting so long the channel is already mid-freeze before the key arrives.

This article is for people already in the middle of setting this up — you have a line, you have a server running, and something specific is broken. The focus sat package sits primarily on Hot Bird 13E and Thor 0.8W/1W depending on your region, and the encryption setup has some quirks that trip up even experienced configs.

Start by capturing the live CAID before touching anything else. Static values you find posted on forums are unreliable — operators rotate them, and a previously working config can fail silently overnight.

Identifying the Focus SAT CAID and Provider IDs

This is where most people skip ahead and then spend hours troubleshooting the wrong thing. The CAID and provider ID are the foundation — get them wrong and nothing downstream will work, no matter how clean your oscam.server looks.

Reading CAID/provider from the channel info screen

Tune to an encrypted focus sat channel that you know should decrypt. On most Enigma2 images, press the Info button twice or long-press to get the technical details view. You want the CA system line — it'll show something like 0B00:000000 or a similar hex pair. The first half is the CAID, the second is the provider ID.

On OpenPLi and OpenATV, the extended info screen (usually accessible via the blue button > Signal) will list the active CA descriptors in the PMT. On Vuplus images running Black Hole, the same data is under Menu > Information > Tune Status. The exact path varies by skin, but every modern Enigma2 image exposes this somewhere.

Write down the exact hex values. Don't assume. The provider ID in particular varies across transponders carrying the same package, and getting it wrong is the single most common cause of a channel appearing to be FTA but frozen.

Confirming the CAID with OScam webif (Reader > Entitlements)

If you have the OScam webif running (default port 8888), go to Readers and click on your active reader. The Entitlements tab shows what the card or line actually exposes. Cross-reference this with what the receiver reported.

The more useful diagnostic tool is the live log. Grep the OScam log for ECM activity on that channel:

grep -i ecm /var/log/oscam/oscam.log | tail -50

Or if you're running oscam with the log going to stdout through your init system:

journalctl -u oscam -f | grep -i "ecm\|caid\|reader"

Each ECM line gives you the full CAID:provid:srvid triplet — for example 0B00:004A01:1234. The service ID (srvid) is channel-specific. The provid is what you need in your reader's ident field.

Why the wrong CAID makes channels appear FTA-but-frozen

Here's a scenario that catches people: the channel has an unencrypted component (like a free preview window or a different transponder frequency carrying the same service FTA). The receiver locks onto it, the channel appears to play, and then it freezes or pixelates because the main stream is actually encrypted and no CW is arriving.

Also watch for channels that are FTA on one transponder and encrypted on another carrying the same service ID. If your scan picked up the FTA version first, the receiver might route ECM requests to the wrong entry in its channel list. Deleting and rescanning just the encrypted transponder usually fixes this.

If OScam's log shows the ECM request arriving but no matching reader being found, or shows the reader rejecting it, that's a CAID or ident mismatch — not a network problem.

OScam Reader and ECM Configuration

OScam config files live in different places depending on your image. On OpenPLi it's typically /etc/tuxbox/config/oscam/. On images using the tuxbox layout it might be /var/config/oscam/. On some OpenATV builds you'll find it under /etc/oscam/. Check where your running instance is pointing with:

ps aux | grep oscam

The -c argument in the process line tells you the config directory.

oscam.server reader block: caid, ident, group

Here's a clean starting-point reader block for a remote protocol share — this covers newcamd and cccam readers, adjust the protocol line as needed:

[reader]label = focus_peer1protocol = cccamdevice = your.server.host,12000user = youruserpassword = yourpasscaid = 0B00ident = 0B00:004A01group = 1cacheex = 0lb_weight = 100ecmwhitelist = 0B00:@300reconnecttimeout = 30

The ident line is the one most configs get wrong. It needs the CAID prefix followed by a colon and the provider ID you captured from the live log. If the provider has multiple IDs active, list them comma-separated: ident = 0B00:004A01,004A02.

The group value needs to match the group assigned to the user in oscam.user — that group mismatch is the other main cause of "no matching reader" entries that people chase for hours.

oscam.user with au and group binding

Your user account in oscam.user needs the same group number and the right CAID scope:

[account]user = localclientpwd = clientpassgroup = 1au = 1caid = 0B00ident = 0B00:004A01

If you have multiple readers in different groups, the user needs to be in the group that contains the reader carrying this package. If the reader is in group 1 and the user is in group 2, OScam will log the ECM as coming in but have nowhere to route it. The log entry looks like "no matching reader" or "rejected" — not an authentication failure, just a routing miss.

Setting ECM timeout and lb_ retry behavior in oscam.conf

Open oscam.conf and find the [global] section. The key values:

[global]logfile = /var/log/oscam/oscam.logmaxlogsize = 500ecmfailures = 3waitforcards = 1[lb]lb_mode = 1lb_save = 100lb_nbest_percaid = 1lb_retrylimit = 800lb_retrylimits = 0B00:1200

The lb_mode = 1 enables load balancing by ECM response time. This is what you want when you have multiple readers — it'll prefer the fastest one. But set lb_nbest_percaid too high (3 or 4) and it starts polling slow or dead readers unnecessarily, which actually increases freeze frequency during peak load. Start at 1 and raise it only if you have confirmed-working redundant readers.

lb_retrylimit in milliseconds tells OScam when to consider a reader too slow and try another. 800ms is reasonable for a low-latency local network reader. For remote peers with variable RTT, push this to 1200–1500ms. Setting it at 200ms on a remote reader will cause it to constantly retry and hit timeout.

The per-CAID override lb_retrylimits = 0B00:1200 lets you tune specifically for this package without affecting others.

Cache and CW handling for stable output

OScam's CW cache (cwcache) can actually cause a specific class of freeze: the receiver gets a valid CW, plays fine, you change channel and come back, and it's black for a few seconds. That's the cache serving a stale CW from the previous session on the same SRVID. The crypto key has rotated but the cache hasn't expired.

If you're seeing this pattern specifically on channel changes, add to oscam.conf:

[cache]cwcachesize = 2000cwcachetime = 15

A 15-second cache lifetime is usually safe for standard 10-second CW rotation periods. Going higher risks serving stale keys.

CCcam Configuration and Line Priority

If you're using CCcam rather than OScam as your primary softcam, the config lives in /etc/CCcam.cfg. The syntax is different but the concepts are the same — you need to tell CCcam which CAID to route through which connection, and you need to control hop behavior.

CCcam.cfg C-line and F-line basics

A C-line is your outgoing client connection to a sharing server. An F-line is an incoming peer that's allowed to connect to you. For decoding the package you need a C-line:

# Connect to a sharing serverC: yourserver.host 12000 youruser yourpass# Allow a local peer to connect (optional)F: localuser localpass 1 0 0 0 0

Port 12000 is the CCcam default and most servers use it. If you're connecting to a newcamd server instead, use an N-line with port 15050 (also a common default). Verify your line is actually connected by accessing the CCcam info page — typically at http://receiver-ip:16001 — and checking the Connected Servers section. Green means connected, red means the handshake failed.

Using CAID/ident priority and ignore lines

CCcam has P: (priority) and I: (ignore) directives that steer routing for specific CAIDs. If you have multiple C-lines and one is clearly better for this package, use:

# Prioritize this server for CAID 0B00P: 0B00:004A01# Ignore a specific peer for this CAID (if it's slow)I: 0B00:004A01 badserver.host

Without these directives, CCcam round-robins between connected servers and you'll get inconsistent decode times. During prime time when one server degrades, this causes intermittent freezes that look random but are actually load-related.

Forcing a specific reader hop for the package

Hop count matters a lot for decode reliability. A hop-1 reader means the card is directly connected to the server you're talking to. Hop-2 means one relay between you and the card. In my testing, hop-1 and hop-2 are generally fine for stable decode. Hop-3 and above introduces latency variance that shows up as freezes during fast ECM rotation.

CCcam exposes hop information in its status page. Under Connected Cards, you'll see the hop count for each CAID entry. If the package is showing hop-4 or higher, that server is not getting its card directly — it's relaying through multiple nodes. Either find a better source or accept the instability.

You can also limit which hops CCcam will use:

ALLOW SIDMAPPING = noIGNORE RESHARE DISTANCE = 3

The IGNORE RESHARE DISTANCE setting tells CCcam to refuse CWs arriving from more than N hops away. Setting it to 2 filters out high-hop garbage at the cost of reducing your fallback options.

Troubleshooting Freezes, Black Screens, and ECM Errors

Before blaming the softcam, always rule out signal first. Tune to a free-to-air channel on the same transponder. If that's also pixelating or dropping, your problem is LNB/dish, not configuration. Only start debugging the softcam once you've confirmed the transponder is locked and FTA channels are clean.

Reading ECM response times in the log

OScam logs ECM response times in milliseconds on each CW line. A healthy decode looks like:

2026/06/03 21:14:02 c [SRVID 1234] ECM answered (0B00/004A01) by focus_peer1 (220ms)

Under 400ms is solid. 400–1000ms is marginal but usually okay for 10-second CW rotation. Anything repeatedly hitting 3000ms+ means the reader is struggling. If you see 9000ms followed by a timeout, the reader gave up — that's your freeze right there.

The pattern to watch for is CW found but arriving late. The channel appears to play, then hitches every time the key rotates. OScam found the CW, but it took 2800ms on a 2500ms window. The fix is either a faster reader source or a higher ecmtimeout to give slow readers more time.

Fixing recurring 'no matching reader' / 'rejected' entries

If the log consistently shows "no matching reader" for a specific CAID:provid pair, work through this in order:

1. Check that the reader block in oscam.server has the correct caid and ident values matching what you captured live
2. Verify the reader's group number matches the user's group in oscam.user
3. Confirm the reader is actually connected — check the webif Readers page for "connected" status
4. If using cacheex, check whether the cache is serving a rejection from a previous failed attempt

"Rejected" is different — it usually means the reader connected but the card or server actively declined the ECM. This happens when you're sending ECM requests for a CAID the server doesn't carry, or when the ident filter on the remote end is blocking your request.

Network and MTU issues over remote peers

This one is easy to miss. If your freezes happen specifically on HD streams and specifically on remote peers (not local network readers), MTU fragmentation is a strong candidate. HD streams have larger ECM payloads, and a remote link with MTU set to 1500 but going through PPPoE or a VPN tunnel with lower effective MTU will fragment those packets. Fragmented CW packets often arrive incomplete, triggering timeout.

Test it: ping -M do -s 1472 your.peer.server. If you see "fragmentation needed" errors, drop your MTU. On Linux, set it on the interface:

ip link set eth0 mtu 1400

Or set it permanently in your network config. 1400 gives enough headroom for most tunnel overhead. After changing, restart oscam and watch if the HD-only freezes clear up.

Distinguishing signal/LNB problems from softcam problems

A quick decision tree:

• FTA channels on same transponder freeze → signal/LNB problem. Stop here, fix your dish.
• FTA fine, encrypted channels black screen immediately → softcam not connecting, likely CAID mismatch or reader not connected.
• Plays for 10–30 seconds then freezes → CW rotation timeout. ECM is slow or failing on key rotation.
• Freezes only during prime time → source server overloaded. Off-peak it's fine. Check ECM times during both periods.
• Works after restart, breaks after channel changes → stale CW cache. See the cwcachetime fix above.

The receiver's own ECM cache can also mask problems temporarily. Some STBs cache the last valid CW for a few seconds after it expires. This makes a broken config appear to work right after a restart, then fail 10–15 seconds later once the cached key expires and a fresh ECM is needed.

Choosing a Reliable Sharing Source (Generic Criteria)

When you're evaluating any source for the focus sat package — or any package — the technical indicators matter more than anything else. A fast ECM response at 2am means nothing if the server melts at 8pm when half its subscribers are online simultaneously.

Uptime and stability indicators to test for

Run your OScam reader for at least 24 hours before concluding a source is stable. Watch ECM response times at these specific windows: 7–9am, 12–2pm, 6–10pm. The evening window is where overloaded sources show their real performance. If you see ECM times jumping from 180ms off-peak to 2400ms during prime time, that source will give you freezes when it matters most.

OScam logs everything. After a day of runtime, run:

grep "focus_peer1" /var/log/oscam/oscam.log | grep -v "not found" | awk '{print $NF}' | sort -n

That gives you a rough distribution of response times for that reader. If the 95th percentile is under 800ms, you're in good shape. If it's over 2000ms, expect freezes.

Hop count and local-vs-remote card reasoning

A source with direct card access (hop-1 in CCcam terms) will always outperform a reshare chain under load. The reason is simple: each hop adds its own processing latency and introduces another potential point of failure. During peak demand, a hop-3 chain might be waiting on two intermediary nodes to process before your CW arrives.

If you have the option, a source where the operator physically holds the card and the server is colocated with it will consistently outperform a reshare. The RTT from your receiver to the card is what drives ECM time, and every hop in the chain adds to that.

A legitimate setup means you or your source have entitlement to the card being shared. Keep that in mind when evaluating options — using a card you're not entitled to is both a legal risk and a technical one, since operators can detect sharing patterns and invalidate the card without notice.

Red flags that predict freezes

Walk away from any source that shows these:

• ECM response times that vary wildly — 150ms one minute, 4000ms the next — indicates an overloaded or flapping connection
• Hop count of 3 or higher in CCcam status
• Frequent reconnects visible in the OScam log (more than once per hour under normal conditions)
• No response to the specific CAID/provid combination you need — the server is resharing cards that don't cover your package
• Performance that's stable for an hour then degrades — suggests a bandwidth cap or session throttle kicking in

And one edge case worth knowing: operators periodically rotate provider IDs for focus sat and other packages on Hot Bird. If a config that worked fine for months suddenly starts logging "no matching reader" with no changes on your end, check the live CAID/provid values again. Your ident line may now be pointing at a stale provider ID that the operator retired.