NTV card sharing: setting up CCcam and OScam in 2026

If you are reading this, you have already spent several hours trying to open NTV+ channels, and something went wrong. Black screen, decoding error, or the channel opens intermittently — classic. NTV card sharing is technically no more complicated than any other package, but it has its nuances with CAID and providers that are easy to miss. Let's break it down step by step.

What you need to know about NTV+ card sharing before setup

Before diving into the configs, it's worth understanding what you're actually working with. NTV+ is not a single monolithic package with one CAID, and this is what confuses most people.

Encoding of NTV+ and the CAID used

Historically, NTV+ uses the DRE Crypt conditional access system (CAID0x4AE1). On some transponders of the Yamal-402 satellite, Conax with CAID0x0B00 can be found. This is not theory — you need to open the info menu of the receiver on a specific channel and see what the system shows.

The problem is that most guides provide one CAID for everything. That's not how it works. SD and HD packages, plus interactive services, can be on different transponders with different encoding systems. Always check the CAID directly on the channel that is not opening.

Provider ID and frequency of key changes

The Provider ID for DRE Crypt at NTV+ is0x000000 on most transponders, but on some it can be different. ECM keys are updated frequently — the interval can be from a few minutes to several hours. This means that an unstable line with delays will cause constant freezes exactly at the moment of key change.

If the ECM time in OScam jumps above 800–1000 ms — that's already a problem. When the key changes, the receiver does not manage to receive the new ECM in time, and the picture breaks up for a second or two. It looks like a firmware glitch, although the reason is in the ping.

What equipment is suitable (Enigma2, Dreambox, OpenATV)

Enigma2 on any hardware — Dreambox 800, VU+ Solo, Formuler — everything works. OpenATV and OpenPLi equally support CCcam and OScam. The only difference is in the paths to the configs: OpenATV places configs in/var/etc/, while some OpenPLi builds place them in/etc/. This is important because an incorrect path means the daemon simply does not see the configuration file and starts with the default.

On Raspberry Pi with LibreELEC and Kodi through a plugin, it also works, but there is its own specificity with dvbapi. Android set-top boxes are a separate story; they require sofcam, and that's already a different configuration.

What is the difference between CCcam and OScam for NTV+

CCcam is simpler in initial setup: add a C-line, restart — it works. OScam is more complex but gives full control: you can see each ECM request, response time, and which reader responded. For debugging NTV+, this is critical.

Personally, I always install OScam even where CCcam would work fine — precisely because of the logs. When a channel does not open, the OScam log immediately shows: no match for CAID, the server rejected the request, or the reader responds in 1500 ms. CCcam does not provide such information.

Setting up CCcam for NTV+: config and ports

CCcam works with one main configuration file. All the logic is there.

Structure of the file /var/etc/CCcam.cfg

On Enigma2 with OpenATV, the path is/var/etc/CCcam.cfg. On some older builds, it can be/etc/CCcam.cfg. It's easy to check:find / -name CCcam.cfg 2>/dev/null.

The basic structure of the file looks like this:

# CCcam.cfg — example for NTV+

C-line: format host port username password

The connection string format is strict:C: host port login password. Spaces are separators, there should be no extra characters. The host can be an IP or a domain name. After editing the config, be sure to restart the daemon:/etc/init.d/CCcam restart or through the firmware menu.

A common mistake is invisible characters at the end of the line if the config was edited in a Windows editor. CRLF instead of LF breaks parsing. Edit via SSH or WinSCP with the correct encoding.

Parameters SID and CAID assignment

DirectiveCAID PRIORITY tells CCcam which encoding system to use first. For NTV+ with DRE Crypt, we specify4AE1. If the package is mixed and there is Conax, you can add priority:CAID PRIORITY: 4AE1 0B00.

Filtering by SID on the CCcam side is done throughF:-lines. If the server restricts the SID list, some channels simply will not open even with a working line — this is normal behavior, not a config bug.

Standard port 12000 and its change

Port 12000 is standard for CCcam sharing. There is no point in changing it unless required by the key provider. If behind NAT or a router — make sure the port is forwarded. For local OScam connecting to an external CCcam server, port forwarding on the client side is not needed.

Configuring OScam for NTV+: reader and dvbapi

OScam uses several configuration files. Each is responsible for its part.

The [reader] section in oscam.server for cccam protocol

File/etc/tuxbox/config/oscam.server describes the key sources. Example section for connecting to a CCcam server:

[reader]

Parameterident here is the CAID:ProviderID. If the provider id differs from000000 for your transponder, change it. You can find the exact value from the OScam log: at the first ECM request, it writes the full identifier.

File oscam.conf and web interface on port 8888

The main fileoscam.conf manages global settings. To enable web monitoring:

[global]

After this, openhttp://IP-receiver:8888 in the browser and see in real time: ECM-time for each channel, status of readers, number of requests. This is the best tool for diagnosing NTV card sharing settings — it immediately shows where the bottleneck is.

