Canal Digitaal Cardsharing Setup: CCcam & OScam Guide

If you've landed here, you're probably staring at a black screen with a connected line and wondering what you broke. The Canal Digitaal cardsharing setup (CCcam/OScam configuration) is one of those things that looks straightforward until you're three config edits deep and channels still won't open. This guide covers the full process — real config blocks, actual file paths, and the specific things that go wrong and why.

This isn't a beginner primer. Assume you already have an Enigma2 receiver running, CCcam or OScam installed, and a sharing line or physical card in hand. What you need is the right config syntax and a way to diagnose what's failing.

Quick Answer: Minimum Working Config for Canal Digitaal

Before getting into the theory, here's what a working minimal config actually looks like. These are placeholder credentials — substitute your real line details.

CCcam Client Line (C: Line) Format

Open /etc/CCcam.cfg (or /var/etc/CCcam.cfg on some Enigma2 images) and add:

C: your.server.host 12000 yourusername yourpassword

That's the minimum. The C: line format is always C: hostname port username password. Port 12000 is the CCcam protocol default, though your provider may use a different port — confirm before you assume. Save the file, restart CCcam, and check the info panel at http://box-ip:16001 to see if the line shows as connected.

OScam Reader + Server Equivalent

OScam splits what CCcam does in one line across three files. The reader definition goes in /etc/tuxbox/config/oscam.server (or /var/etc/oscam/oscam.server depending on your image):

[reader]
label = canal_line
protocol = cccam
device = your.server.host,12000
user = yourusername
password = yourpassword
cccversion = 2.3.0
group = 1
reconnecttimeout = 30

In oscam.user, create a local account that the DVB API uses:

[account]
user = localclient
password = localpass
group = 1
au = 1

And the bare minimum for oscam.conf:

[global]
nice = -1
logfile = /tmp/oscam.log
[webif]
httpport = 8888

Which Ports and Files You Actually Need to Edit

For CCcam: edit only CCcam.cfg. For OScam: touch oscam.conf, oscam.server, and oscam.user. The oscam.dvbapi file is needed if OScam drives the tuner directly (common on Enigma2). The OScam config directory is usually /etc/tuxbox/config/ on older images and /var/etc/oscam/ on newer ones — ls /etc/tuxbox/config/oscam.* will tell you immediately which applies.

One thing that trips people up: on some boxes, /etc/ is a symlink or tmpfs mount that gets wiped on reboot. If your edits vanish after a restart, your actual persistent config location is somewhere else — usually /var/etc/ or a flash partition. Check where the running process reads from with ps aux | grep -i oscam and look at the -c argument.

Understanding the Canal Digitaal Encryption Setup

Canal Digitaal uses Irdeto 2 conditional access. Every encrypted channel broadcasts ECM (Entitlement Control Message) packets that carry the CAID and provider ID identifying which card can decrypt it. Your emulator intercepts these and routes them to a reader — either a physical card or a remote sharing line — that actually holds the entitlement.

CAID and Provider ID Basics

CAID identifies the conditional access system — for Irdeto 2 on this platform, you'll typically see something like 1833 or 1834 in hex in your logs. Provider ID (ident) narrows it further: different packages on the same CAID may have different provider IDs, and a sharing line might carry some but not all. This is exactly why certain channels open and others stay black even with a "working" line.

Why the Right CAID Matters for ECM Routing

OScam routes each ECM request to readers based on matching CAID and group. If the reader doesn't explicitly list the CAID (or if the CAID filter is wrong), OScam won't even try that reader. CCcam handles this more automatically but is less transparent about why a particular channel fails. In OScam, you can restrict which CAIDs a reader handles via the caid field — useful when you have multiple readers and want to avoid cross-routing, but also a common source of "line connected, channels dead" problems when the filter is too restrictive.

Reading Your ecm.info to Confirm the Card

On Enigma2, tune to a channel that should work and read /tmp/ecm.info. You'll see something like:

CAID: 0x1833
Namespace: 0x00000000
PID: 0x0200
Ident: 0x000000
Reader: canal_line

The CAID and Ident here are what the channel is requesting. The Reader field tells you which reader OScam used. If Reader is blank or shows "not found", ECM routing failed — the request never reached your line. If Reader shows your line but the channel is still black, the line answered but either returned a wrong CW or the response took too long.

Step-by-Step OScam Configuration

Here's a full annotated config walkthrough. This covers the most common Enigma2 setup where OScam handles both the remote line and the DVB API.

oscam.conf Global and Webif Settings

[global]
nice = -1
WaitForCards = 1
logfile = /tmp/oscam.log
maxlogsize = 200
preferlocalcards = 1
[webif]
httpport = 8888
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

