NTV card sharing: CCcam/OScam setup 2026

If you are engaged in NTV card sharing, it means you have already figured out the basics and are now stuck on specifics: what line to write in the config, why channels are not opening, what an error in the logs means. This material is specifically about that. No introductory theory for beginners — only syntax, file paths, diagnostics, and real reasons for freezes.

What is NTV card sharing and how does it technically work

The principle is simple, but it is often misunderstood. You receive the video stream directly from the satellite — the card sharing server has nothing to do with it. Only so-called Control Words (DCW keys) are transmitted over the network, which are needed for descrambling the already received signal on your receiver.

The receiver sends an ECM request to the server, the server proxies it to the physical smart card, the card returns the key, and the receiver decrypts the picture. This entire cycle must fit within 300–500 ms — otherwise, freezes begin, because the keys change approximately every 10 seconds.

Below is a table of technical parameters that you need to know for setup. Confusion between CAID and client protocol is one of the most common reasons why the line is Active, but channels do not open.

Parameter	Value	Note
CAID	0x0500 (Viaccess)	Conditional access system of the NTV+ package
Provider ID	032830, 032831	Depends on the specific satellite and transponder
Client protocol	CCcam / newcamd	Do not confuse with CAID — this is the transport layer
Standard CCcam port	12000	May be changed by the server
Standard newcamd port	15050	Used less frequently, but supported by OScam

CCcam (port 12000) and newcamd protocols for receiving NTV

CCcam is a proprietary protocol that operates on port 12000 by default. Newcamd is older, uses port 15050, and has a slightly different authentication scheme (with a DES key). For NTV card sharing, CCcam currently dominates, but OScam as a client can speak both languages simultaneously — this is convenient if the server supports only one of the protocols.

An important point: CAID is the identifier of the encryption system (Viaccess = 0x0500), not the connection protocol. You can use the CCcam protocol to connect to a server that holds a Viaccess card. These are different levels of the stack, and they should not be mixed up in your mind.

The role of ECM/EMM and descrambling on the receiver side

ECM (Entitlement Control Message) is encrypted packets within the transponder that contain encrypted keys. The smart card on the server decrypts them and returns the Control Word. EMM (Entitlement Management Message) is subscription rights updates that go directly to the card and have nothing to do with the client.

Descrambling occurs on your receiver — in the CAM module or built-in descrambler. The server only responds to ECM requests; everything else is done by your hardware locally.

What is transmitted over the network: DCW keys, not the stream itself

DCW is 16 bytes of data. This is how much is transmitted from the server to the receiver for each request. A channel with a bitrate of 8 Mbps goes past the card sharing server altogether. Therefore, the speed of the internet connection does not affect the quality of the picture — only the latency to the server matters, not the bandwidth.

CCcam setup for NTV: step-by-step configuration

Here it is as specific as possible. The format of the C line in CCcam.cfg looks like this:

C: hostname.example.com 12000 username password no { 0:0:2 }

In order:C: — type of line (client).hostname.example.com — server address.12000 — port (may be different, check with the provider).username andpassword — your credentials.no — disable encryption (yes if the server requires it).{ 0:0:2 } — maximum number of hops (0 — do not forward the card further on the network; 2 — allow two levels of forwarding).

C line structure: hostname port username password in CCcam.cfg

The line must be without line breaks, one per line, without extra spaces at the end. Most "not connecting" issues are typos in the hostname or a space after the password. Check in a hex editor if you copy from a browser: some sites insert non-breaking spaces (0xA0).

If you have multiple lines — write each on a new line. CCcam processes them in order upon failure. But do not abuse it: 10 dead lines will slow down response time.

Path to the configuration file (/etc/CCcam.cfg or /var/etc/CCcam.cfg)

Depends on the firmware. Here’s where to look:

• OpenATV, OpenPLi, OpenVIX —/etc/CCcam.cfg
• Gemini, Newnigma2 —/usr/keys/CCcam.cfg
• DreamElite and some DM builds —/var/etc/CCcam.cfg

