Cardsharing Rainbow TV: setting up CCcam and OScam

If you already have the connection data in hand and the receiver is ready to work — most of the journey is behind. But it is at the stage of entering the config that most get stuck. Cardsharing Rainbow TV operates on a clear scheme, and when you know what exactly to check, the black screen ceases to be a mystery. In this article — real paths to configs, live examples of syntax, and diagnostics through logs.

How cardsharing works for Rainbow TV

The essence is as follows: your receiver does not hold a physical card. Instead, it sends an ECM request (Entitlement Control Message) to a remote server, where the card is actually located. The server returns a control word (Control Word, CW), which the receiver uses to decrypt the video stream. All this happens every 10 seconds — that’s how long one CW lives.

The delay between the request and the response directly affects the quality of the picture. If the CW arrives late, the receiver does not have time to decrypt the next block of data — we get a freeze or a pixelated image at the moment of key change.

Principle of ECM/EMM exchange

The ECM request contains encrypted data specific to a particular channel and time interval. The server decrypts it with the card, extracts the CW, and sends it back. EMM (Entitlement Management Message) is an update of access rights on the card itself, which has no relation to the client receiver.

The fewer "hops" between your receiver and the server with the local card — the lower the ECM time. Resharing through a chain of servers adds delay at each link. This is not theory — it is what you will see in the OScam logs.

What encoding system is used

Rainbow TV uses encodingViaccess 3.0. CAID for it is —0x500. Ident (provider identifier) depends on the specific package, most often values in the range are encountered040000–04002A. Important: if an incorrect ident is specified in the config, the server simply will not respond to ECM requests from your receiver, and the channels will not open — even with a working account.

The HD package may have a separate SID list and a different ident. That’s why SD channels open, but HD ones do not. This is not a server problem, it is filtering by CAID/SID.

Satellite, frequencies, and reception transponders

Rainbow TV broadcasts from the satelliteIntelsat 15, orbital position85.2°E. Main transponders:

Frequency (MHz)	Polarization	SR (symbols/s)	FEC
11054	H (horizontal)	43200	5/6
11096	H	43200	5/6
11554	V (vertical)	43200	5/6
11595	V	43200	5/6

Before dealing with the card sharing config, make sure that the receiver can see the transponder at all. A signal level below 60% and quality below 70% on the receiver screen indicate a problem with the antenna, not with the server.

CCcam setup for receiving Raduga TV

CCcam is a simple and understandable protocol. The config file is read line by line, with a minimalist syntax. For most users who are setting up Raduga TV card sharing for the first time, this is a good start.

Structure of the CCcam.cfg file

The file consists of directives, each on its own line. Empty lines and lines with# at the beginning are comments. A minimally working config looks like this:

# CCcam.cfg — client configuration

ParameterRELOAD WHEN CHANGE allows changes to be applied without restarting the daemon — convenient for debugging.DEBUG = 1 should only be enabled temporarily: the log grows quickly.

C: line and mandatory parameters

The connection line to the server has the format:

C: hostname port username password [no/yes] [{ caid:ident:sid }]

Where:

• hostname — domain name or IP of the server
• port — port provided by the server owner (there is no standard, usually 10000–15000)
• username /password — your credentials
• no/yes — disable/enable CCcam connection encryption
• block{ 0500:040000:0 } — optional filter by CAID:ident:SID

The filtering block is useful if there are several packages with different CAIDs on one server. For Raduga TV with Viaccess, the example looks like this:

C: share.example-server.net 12000 user1 pass1 no { 0500:040000:0 }

Zero in SID means "all channels of this provider." If a specific one is needed, substitute its SID in decimal or hexadecimal format.

Path to the config and restart of the daemon

On Enigma2 (Dreambox, VU+, Formuler with OpenATV/OpenPLi), the config is located at:

/var/etc/CCcam.cfg

On some firmware (especially older images for STB), the path is different:

/usr/keys/CCcam.cfg

After updating the firmware, the daemon may not start precisely because the path has changed — the new firmware looks for the config in/var/etc/, while it remained in/usr/keys/. Check this first.

Restart via command line:

killall -9 CCcam&

Or via init.d, if there is a script in the firmware:

/etc/init.d/softcam restart

Configuring OScam for Raduga TV

OScam is more complex in initial setup but provides incomparably more information about what is happening. The web interface, detailed ECM time logs, filtering by CAID/ident — all this makes OScam the preferred choice when you need to troubleshoot rather than just "it works, and that's fine."

Config oscam.server and protocol cccam

Fileoscam.server describes readers — connections to servers. The section for connecting via the CCcam protocol:

[reader]

Parametercaid = 0500 restricts the reader to only Viaccess requests. Without this, OScam will send ECM for any CAID through this reader — unnecessary load and confusion in the logs.