nice = -1 gives OScam slightly elevated CPU priority — on slow boxes this actually matters for ECM response time. preferlocalcards = 1 routes ECMs to a physical card before trying network readers, which is what you want if you have a card in the slot alongside a sharing line as backup.

oscam.server Reader Block for a CCcam-Protocol Line

[reader]
label = canal_line
protocol = cccam
device = your.server.host,12000
user = yourusername
password = yourpassword
cccversion = 2.3.0
ccckeepalive = 1
group = 1
reconnecttimeout = 30
lb_weight = 100

The cccversion field matters. Some upstream servers reject connections from mismatched versions. 2.3.0 is widely accepted. ccckeepalive = 1 sends periodic pings to prevent the server from dropping idle connections — useful on lines that cut off after a few minutes of inactivity. Leave caid blank here unless you have a specific reason to restrict it; let OScam figure out what the reader provides from the server's card list.

oscam.user with Group and CAID Filtering

[account]
user = localclient
password = localpass
group = 1
au = 1
uniq = 0

The group value here must match the group value in your reader block. This is the most common configuration mistake I see. The reader is in group 1, the account must also request group 1 — if they don't match, ECMs from this account will never reach that reader. au = 1 enables card updates (entitlement messages) to pass through, which some setups need for the card to stay authorized.

oscam.dvbapi for the Local Tuner

[dvbapi]
enabled = 1
au = 1
pmt_mode = 0
boxtype = dreambox
user = localclient

The user here must match the account defined in oscam.user. boxtype = dreambox works for most Enigma2 receivers regardless of actual brand. If you're running on an OpenATV or OpenPLi image, this is the standard setting. Some images use boxtype = enigma2 — check what your image's documentation says if dreambox doesn't work.

Restarting and Reading the Log

Restart OScam with /etc/init.d/oscam restart or via your image's plugin menu. Then watch the log:

tail -f /tmp/oscam.log

Look for lines showing your reader connecting. A good sign is reader canal_line: connected to your.server.host:12000 followed by cards: 1 or more. The webif at http://box-ip:8888 → Status tab shows each reader's current state. Connected with cards > 0 means the line is live. Then tune a channel and watch for ECM lines — you should see the CAID, the reader used, and the response time in milliseconds.

Step-by-Step CCcam Configuration

CCcam is simpler to configure but harder to debug since it gives you less visibility into what's happening internally.

CCcam.cfg Client Lines and Options

The full CCcam.cfg for a basic client setup:

# Connect to sharing line
C: your.server.host 12000 yourusername yourpassword
# Optional: disable cache sharing to reduce server load
DISABLE SHARE PUSH: yes
# Log file
LOGFILE: /tmp/cccam.log
LOGFILE SIZE: 500
# Info panel port
WEBINFO LISTEN PORT: 16001

CCcam processes the config top to bottom. Multiple C: lines are supported — CCcam will try them in order if the first fails. There's no group matching to worry about; CCcam auto-negotiates which CAIDs the remote server carries.

Server-Side F: Lines If You Share Your Own Card

If you have a physical card in your receiver's slot and want to share it to other clients:

F: clientuser clientpassword 1 0

Format is F: username password uphops downhops. uphops = 1 means this client can reshare to one additional hop (set to 0 to prevent resharing). downhops = 0 is standard. CCcam auto-detects the physical card through the receiver's built-in reader — you don't define the card itself in the config, just the client accounts allowed to connect.

Note: running CCcam as a server requires the listening port (12000 by default) to be open in your box's firewall and forwarded if you're behind a NAT router.

Useful Global Options (WEBINFO, Port, Log)

SERVER LISTEN PORT: 12000
WEBINFO LISTEN PORT: 16001
CCCAM RESHARE: 0
DISABLE CACHE EX: yes
KEEPALIVE: yes

CCCAM RESHARE: 0 prevents connected clients from resharing your card further down the chain. DISABLE CACHE EX: yes turns off the ECM cache exchange protocol, which can cause issues with some upstream servers. KEEPALIVE: yes maintains the connection even when no channels are being decrypted.

CCcam does reload the config on some images if you just save the file, but a hard restart (/etc/init.d/cccam restart) is safer. The webif at port 16001 shows connected servers, hop counts, and which CAIDs each connection provides — read this before assuming the line is working.

Troubleshooting: Freezing, No Channels, and Connection Errors

Most Canal Digitaal cardsharing setup (CCcam/OScam configuration) problems fall into a handful of categories. Match your symptom to the cause below.

Line Connects but Channels Stay Black

This is almost always a CAID/ident mismatch. The line is connected and reports cards, but the specific CAID or provider ident your channels request isn't available on that line. Check /tmp/ecm.info or the OScam log for the CAID being requested, then check your line's reported card list in the OScam webif or CCcam info panel. If the CAID doesn't appear, the line simply doesn't carry it.

