CCcam DVBAPI Delayer: Fix Freezing & Setup Guide

If you've landed here because your channels freeze every 10 seconds on the dot, you're dealing with a timing race — not a bad line. The CCcam dvbapi delayer configuration is the knob that fixes it. This guide covers exactly how to set it, how to read the logs to tune it properly, and when it won't help so you don't waste three hours chasing the wrong thing.

What the DVBAPI Delayer Actually Does

The DVBAPI interface is how your set-top box (or Linux-based receiver running Enigma2, for example) exposes its CA descrambler to userspace software. Instead of using a physical CAM, a DVBAPI client like OScam or CCcam's built-in DVBAPI plugin writes control words (CWs) directly into the demuxer via /dev/dvb/adapterX/caY.

The delayer inserts a pause — measured in milliseconds — between the moment the software receives a decrypted CW and the moment it writes that CW to the hardware. Without that pause, the CW can arrive faster than the demuxer is ready to consume it. The result: a black screen, a freeze, or a brief stutter at every key change.

ECM-to-control-word timing in CCcam DVBAPI

Quick definitions so we're on the same page. An ECM (Entitlement Control Message) is a short encrypted packet broadcast in the DVB stream. Your sharing client sends it upstream, the card decrypts it, and hands back a control word — the actual 8-byte key your descrambler needs to decode the video. That full round trip takes some milliseconds depending on your line.

Most pay TV providers rotate their keys on a crypto period of roughly 10 seconds. When the period flips, a new ECM arrives, a new CW gets fetched, and the DVBAPI client needs to write it to the demuxer at exactly the right moment. Too early and the hardware discards it. Too late and you get a freeze gap.

Why a delay is needed before writing the CW to the demuxer

The demuxer hardware on many receivers — especially older Dreambox units and budget Enigma2 boxes — has a tiny window where it'll accept a new CW. If your sharing client is fast (which is usually a good thing), it can win the race against the hardware and write before the demuxer has finished transitioning to the new crypto period.

The delayer forces the software to sit on the CW for N milliseconds before writing. That breathing room lets the hardware catch up. It sounds counterintuitive — slowing down the response to fix a problem — but it works, and it works consistently when tuned correctly.

How CCcam differs from OScam's dvbapi handling

CCcam's native DVBAPI support is fairly basic. It'll work, but the configurability is limited — you get a global delay, and that's about it. OScam's dvbapi implementation is considerably more mature: per-CAID delays, per-SID overrides, a web interface showing real-time ECM times, and better adapter targeting.

This is why most production setups bridge CCcam into OScam: CCcam handles the protocol and the card sharing network, but OScam handles the actual descrambling. If you're still running CCcam DVBAPI natively and fighting freezes, the OScam migration path is worth considering — more on that in the last section.

Step-by-Step Delayer Configuration

Getting the CCcam dvbapi delayer configuration right starts with knowing which file to edit. The path differs depending on your image and whether you're using CCcam's built-in DVBAPI or bridging through OScam.

Locating the config: CCcam.cfg vs oscam.dvbapi

For pure CCcam DVBAPI, the main config lives at /var/etc/CCcam.cfg on most Enigma2 images (OpenATV, OpenPLi, OpenViX). On older setups or Gemini-based images you might find it at /etc/CCcam.cfg. Check both if you're not sure.

If you're using OScam with a CCcam reader (the more common setup), the delay lives in /etc/tuxbox/config/oscam/oscam.dvbapi or /var/etc/oscam.dvbapi, again depending on your image. OpenATV tends to use /var/etc/. OE-Alliance images sometimes put it under /etc/oscam/. Run find / -name oscam.dvbapi 2>/dev/null if you can't locate it.

Setting the delay value (DELAY: parameter and ms ranges)

In CCcam.cfg, the line looks like this:

DELAY : 150

That's milliseconds. Start at 100–300 ms and tune from there. If channels still freeze on key change, bump it up by 50 ms increments. If zapping feels sluggish — you press a button and wait a beat too long — you've gone too high, bring it back down in 25 ms steps.

In oscam.dvbapi, the format is different. A global delay line looks like:

DELAY : 150

But you can also target specific entries. The full per-entry format is:

P: CAID:ProvID:SID:PMT_PID:ECM_PID : DELAY

For example, to set a 200 ms delay for a specific CAID/provider combination while leaving everything else at 100 ms:

DELAY : 100P: 0963:000000:0000:0000:0000 : 200

Where some receivers expose a web interface for CCcam (the built-in HTTP server runs on port 16001 by default), you may find a "DVB API DELAY" field there too. Don't rely on it alone — changes through the web UI don't always survive a daemon restart unless the underlying config file is also updated.

Per-channel and per-CAID delay overrides

This is what most guides miss. A global delay is blunt — it slows every channel change across every CAID. But in practice, the timing problem is almost always CAID-specific or even transponder-specific. One provider's crypto period syncs fine at 100 ms; another needs 250 ms because their ECMs arrive slightly late relative to the key change.

OScam's oscam.dvbapi lets you scope delays tightly. If you know the CAID (e.g., 0963 or 1810) of the problematic package, set a higher delay only for that entry and leave the global lower. Your sports package zaps fast; your movie package stays stable. Both work.

On a transponder with mixed CAIDs — say, a free-to-air package multiplexed with an encrypted one — make sure your CAID targeting is precise or you'll slow zapping on channels that don't need it.

Restarting the daemon and confirming the change loads

CCcam doesn't hot-reload config. After editing CCcam.cfg, restart it:

killall -9 CCcam && sleep 2 && CCcam

Or via your init script if you have one set up (/etc/init.d/CCcam restart). Check /tmp/CCcam.log or whatever log path you've configured and look for the DELAY line being parsed at startup.

For OScam, a soft restart is enough:

killall -HUP oscam

Or use the OScam web interface at port 8888 → Restart. Check the info page confirms your dvbapi delay value is what you expect.

Reading the Logs to Find the Right Delay

Guessing delay values is a waste of time. The logs tell you exactly what's happening, and five minutes reading them beats an hour of trial and error.

Enabling debug logging (loghistorysize, log levels)

In OScam's oscam.conf, under [global]:

[global]logfile = /tmp/oscam.logloghistorysize = 4096loglevel = 64

Level 64 gives you ECM-level detail without flooding the log with noise. If you need more, combine it: loglevel = 64+32 adds reader debug info. Anything higher and you'll need a bigger loghistorysize or the history fills up before you can read it.

For CCcam, log verbosity is set in CCcam.cfg:

DEBUG LEVEL : 1

Level 1 is usually enough to see CW delivery events. Level 3 gives full ECM traffic but generates a lot of output.

Interpreting decode/freeze timing in the log

What you're looking for is the time between ECM arrival and CW delivery, and how that correlates with your freeze events. In OScam logs, each decode line looks roughly like:

[reader] (ecm time: 87 ms) CW found [0963/000000/1234]

That 87 ms figure is your round-trip ECM time. If your crypto period is 10 seconds and your ECMs are arriving at 87 ms decode time consistently, a delay of 100–150 ms covers the gap with margin. If that number spikes to 400 ms occasionally (network hiccup, busy server), you need either a higher delay or a better line.

Compare freeze timestamps in your receiver log against the key-change interval. If freezes land consistently at 9.8–10.2 second intervals, that's a timing issue and the delayer will fix it. If freezes are random — every few minutes, no pattern — that's not a timing issue.

Tools: tail -f, oscam status page, ECM time column

The OScam web interface at http://[receiver-ip]:8888 has an ECM/EMM tab that shows live decode times per CAID. That "msec" column is what you base your delay tuning on. It updates in real time.

For raw log watching:

tail -f /tmp/oscam.log | grep "ecm time"

Run that while zapping and watching for freezes. The practical tuning method: start high (say, 300 ms), watch for zapping sluggishness, reduce by 50 ms every few minutes while monitoring for freeze events. When freezes reappear, add 75 ms back as a safety margin and call it done.

Common Misconfigurations and How to Fix Them

Most freeze problems people blame on the delayer are actually something else. Here's what I see consistently.

Delay set globally when only one CAID needs it

Setting DELAY : 300 globally to fix one stubborn channel package means every single channel change takes 300 ms longer. If you're jumping through a sports event and hitting 15 channels in 30 seconds, that adds up to noticeable lag.

Fix: identify the CAID causing problems (check the ECM log), set the high delay only for that CAID in oscam.dvbapi, and bring the global back to 100 ms or lower.

Wrong adapter/demux index for multi-tuner boxes