oscam.dvbapi and CAID/provider binding

Fileoscam.dvbapi specifies which encoding systems to process and in what order. For NTV+:

P: 4AE1:000000

LineP: sets the priority. If the channel uses both CAIDs, OScam will try the first one. Incorrect order — and the receiver will waste time querying the wrong reader. This is why there can be a situation: SD channels open, HD — do not (HD is on another transponder with a different CAID).

Logs in /var/log/oscam.log for diagnostics

The log is the main tool. View it in real time:tail -f /var/log/oscam.log. What to look for:

• ECM found (reader: ntv_reader) 234 ms — key received, response time 234 ms, all good
• no matching reader found — no reader matched by CAID or provider
• card not found — the server did not find a card for your request
• ECM timeout — the reader did not respond in time

Each of these lines indicates a specific problem.no matching reader — check CAID and ident in oscam.server.card not found — problem on the server side.ECM timeout — ping or overloaded line.

Solutions to typical NTV+ card sharing problems

Most problems fall into four scenarios. Let's analyze each.

Black screen with a working line

The line shows status connected in CCcam or OScam, but the screen is black. The first thing to check is — oscam.dvbapi. If the required CAID is not listed there or the provider id does not match, OScam simply will not make ECM requests for this channel.

The second option — the server filters by SID. Some NTV+ channels may be closed on a specific line. It's easy to check: open another channel from the same package. If one channel opens and another does not — this is SID filtering, not a configuration error on your part.

Another case: NTV+ changed CAID on the transponder, but the old one remained in the config. This can happen after technical work by the broadcaster. The solution is to open the info menu on the non-working channel and compare the current CAID with what is listed in oscam.server.

Long channel opening (high ECM-time)

Normal ECM-time for NTV card sharing with a good line is 150–400 ms. Anything above 800 ms already causes noticeable delays when switching channels. Above 1500 ms — periodic drops and freezes.

Causes: geographically distant server, overloaded reader (many clients on one card), poor internet channel. We check the ping to the server:ping host.example.com. If the ping is 200+ ms, the ECM-time will be at least 400–500 ms even under ideal conditions.

Error 'card not found' and CAID mismatch

This error in the log means that the server received an ECM request but did not find a suitable card. Either there is no card with that CAID on the server, or there is a mismatch in the provider id.

If you see a double CAID on the channel in the receiver (this happens with NTV+ when the transponder contains both DRE and Conax descriptors), the receiver may be selecting the wrong one. In oscam.dvbapi, put the required CAID first — it will be used for the ECM request. And checkident in oscam.server — there should be an exact provider id, not000000, if it differs.

Freezing and pixelation on HD channels

This is the error that is most often explained incorrectly. HD NTV+ in MPEG-4 requires a stable stream of 5–8 Mbps. If the internet connection is unstable or the provider is cutting UDP — the picture will pixelate regardless of how good the sharing line is.

It's easy to check: SD channels of the same package work fine, while HD freezes. This is almost always a problem of bandwidth or packet loss, not sharing. Runiperf3 or just check the speed while watching. If packet loss is more than 0.5% — HD will glitch.

How to choose a stable key source (criteria, without names)

I won't name specific providers here — this is not advertising. But the selection criteria are important because a bad line will ruin any perfect setup.

What to look at: line uptime and ECM-time

Uptime is the first. A line with 95% uptime means that once every 20 days you will lose the signal for several hours. For normal viewing, you need at least 99%. Good lines provide 99.5% and above. This can only be checked during the trial period — honest providers give 24–48 hours for free.

Check the ECM-time in the OScam web interface on port 8888 during the trial period. Look not at the average, but at the peaks. If during peak hours the ECM-time jumps to 2000 ms — the line is overloaded.

Local key server vs remote

A local server (when the physical card is connected to the receiver in your own network) gives an ECM-time of 10–50 ms. This is ideal. A remote server depends on the internet channel and geography. Other things being equal, choose a server in the same country or the nearest region.

If you have the option to choose between a server in Moscow and in Europe — take the Moscow one for NTV+. The difference in ping of 30 ms versus 80 ms may seem small, but combined with processing, it results in a difference of 200–400 ms in ECM-time.

Trial period and stability check

A minimum of 48 hours of trial period is needed to catch night drops and behavior during peak hours (Friday-Saturday evening). Test specifically NTV+ channels, not just public ones. Some lines handle simple CAIDs well and poorly handle DRE.

And check how many clients are on one card. A standard NTV+ card processes about 5–10 simultaneous ECM requests without degradation. If the provider sells 50 lines on one card — the ECM-time will be constantly high.

Legal aspects in the Russian Federation

NTV+ is a paid package with licensed content. Receiving channels without an official subscription through card sharing violates the broadcaster's terms and may be classified as a copyright infringement under Article 146 of the Criminal Code of the Russian Federation and the Civil Code of the Russian Federation on intellectual property. This article is purely informational and technical — using card sharing technologies to view paid content without a subscription is illegal.