In OScam, also verify group numbers. If your reader is group 1 and your account is group 2, OScam won't route — the log will show ECM requests arriving but no reader being tried.

Another scenario: you have two emulators running simultaneously (say, CCcam and OScam both installed and both started). They fight over the DVB API and the CA device. Only one can win. Check ps aux | grep -E 'cccam|oscam' and kill whichever you're not using.

Channels Open Then Freeze Every Few Seconds

Freezing on an interval — typically every 8-10 seconds for SD, shorter for HD — means ECM responses are arriving too slowly. Control words (the actual decryption keys) change on a schedule, and if the new key doesn't arrive before the old one expires, you get a freeze until the next key comes.

Check the ECM response time in the OScam log. Anything consistently over 600ms is risky. Over 1000ms and you'll see regular freezes on SD; HD channels have a tighter window and start freezing at lower thresholds — around 400-500ms — because the ECM load is higher.

Causes: too many hops (each hop adds latency), overloaded upstream server, or a slow network path. The fix is a faster line — one with hop count 1 and sub-300ms ECM times.

Reader Shows Disconnected or 0 Cards

Work through this in order. First, verify the hostname resolves: nslookup your.server.host. Then verify the port is reachable: telnet your.server.host 12000 — if it times out or refuses, the problem is network, not config. Check whether your box firewall blocks outbound connections on that port (iptables -L -n). Some ISPs also block outbound connections on non-standard ports, though this is less common than it used to be.

If telnet connects, the problem is credentials or protocol. Double-check username, password, and port against your line details. For OScam, confirm cccversion matches what the server expects.

Wrong CAID / ECM Not Answered

You might have the right CAID but the wrong provider ident. Canal Digitaal's package structure means some channels sit under different provider IDs even within the same CAID. A line carrying the CAID might answer ECMs for the main package but not for sports or premium add-ons if those have different idents and the sharing card doesn't have that entitlement.

In OScam, you can add an ident filter to the reader to restrict which provider IDs it handles — but by default, leave this blank and let the upstream sort it out. If specific channels in a package work and others don't, this is the likely cause.

Time Sync and Firewall/Port Issues

This one gets skipped in most guides. Irdeto 2 ECM decryption is time-sensitive — the card checks system time as part of the decryption process. If your box clock has drifted more than a few minutes, decryption fails silently. Boxes without a real-time clock (RTC) are especially prone to this after a power loss.

Fix it: install and enable NTP synchronization. On Enigma2, ntpdate -u pool.ntp.org forces an immediate sync. Add it to your autostart if the box doesn't have an RTC. Also verify the timezone setting matches your actual location — a wrong timezone is functionally the same as clock drift from the card's perspective.

For outbound firewall issues: most Enigma2 boxes have minimal firewall rules by default, but if someone has hardened yours, check that outbound TCP on port 12000 (or whatever port your line uses) is allowed.

How to Choose a Reliable Sharing Line (Generic Criteria)

The Canal Digitaal cardsharing setup (CCcam/OScam configuration) is only as good as the line feeding it. You can have a perfect config and still get constant freezes from a low-quality line. Here's how to evaluate what you're connecting to — using data from your own tools, not seller marketing.

Local vs. Remote Card Indicators

In CCcam's webif and OScam's reader status, you can see the hop count reported by the remote server. A hop count of 1 means your connection is one step from the physical card — the best possible. Hop count 2 means there's an intermediate server. Higher than that and you're stacking latency with every additional hop.

For Canal Digitaal specifically, you want a line that reports the target CAID at hop 1. Lines that show the CAID at hop 3 or 4 will often work on SD but fail under load or on HD channels.

Hop Count and Server Load Signals

The OScam webif's Readers page shows current ECM response time per reader. Watch this over several minutes, not just at a single moment. A line averaging 180ms with occasional spikes to 400ms is fine. A line "averaging" 250ms because it swings between 80ms and 900ms is not — those spikes cause freezes.

CCcam's info panel shows active shares per card. A card serving hundreds of simultaneous clients will have high response times under load. This is invisible to you from outside, but consistently high response times (over 500ms) during prime time are a signal.

Uptime and ECM Response Time as Quality Metrics

OScam tracks reader uptime in the webif. A line that's been connected for 7 days straight is more reliable than one that shows 4 hours of uptime because it keeps dropping. You can also look at the "no answer" counter in the OScam reader stats — a reader that frequently returns no answer is either overloaded or missing the CAID for channels you're trying to watch.

Run a line for 24 hours before judging it. Many lines look great at 2pm and fall apart at 8pm when everyone is watching. The webif log timestamps let you correlate freeze events with ECM response time spikes, which tells you exactly when and why the degradation happens.