How to connect card sharing: CCcam and OScam in 2026

If you have already received the data from the provider — host, port, username, and password — and are now looking at the receiver screen with a confused expression, this article is for you. Connecting card sharing is technically not difficult, but small errors in the config can waste hours of time. Let's break it down step by step: from hardware requirements to diagnosing freezes through ECM time.

What is needed to connect card sharing

Before diving into the configs, make sure you have everything necessary. Skipping this step means you'll be guessing later why nothing works.

Compatible receiver or set-top box on Enigma2/Linux

You can fully connect card sharing via CCcam or OScam only on receivers with Linux firmware — Enigma2. These include Dreambox (DM900, DM7080), Vu+ (Duo4K, Zero4K), Zgemma (H9S, H7), GigaBlue, Mut@nt, and their analogs. Softcam emulators work on them as full-fledged plugins.

Classic receivers without Linux — like Openbox, Skybox, GBox-compatible — also support sharing, but through built-in clients. They do not have a full OScam, but there is GBox or a built-in CCcam client with limited settings. The config is simpler there, but debugging is a pain.

Firmware with emulator support (softcam)

On Enigma2, you need firmware with a softcam panel — OpenATV, OpenPLi, OpenVIX, or EGAMI. All of them support the installation of CCcam and OScam through the built-in plugin manager or manually via FTP. OpenATV and OpenPLi are the most common, with the most ready-made ipk packages available for them.

Access data: host, port, username, password

For the CCcam protocol, you need exactly four parameters: server address (hostname or IP), port (usually in the range of 12000–30000), username, and password. All of this is provided by the provider upon registration. Without this data, you cannot proceed further.

If the provider gives newcamd instead of CCcam — a DES key (14 bytes hex) is also needed. More on this below in the section about OScam.

Stable internet from 2 Mbps and low ping

Channel speed is not the main thing. Card sharing consumes a laughable amount of traffic, literally kilobytes per second. Ping is important. If the ping to the server is more than 150 ms — freezes are practically guaranteed, especially on channels with fast key changes (fast ECM). The norm is up to 100 ms, the ideal is up to 50 ms.

Check the ping directly from the receiver via telnet:ping -c 10 your.server.host. If you see packet loss or jitter above 30 ms — the problem is in the network, not in the config.

CCcam setup: CCcam.cfg file

CCcam is the most widely used sharing protocol. The setup is simple, one file, one syntax. But there are plenty of nuances.

Installing the CCcam plugin via the softcam panel

On OpenATV: Menu → Plugins → Software Manager → find CCcam in the softcam list → install. The path is similar on OpenPLi. After installation, CCcam will appear in the Softcam Panel (usually accessed via the blue button on the remote in the main menu).

If the package is not in the repository — download the ipk manually and install it viaopkg install CCcam_*.ipk in telnet. CCcam version 2.3.0 and above works stably; 2.1.x is already outdated, better not to use it.

File location: /etc/CCcam.cfg or /var/etc/CCcam.cfg

The main path —/etc/CCcam.cfg. On some firmware (especially older OpenPLi 7.x builds and some images for Zgemma), the config is located in/var/etc/CCcam.cfg. Check both paths via FTP or telnet with the commandfind / -name CCcam.cfg 2>/dev/null.

Sometimes the file is write-protected — especially if the firmware is uploaded to a read-only partition. In this case, mount the partition as writable:mount -o remount,rw /, edit it, and restart.

C-line string: C: host port username password

Here is a working example of a C-line:

C: my.server.com 12000 myusername mypassword

The syntax is strict:C: with a capital letter, space, host, space, port, space, login, space, password. No quotes, no extra characters. The line must end with a newline — if you edit in Windows and save in CRLF, CCcam may not recognize the line. Use Notepad++ with Unix line endings or edit directly via telnet throughnano.

You can add multiple C-lines for backup servers — CCcam automatically switches when the main one is unavailable.

F-line and G-line parameters for sharing

F-line is needed if you are sharing lines with other clients:

F: localuser localpassword 1 0 0 0 { 0000:000000 }

G-line is for limiting which packages you receive or share. Block{ 0000:000000 } at the end of the F-line means "no restrictions". If you want to block a specific package (for example, to not forward a certain CAID) — specify it:{ 0500:000000 } will block Viaccess.

If you are only a client, not a reseller — you do not need an F-line at all.

Restarting the service and checking the status

Via telnet:/etc/init.d/softcam stop&& /etc/init.d/softcam start. Or shorter:init 4&& init 3 (restarts all softcam processes).

Via the remote — blue button → Softcam Panel → select CCcam → Restart.

Checking the status via the web interface: open a browser, enterhttp://IP_receiver:16001. You will see a list of connected C-lines, the status of each reader, ECM requests in real time. If the line is green — connected, gray — no connection.

Configuring OScam: dvbapi, server and reader

OScam is more complex than CCcam in initial setup, but more flexible in everything else. It supports CCcam, newcamd, mgcamd, camd35, radegast — simultaneously. For a receiver with two tuners, where different CAIDs need to be decoded simultaneously, OScam is the only option.

Configs in /etc/tuxbox/config/ or /var/etc/oscam/

OScam reads multiple configuration files from one directory. On most Enigma2 firmware, this is/var/etc/oscam/. On older Dreambox with Tuxbox —/etc/tuxbox/config/. Files:oscam.conf,oscam.server,oscam.user,oscam.dvbapi.

oscam.conf — sections [global], [dvbapi], [webif]

Minimum workingoscam.conf:

[global]

