Cardsharing NTV+ 2026: setting up CCcam and OScam

If you've already put together a receiver on Enigma2 or set up a server on Linux and figured out what card sharing is in principle — this text is for you. This isn't about general basics, but specifics: how to set up cardsharing NTV+ on CCcam or OScam, which caid and provid to enter, why channels might not open, and how to diagnose this from logs rather than guessing.

I've run both servers myself on different hardware — from an old DM800 to a regular mini-PC with Ubuntu — and below I've collected exactly what's actually useful when setting up cardsharing NTV+, without the fluff about "what satellite TV is."

What you need to know about cardsharing NTV+ before setup

NTV+ uses the Viaccess conditional access system. This is not CryptoWorks and not Irdeto, so configs downloaded "for another operator" won't fit here one-to-one — the syntax is similar, but the caid and provid logic differ fundamentally.

NTV+ encryption and caid (Viaccess, current values for 2026)

All caid values in the Viaccess family start with 0500. In practice, 0500 is most commonly seen for NTV+, but you shouldn't memorize the specific value from old forums — instead check it on your own receiver or in OScam directly, as a matter of fact. In OScam this is done via the web interface: the ECM info section will show the real caid of the current channel at the moment a key request is made.

On an Enigma2 receiver, the same caid can be seen in the channel information (usually pressing the "i" button twice, or the "Signal Finder" item with extended CA information). Look at exactly what the receiver shows right now — operators periodically change encryption parameters, and yesterday's data from someone else's config might simply be outdated.

Provid and NTV+ packages: how to determine your own

Provid is a further specification within caid, tied to a channel package. NTV+'s different packages (basic, HD, sports) may come with different provid values even within the same caid 0500. Hence a common scenario: some channels open, but the HD package doesn't, even though the caid seems to match.

Provid is determined the same way as caid — via the OScam ECM log (a line likecaid: 0500 provid: 000000will be replaced with the real values upon receiving the first request) or via the receiver's info panel. If your sharing provider gives several provid values at once, they can be entered comma-separated in the reader — this is normal practice for different NTV+ packages.

Eutelsat 36°E satellite and transponder frequencies

NTV+ broadcasts from Eutelsat 36°E (formerly Eutelsat 36B/36C). Transponder frequencies and symbol rates periodically change during the operator's technical work, so it makes no sense to hard-fix them in the article — the current list should be checked in a fresh satellite scan or in the tuner setup panel right before the first launch. If everything used to work, and at some point the sharing provides keys but there's no picture — first check not the server config, but whether the antenna and frequency settings on the receiver itself are up to date.

CCcam or OScam: what to choose for NTV+

CCcam is simpler in basic setup — one file, minimal directives, works "out of the box" on many receivers. This is convenient for a quick connection.

OScam is more flexible and, more importantly for Viaccess, gives much more detailed logs: you can see the exact ECM response time, hop, card status, reason for rejection. If you're setting up cardsharing NTV+ for the first time and want to understand what's actually happening with the signal, OScam will save you from guesswork. I usually recommend it specifically to those who plan to figure out problems on their own, rather than reinstalling the config with every error.

Setting up CCcam for NTV+: a working config

Basic CCcam setup revolves around two things: the connection line (C-line) and the file/etc/CCcam.cfg.

C-line: syntax and port

The standard format is:

C: host port login password

For example:C: 123.45.67.89 12000 user1 pass1. Port 12000 is a typical default value for the CCcam protocol, but it's configurable and may differ for a specific source — check against what the server sent you. The host, login, and password must be provided to you separately — an article about cardsharing NTV+ is not the place for someone else's working credentials; this is always individual data from your source.

File /etc/CCcam.cfg — key parameters

In the server or client config itself, the following directives matter at first:

• SERVER LISTEN PORT 12000 — the port on which the server accepts connections, if you're setting up a local share relay.
• ALLOW TIMEOUT 5000 — the timeout for waiting for a response from the card, in milliseconds.
• CACHE EXTENDED 1 — enables extended ECM/EMM caching, reduces load on repeated requests.
• DEBUG 8 — logging level; for diagnostics it's convenient to temporarily raise it to 9-10, for production mode 0-2 is enough.

After editing the file, CCcam needs to be restarted (usually via the plugin menu on Enigma2, or with the commandkillall -9 CCcam&& /usr/bin/CCcam on Linux builds, the path may differ).

Checking the connection and share status in the web interface

CCcam launches a built-in web status page, by default on port 16001 — it opens at the addresshttp://receiver_ip:16001. There you can see the list of active cards (shares), the hop value for each, and, importantly, the time of the last ECM request. If a card's line doesn't appear in the list at all, the problem is at the connection level (network, port, login/password), not signal reception.

Parameters for stable channel opening

For Viaccess, and accordingly for NTV+ cardsharing, a reasonable ECM timeout is around 3000-5000 ms. Too short a timeout on a not-so-fast link causes false picture dropouts even when the card on the other end is quite alive — the response just arrived a bit past the deadline.

Configuring OScam for NTV+: reader and ports