If unsure — check via FTP or SSH with the commandfind / -name "CCcam.cfg" 2>/dev/null. The file may not exist — then create it in the necessary location and write the lines.

Hops (hops) and CAID priority parameters

Hops are the depth of sharing. The value{ 0:0:2 } means: 0 local cards do not share, 0 — also none, 2 — maximum depth of forwarding for incoming cards. For client configuration of NTV card sharing, usually enough is{ 0:0:2 } or even{ 0:0:1 }.

CAID priority is configured in the filepriority.cfg or through the directivePRIORITY CAID in CCcam.cfg. If you have multiple sources for one CAID — CCcam chooses based on priority. If channels do not open with an active line — this is the first place for diagnostics.

Restarting the daemon and checking in CCcam Info

Through SSH/telnet:/etc/init.d/CCcam restart orkillall -9 CCcam&& CCcam&. Through the web interface Enigma2 — section Plugins → CCcam, button Restart. After restarting, allow 15–20 seconds for the connection to establish.

In the CCcam Info section on the receiver, check the Status column.Active — connection exists, card available.Offline — server unavailable.Idle — connection exists, but there were no requests. If the status is Active, but channels are not working — the problem lies in CAID or provider ID, not in the connection.

Configuring OScam for NTV: reader and server parts

OScam is more complex than CCcam in configuration, but provides much more control and information. The configuration is split into several files, which can be confusing at first.

Main OScam files:

• /etc/oscam/oscam.conf — global settings of the daemon
• /etc/oscam/oscam.server — description of readers (card sources)
• /etc/oscam/oscam.user — users and their rights

On some firmware, the path is different:/etc/tuxbox/config/ or/usr/keys/. Checked with the commandfind / -name "oscam.conf" 2>/dev/null.

Section [reader] in oscam.server: protocol cccam, device, key

The reader block for connecting to the CCcam server looks like this:

[reader]

Parametercaid = 0500 — filter: the reader will be used only for Viaccess requests. If not specified, OScam will process all requests through it, which may slow down performance.group = 1 links the reader with users from oscam.user who are assigned to the same group.

cccversion — the version of the CCcam protocol that OScam emulates. The value 2.0.11 is suitable for most servers. If the server does not accept it, try 2.1.4 or 2.3.0.

Configuration of oscam.conf and web interface on port 8888

Minimum configuration of oscam.conf for running with a web interface:

[global]

After starting OScam, the web interface is available athttp://IP_receiver:8888. It shows everything: status of readers, ECM time, failure counter, active sessions. This is the main diagnostic tool.

File oscam.user and access groups

oscam.user is needed if OScam also works as a server for other clients in the local network. If you are only a client, the file can be empty or contain one entry for local use:

[account]

Parameterau = 1 enables Auto-Update — transmission of EMM to the card. If there is no card (pure client scheme) — set it to 0.

Checking the status of the reader in WebIF (ECM time, status OK)

In WebIF OScam, the Readers section shows the status of each reader. A green icon means the reader is connected and working. Yellow means it is trying to reconnect. Red means an error.

ColumnECM time — the average response time for the last requests. Norm: up to 300 ms is excellent, 300–500 ms is good, 500–800 ms is tolerable, above 1000 ms — there will be freezes. ColumnRejected — the number of rejected requests. If it is increasing, the server is overloaded or the CAID does not match.

Troubleshooting: why NTV does not open

A black screen with a working line is a common situation. There are several reasons, and they are not always obvious.

Error 'no card' and CAID/provider mismatch

Errorno card in the OScam logs means that no reader was able to respond to the ECM request for the given CAID and provider ID. First, check the CAID and provider ID in the config against the actual parameters of the transponder.

You can view the channel parameters directly on the receiver: Info → Technical Info or the equivalent in your menu. Provider ID for NTV+ is 032830 or 032831 depending on the transponder. If the wrong provider is specified in the config, add a filter in the reader section:services = ntv_package and describe the package in oscam.services.