File oscam.user and profile binding

If OScam works as a server (for example, distributing CW to a local receiver via newcamd or camd35), the fileoscam.user:

[account]

Parameterau indicates which reader to use for updating rights (EMM). In a client scenario, when OScam only proxies requests to an external server, this file can be minimal.

Reader, group, and cccmaxhops

cccmaxhops = 2 — the maximum number of "hops" from the card source to your receiver. A value of 1 means only local cards on the server, 2 allows for one resharing. There is no point in setting it higher than 3: the delay increases, and the quality of resharing degrades.

cccwantemu = 0 — disable the reception of software emulators via CCcam. For legitimate servers with real cards, this is unnecessary.

Paths to OScam configs depend on the firmware. Enigma2:

/etc/tuxbox/config/oscam/

Another common option:

/var/keys/oscam/

The OScam web interface by default runs on port8888. You can access it directly from a laptop on the same network:http://192.168.1.xx:8888. There you can see the status of each reader, ECM time in real-time, and the latest requests.

Diagnostics and troubleshooting reception errors

This is where most guides end with "check the config." But the config is the last thing to check if the logs are being read correctly.

Black screen and encoding error

First, we look atoscam.log. If there are lines like:

ECM handler for CAID 0500 not found

— it means the reader with the required CAID did not start or is not bound to the required group. We check the parametersgroupinoscam.serverandoscam.user— they must match.

The line:

no matching reader found for ECM

indicates that the ident in the request from the receiver does not match what is specified in the reader. Or it is not specified at all — then remove theidentparameter fromoscam.serverand check if decoded ECMs appear.

Black screen only on HD channels while SD channels work — a typical situation with different SIDs or CAIDs for the HD package. We look in the log to see which CAID is requested for the HD channel and compare it with what the server has.

Stuttering and freezes with high ping

Freezes strictly at the moment of CW change (every ~10 seconds, at regular intervals) — this is server delay, not signal. ECM time is normal — up to 300–400 ms. Values of 700+ ms cause noticeable stuttering. Above 1000 ms — the picture will regularly break up.

In the OScam web interface (port 8888, "Readers" section), ECM time is visible in real-time. If the values jump from 200 to 900 ms — the server is overloaded. This often happens during prime time: in the evening from 20:00 to 23:00, the load on popular servers increases by 3–5 times, and a seemingly reliable server starts to "lag."

Consistently high ping with normal ECM time — it's already your internet channel. We check with a command directly from the receiver (if SSH is available):

ping -c 10 share.example-server.net

Checking the connection to the server via logs

The port may be blocked by the internet provider or the router's firewall — especially non-standard ports above 10000. Check availability:

telnet share.example-server.net 12000

If the connection hangs or is immediately dropped — the problem is network-related, not in the config. In this case, we check the NAT/firewall rules on the router and, if the provider blocks ports — we try through VPN or ask the server owner to provide a port from another range.

In the OScam log, a successful reader connection looks like this:

[reader] raduga_main: connecting to share.example-server.net:12000

If instead you see —Connection refused orConnection timed out — check the network, not the config.

Criteria for choosing a reliable card sharing server

A technically correct config is half the battle. The other half is a server that won't let you down. Let's discuss what to look for when choosing, without naming specific resources.

Stability and ECM response time

The key parameter is ECM time and its stability. It's not enough to know the average value: the spread is important. A server with an ECM time of 150 ms at 9 AM and 800 ms in the evening is a bad server, even if the average looks good. A good provider publishes availability and load graphs — this is a sign that they have something to show.

The difference between "local card" and "reseller/reshare" is fundamental. A local card on the server gives an ECM time of 50–150 ms. Reshare through two or three hops gives 400–800 ms. When choosing a card sharing server, Raduga TV, clarify whether they have a real local card.

Support for the required encoding and uptime

Make sure the server explicitly states support for Viaccess 3.0 and the Raduga TV package with Intelsat 15 (85.2°E). Not "all satellites," not "everything available" — a specific satellite and CAID 0500.

Claimed uptime of 99%+ without supporting statistics is marketing. Real uptime can only be verified through a trial period or by user reviews with a long history of use.

Trial period and technical support

A normal server provides trial access for 24–48 hours without payment. During this time, you can capture real ECM time values at different times of the day — morning, afternoon, evening prime time. If there is no trial period at all — this is a reason to be cautious.

The response speed of technical support is checked simply: ask a question before payment. If they respond within an hour — good. If they only respond after payment — a signal about priorities.

And finally: a server that works fine with 100 users may crash with 500. Resold lines are the most common cause of evening freezes. If complaints about overload during prime time are regularly found in reviews — this is a systemic problem, not a one-time failure.