OScam is built more modularly than CCcam — the configuration is spread across several files, which seems more complicated at first, but greatly simplifies diagnostics later.

The [reader] section with protocol=cccam for NTV+

If the share source is broadcasting over the CCcam protocol (a common case), inoscam.server the reader looks something like this:

[reader]

protocol = cccam
device = 123.45.67.89,12000
user = user1
password = pass1
caid = 0500
ident = 0500:000000
group = 1
cccversion = 2.3.0
inactivitytimeout = 30

The valuecaid andident should be entered based on your actual signal (see the section above on how to determine them), not copied from old guides — this exact mistake is what most often breaks reception after the operator changes encoding parameters.

oscam.server, oscam.user, oscam.conf: what to edit where

On classic Linux builds, the configs are located in/etc/oscam/ or/etc/tuxbox/config/oscam/ depending on the distribution, on Enigma2 images — more often in/etc/tuxbox/config/ or/var/tuxbox/config/oscam/. The three files do different things:

• oscam.server — card/share sources (readers), including your reader for NTV+.
• oscam.user — accounts of clients that connect to your server (if you share access with someone yourself).
• oscam.conf — general settings: logging, web interface ports, default timeouts.

caid/ident and groups for ECM routing

Group in OScam is a convenient mechanism if you have several readers: you can assign a specific group to NTV+, so that ECM requests from those channels go strictly through the needed source instead of iterating through all of them. For NTV+ cardsharing with several provids within a single operator this is especially useful — you specify the same group in the client's user config, and routing becomes predictable.

OScam web interface (port 8888) and ECM monitoring

By default, the OScam web interface listens on port 8888 (set by the directivehttpport = 8888inoscam.conf), opened viahttp://ip:8888. In the ECM section you can see the most important things: response time for each channel, reader status (CONNECTED / card not responding), decode count versus found. If found is growing but decode isn't — the signal is arriving, but the key isn't being picked up, which is almost always a caid/provid issue, not a network one.

Diagnosing NTV+ reception errors via cardsharing

Most NTV+ cardsharing problems can be solved from the logs in five minutes if you know where to look. Below is the order in which I check this myself.

Channels won't open: checking ECM time and hop

First I look at ECM time in the OScam log or in the CCcam web status. If the response time is consistently above 500 ms — that's already borderline, the picture may open with a 2-3 second delay after switching channels, which is often mistaken for "not working at all." I also check hop: a value of 1 means a direct connection to a local card, 2 and above means the share is going through an intermediary, and each extra hop adds delay and a point of failure.

Periodic freezes and image "blocking/pixelation"

Freezes are almost always related to link instability, not the card itself. I check the ping to the share server: if it jumps between 40 and 300 ms — that's already a cause for the picture falling apart, especially on channels with frequent key changes. A stable low ping with rare packet loss is what you should aim for, but it can't be guaranteed on a rented server or through an intermediary.

"No access" error / caid mismatch

This is the most common story specifically with NTV+. Causes in decreasing order of likelihood: incorrect or outdated provid in the reader, the source is providing a different NTV+ package than the one you have access to, or the operator changed the keys and the local card (if the share comes from a real card) hasn't yet received the rights update via EMM. In the latter case, ECM formally responds, but decoding fails — the picture in the log will look like a provid problem, though the cause is completely different.

Checking the network, ports, and firewall

If the reader isn't connecting at all (status not CONNECTED), I simply check port availability:

ping server_host
telnet server_host 12000

If telnet doesn't connect — the port is closed either on the server side or in your firewall. On a Linux server that distributes the share itself, check the rules:

sudo ufw allow 12000/tcp
sudo iptables -L -n | grep 12000

A separate headache is a receiver or server behind NAT/CGNAT. If you're distributing the card further yourself and are behind the provider's CGNAT, port forwarding via the router simply won't work, because you physically don't have a "white" IP — here you can't do without a VPN or a tunnel to an external server. If you're only a client connecting to someone else's server — NAT on your side usually doesn't get in the way, incoming forwarding isn't needed, an outgoing connection is enough.

How to choose an NTV+ share source (criteria, not names)

I won't name any specific services here — the cardsharing market is unstable, today's reliable source may disappear tomorrow, so it's more important to understand how to evaluate quality yourself than to follow someone else's recommendation.

What to look at: local card, hop 1, stable uptime

A source with a real local card and hop 1 is almost always more stable than a long chain of intermediaries. Ask directly where the signal comes from, and don't hesitate to check the hop in your own log after connecting — if it's higher than 2, factor in the risk of additional dropouts.

Ping to the server and ECM response time as a quality metric

These are the only objective figures that don't depend on someone else's promises. Measure the ping at different times of day, check the ECM time over an hour or two of operation in the OScam log. If both indicators are stable — the source is working properly. If the ping jumps around and the ECM time occasionally spikes past a second — sooner or later this will result in freezes while watching.

Signs of an unstable source

Be wary of: constantly changing host and port without explanation, no clear answer about the hop, frequent "technical work" without warning, only part of the НТВ+ package channels working while full access was promised. Any of this is worth checking with logs rather than taking on faith — luckily both CCcam and OScam provide enough data for this.