Parameterau = 1 in the dvbapi section enables automatic key updates — without it, channels with periodic key changes will periodically freeze. The fielduser in dvbapi must match the username inoscam.user.

oscam.server — configuration [reader] with cccam protocol

Example reader with CCcam protocol:

[reader]

If the provider only distributes newcamd — change the protocol and add the key:

[reader]

DES keykey — 14 bytes in hex, provided by the provider along with the other data. Without it, newcamd will not connect.

oscam.user — local users

User for dvbapi (decoding on the receiver itself):

[account]

The name must match what is specified inoscam.conf in the section[dvbapi]. The password for the local dvbapi user is technically not checked, but the field must be filled.

OScam web interface on port 8888

Openhttp://IP_receiver:8888 in the browser. The Readers tab — you see all readers and their status: green icon — connected and card found, yellow — connecting or no response to ECM, red — connection error or incorrect data.

The Status tab → EMM/ECM shows live requests in real time. If you see lines with response times of 200–400 ms — everything is fine. Above 800 ms — the server is overloaded or network delays are critical.

Important: do not run CCcam and OScam simultaneously. Both try to capture /dev/dvb/adapter0/demux0 via the dvbapi socket, conflict, and neither works properly. One emulator — one device.

Checking operation and troubleshooting freezes

Freezes are the most common complaint after successfully connecting card sharing. Channels open, but the image freezes every 10–30 seconds. This can be fixed by diagnosing the logs.

Reading the OScam/CCcam log for diagnostics

OScam writes the log to/var/log/oscam.log (if specified inoscam.conf). To view in real time:tail -f /var/log/oscam.log via telnet.

CCcam — log in/tmp/CCcam.log or through the web interface on 16001. In telnet:tail -f /tmp/CCcam.log.

Checking ECM time (normal up to 400-600 ms)

ECM time — the time from the key request to receiving a response. This is the main indicator of the quality of the connection to the server. The norm is up to 400–600 ms. At 600–900 ms, rare freezes begin. At 1000 ms and above — constant freezes, making it impossible to watch.

In the OScam web interface, the value is visible in the ECM Time column on the Status tab. In the log, it looks like this:

2026/04/15 21:33:11 myshare_cccam (cccam) found (0500/000000/1234) 287ms

287 ms — excellent. If you see 1200 ms and above — the server is overloaded or too far geographically.

Analyzing error codes: 'card not found', 'no matching reader'

card not found — the reader connected, but the required CAID was not found on the server. Either the provider does not have this package, or the filter inoscam.dvbapi is incorrectly configured.

no matching reader — OScam did not find any reader in the required group. Check that the groups inoscam.server andoscam.user match (both must havegroup = 1 or another identical value).

Connection refused / timeout — the server is not responding. Either the host/port is incorrect, or the outgoing port is blocked by your provider or router. Check from another device (smartphone via mobile internet): if the check passes from mobile but not from home — double NAT or provider firewall.

Solution to the problem of constant freezes on HD channels

HD channels with fast ECM (especially some European packages) update keys every 5–10 seconds. With ECM time above 500 ms, the receiver does not manage to get a new key before the next change — hence the freezes specifically on HD, while SD works fine.

Solutions: first, create a file/var/etc/oscam/oscam.dvbapi and explicitly specify the CAID priority for problematic channels:

P: 0500:000000

Secondly, check the parameterpreferlocalcards = 1 inoscam.conf — it makes OScam ask for local cards first, if available, and only then go to network readers. This parameter is not needed for a purely client scheme without physical cards.

If you have a receiver with two tuners and you are recording one channel while watching another with a different CAID — make sure that inoscam.user the dvbapi user hasmax_connections = 2, otherwise OScam will only process one stream.

How to choose a cardsharing server: criteria

Technically, connecting cardsharing is not difficult if the data is working. The problem often lies in the quality of the server itself. Here’s what to look for when choosing.

Server uptime and claimed uptime

A normal server maintains an uptime of 99% or higher. If they claim "99.9% uptime" — ask for a monitoring screenshot or check it yourself through a third-party ping monitor. Some providers display pretty numbers on their website, while the server crashes every weekend.

Pay attention to the incident history: is there a status page, how quickly they respond to outages. A response in 6 hours during prime time is a bad sign.

Supported protocols and number of locals

A good server supports at least two protocols — CCcam and newcamd. This means you can switch without changing providers if one protocol suddenly gets blocked. A server that only distributes through one protocol immediately limits your configuration options.

Locals (local cards) — real cards inserted into the card reader on the server side. The more locals and the more diverse the packages — the more stable the operation. Ask directly: "how many locals do you have for CAID 0500?" An adequate provider will answer specifically.

Trial period before payment

Without a test — do not pay. 24–48 hours of trial access is enough to check the real ECM time, stability during prime time (evening from 20:00 to 23:00), and the operation of the specific channels you need. If the provider refuses a test — that’s a red flag.

During the test, specifically watch HD channels during prime time. That’s when the server is under maximum load and the ECM time increases.

Response speed and server geography

The closer the data center is to your location — the lower the ping. If you are in Eastern Europe and the server is in the Netherlands — 30–50 ms is normal. If the server is on another continent — 150+ ms, and freezes on fast ECM are almost inevitable.

Ping is checked directly from the receiver via telnet before paying for the subscription. Some providers give test data from another, faster server, and after payment switch to another — check the ping on the production host, not the test one.

Signs of a questionable offer: price 3–5 times lower than the market with the same claimed packages, lack of trial access, a single protocol, support only through a form on the website without the possibility to write directly.