Long ECM time and freezes (freeze) of the picture

ECM time above 800–1000 ms gives a characteristic picture: normal video, then a second freeze, normal again, freeze again. This is not a signal problem from the satellite — the keys arrive later than needed for descrambling.

Causes of high ECM time: server overload (the card is shared among too many clients), high ping to the server, a bottleneck in the network between you and the server. Check the ping:ping -c 10 hostname.example.com. Above 150–200 ms is already risky.

Problem with key update frequency and sat/freeze

Some channels change keys more often than usual — especially during active anti-piracy campaigns. If the ECM time is normal, but there are freezes only on some channels — the problem may be exactly this. The OScam logs will show frequent ECM requests for a specific CAID/SID.

A special case: if the server works fine during the day, but freezes in the evening from 19:00 to 23:00 — a classic sign of reselling one card to too many clients. During prime time, the queue of ECM requests increases, and the response time grows. This can be diagnosed easily: check the ECM time in WebIF specifically during evening hours.

Network check: ping, open port, firewall

Check server availability:telnet hostname.example.com 12000. If the connection is established — the port is open. If "Connection refused" — the port is closed on the server or on your router.

Double NAT (CGNAT from the provider) does not interfere with outgoing connections — problems arise only if you want to receive incoming connections. For the client role in card sharing, CGNAT is not critical. But if your provider uses CGNAT and you want to run an OScam server yourself — port forwarding will not work without a VPN or tunnel.

A receiver with multiple tuners sometimes conflicts: the local card in CAM and the network reader try to respond to one ECM. In OScam, this is resolved with the parameterlb_mode (load balancing mode) in oscam.conf — setlb_mode = 1 to select the fastest reader.

How to choose a reliable card sharing source: criteria

There will be no specific service names here — not because there are none, but because the market changes quickly, and bad advice here costs money and nerves. However, there are objective technical criteria by which you can evaluate any provider independently.

Stability of uptime and ECM response time

A normal provider gives a test line for 24–48 hours. During this time, be sure to check the ECM time at different times of the day — in the morning, during the day, and in the evening prime time. If the variation is large (200 ms in the morning, 1500 ms in the evening) — the card is overloaded with clients.

A good benchmark: ECM time is stable up to 400–500 ms during peak hours. A provider that does not offer a test line — is an immediate signal. It is not worth paying in advance for a cat in a bag.

Support for the required CAID and local package

Directly ask or check: which CAID is supported, what provider IDs, from which satellite. For NTV card sharing — this is Viaccess (0500) with provider IDs 032830/032831. If the provider cannot name specific parameters — they are most likely just reselling someone else's lines and do not know what is inside.

After changing the CAID or updating keys on the broadcaster's side, some providers update within hours, others — within days or do not update at all. Ask how quickly they reacted to the last update.

Availability of backup servers and protection against fraud

A normal infrastructure implies at least two servers — primary and backup. In OScam, this is configured through two [reader] blocks with the same group and the parameterfallback = 1 for the backup. The provider must provide both addresses themselves.

Protection against fraud (sharing cards further across the network) — these are parameters on the server side. An honest provider limits the number of simultaneous ECM requests from one line. If this is not the case — one card can be resold to hundreds of clients, and stability will not be there.

Trial period for checking before payment

Checklist for self-checking line quality through OScam logs:

• ECM time during peak hours — should be up to 500 ms
• Rejected counter in WebIF — should not grow during normal viewing
• Logs/var/log/oscam.log at debug level 4 (loglevel = 4) — look for linesCAID:0500 REJECTED orno matching reader
• Ping to the server host — up to 100 ms is excellent, up to 150 ms is good
• Stability during 2–3 hours of evening prime time

Enable detailed logging in OScam: in oscam.conf setloglevel = 4 andlogfile = /var/log/oscam.log. After the restart, the log will contain complete information for each ECM request with response time and status.