On a dual-tuner receiver — common with Vu+ Duo2, Dreambox DM920, or similar — you have /dev/dvb/adapter0 and /dev/dvb/adapter1, each with their own ca0 device. If your DVBAPI client is writing to adapter0/ca0 but the active tuner is adapter1, you'll get complete decrypt failure regardless of delay values.

In OScam's oscam.dvbapi, you set the adapter with:

BOXTYPE : dreamboxREOPENONZAP : 1

And verify the adapter enumeration in /proc/bus/pci/ or via ls /dev/dvb/. Some images number tuners differently after a kernel update. If your config hasn't changed but decryption suddenly stopped working, check whether the adapter indices shifted.

Conflicts between CCcam DVBAPI and a parallel OScam instance

This one is surprisingly common. Someone installs OScam alongside a running CCcam setup without disabling CCcam's built-in DVBAPI. Both try to open /dev/dvb/adapter0/ca0 simultaneously. The result is unpredictable — sometimes one wins, sometimes they fight, always causing instability.

You need exactly one DVBAPI client active. If you're using OScam, disable DVBAPI in CCcam by removing or commenting out the DVBAPI : 1 line (or equivalent) in CCcam.cfg. If you're using CCcam's native DVBAPI, make sure OScam isn't configured as a dvbapi client.

Receiver-side caching masking the real problem

Some Enigma2 images — particularly older OpenPLi builds — cache the last-used CW briefly. This can make it look like decoding is working when it's actually serving stale keys for a second or two before failing. The symptom: no freeze on the first watch, but fast zapping causes brief black screens that resolve themselves.

Disable CW caching if your image exposes that option, or update to a current image build where this is better handled. OpenATV 7.x and OpenPLi 9.x are both more reliable here than anything from 2022 or earlier.

When the Delayer Won't Help (and What Will)

This is the section most guides skip, and it matters. The CCcam dvbapi delayer configuration fixes exactly one thing: a timing race between CW delivery and demuxer readiness. It doesn't fix network problems, bad lines, or hardware limitations.

Freezing caused by network latency, not timing

If your ECM round-trip times in the OScam log are jumping between 80 ms and 1200 ms randomly, that's network instability. Maybe the share peer is overloaded. Maybe your internet connection has packet loss. The delayer has nothing to contribute here — you can't set it high enough to cover a 1.2-second spike without making zapping feel broken.

Diagnose network issues with ping -i 0.2 [server-ip] running while watching TV. If you see outlier pings coinciding with freeze events, the delay setting is irrelevant. Fix the network, or find a more stable share source.

Crypto period / key-change problems vs delay problems

Timing-related freezes follow a pattern: they happen at predictable intervals matching the crypto period. If you note a freeze at 10:01:10 and another at 10:01:20 and another at 10:01:30, that's a 10-second crypto period and a delay problem. Fix it with the delayer.

If freezes are at 10:01:12, 10:04:47, 10:09:03 — no pattern — that's not a key-change timing issue. Don't tune the delayer, investigate something else.

Hardware demux limitations on older receivers

Some older receivers — Dreambox 500s, first-gen AZBox units, certain no-name Chinese boxes — have hardware demuxers that simply can't accept software-delivered CWs fast enough regardless of how the delay is tuned. The window is too narrow, or the hardware has quirks that no software delay can compensate for.

On these boxes, the freeze is often a few frames rather than a hard black screen, and it happens on every single key change no matter what you set. If that's your situation, the hardware is the bottleneck. A modern Vu+, Gigablue, or AX receiver will handle the same setup without issues.

Migrating from CCcam DVBAPI to OScam for stability

If you're running CCcam's native DVBAPI and hitting walls with configuration options, migrating to OScam as the DVBAPI handler while keeping CCcam as the sharing protocol is the right move. The bridge is simple at a high level: OScam connects to CCcam as a reader via the newcamd or CCcam protocol on port 10000 (or whatever port your CCcam server uses), then handles all local DVBAPI descrambling itself.

In oscam.server, your CCcam reader looks like:

[reader]label = cccam_mainprotocol = cccamdevice = 127.0.0.1,10000user = your_cccam_userpassword = your_cccam_passcccversion = 2.3.0ccckeepalive = 1

OScam then handles the DVBAPI side with its full delay control, per-CAID targeting, and the web interface to monitor it all. The freeze problems that stem from CCcam's basic DVBAPI implementation usually disappear immediately when you make this switch.