Dreambox 920 freezes every 5 minutes: CCcam fix 2026

If you are googling dreambox 920 freezing every few minutes cccam fix at three in the morning from your phone, while the picture on the screen has frozen for the third time in a row — this article is for you. I have been through this personally, on three different DM920 boxes with different images. And in 90% of cases, the cause is not where it is usually looked for first. Below is a working diagnostic algorithm, not a list of “try reinstalling the image” and “change the server.” Let's break down step by step where to really dig: ECM timeouts, network, memory, hardware, signal, and finally, the sharing source side.

Quick diagnostics: what exactly is freezing — the picture, CCcam, or the entire receiver

The first thing to do is to stop calling the problem with one word “freezing.” There are three completely different scenarios, and they are treated differently.

Scenario one: only the picture freezes, while the remote responds, the menu opens, and the web interface on port 80 is accessible. This is almost always a problem with ECM requests, the network, or the sharing source itself. Enigma2 is alive, CCcam is alive — it just does not manage to receive the control word in time.

Scenario two: the CCcam daemon crashes and restarts. The picture disappears for a few seconds, then the channel reopens by itself. Here the problem lies in memory, the architecture of the binary, or a conflict with softcams.

Scenario three — the most unpleasant: the entire receiver goes into reboot or freezes completely, the remote does not respond, and the web interface does not open. This is no longer CCcam — it’s power, overheating, drivers, or a corrupted image.

It’s easy to distinguish them in five minutes via telnet or SSH (port 23 or 22, login root). We connect and look at the live system:

top -d 1
free -m
uptime
cat /proc/loadavg
ps aux | grep -i cccam

If during the freeze the ping to the receiver continues to respond and the web interface opens — the problem is definitely not hardware, we go to diagnose ECM and the network. If the ping disappears and the receiver is completely inaccessible — we immediately move to the section about power and overheating.

The second step is to enable the CCcam log. In /etc/CCcam.cfg, we add or check the line:

DEBUG              : 1

After restarting the softcam, we watch the log in real time:

tail -f /tmp/cccam.log

Here is an important detail that almost no one mentions out loud: if the freezes occur strictly at the same interval — say, every 4-5 minutes, second by second — this is almost never a hardware problem. This is a cycle: either re-sending ECM, or reconnecting the TCP session due to NAT timeout on the router, or a watchdog that quietly restarts the daemon. Random, “floating” freezes in time more often indicate a signal or disk issue. Take a stopwatch and measure the actual interval — this is the first and cheapest diagnosis that immediately rules out half of the hypotheses.

Reason #1: ECM timeouts and key change cycle (the most common case on DM920)

This is where the classic dreambox 920 freezing every few minutes cccam fix lives, which everyone is looking for. The mechanics are simple, but it is rarely explained in layman's terms.

The provider changes the control word (CW) — the key for decrypting the stream — usually every 10 seconds. Your CCcam client must manage to send an ECM request to the sharing server and receive a response before the current CW's action window expires. If the round-trip time to the server is higher than this window, the picture freezes exactly until the next successful key change. Hence the periodicity — freezes do not come randomly, but in batches, synchronously with the CW change cycle. Now let's look at the actual directives in /etc/CCcam.cfg that control this behavior:

ECM TIMEOUT        : 3000
WAIT TIME          : 0
DEADTIME           : 3
MAX HOPS           : 2

ECM TIMEOUT is set in milliseconds — this is the time the client waits for a response from the card before trying the next one in the list. A value that is too large — and the receiver hangs for a long time, waiting for a response from a dead or overloaded source, instead of quickly switching to an alternative card. This is perceived as “freezing for a few seconds.” A value that is too small — on the contrary, leads to constant unnecessary retransmissions and load on the source, even when it responds normally, just a bit slower than usual. DEADTIME determines how many seconds a card is considered “dead” after a failure before it is tried again. MAX HOPS limits the number of intermediate servers through which the request can pass — more on this in the section about the source side. How to choose a reasonable ECM TIMEOUT value? Don’t take a number from someone else's forum — measure the actual RTT to the server:

ping -c 20 <ip_сервера>

Take the average response time and multiply it by 3-4. If the average ping is 80 ms, a reasonable ECM TIMEOUT is somewhere around 250-350 ms, not 5000, as is often advised “for reliability.” Five seconds of waiting for a dead card with a 10-second key change cycle is already half of the lost window. In the log, look for lines like:

ECM timeout
no card found for this caid/provider
cw not found

If such lines appear regularly and synchronously with the freezes on the screen — you have found the cause. But it is important to understand: increasing the ECM TIMEOUT treats the symptom, not the cause itself. If the real problem is an overloaded source or a bad channel, you will simply stretch the waiting time for the frozen picture, rather than eliminate it. This is masking, not fixing. Separately about several lines C: in the config. If you have two or three alternative cards listed, the client tries them in order by default. A slow or dead first source with a large ECM TIMEOUT will block the transition to working alternatives — you pay for a backup card, and it harms you.

Reason #2: network — MTU, Wi-Fi, packet loss, and NAT timeouts

CCcam operates over TCP on the port specified by the server (typical values — 12000, 15000, 16000, and similar, but this is always the configuration of a specific source, not a standard). And here lies the second most frequent reason why dreambox 920 freezing every few minutes cccam fix is searched specifically with a time reference — periodicity. Home routers by default close “inactive” TCP sessions after some idle time (often 300-600 seconds, but budget models may have much stricter NAT table timeouts). If CCcam does not send keepalive often enough, a quiet reconnect occurs during the next ECM request — a new TCP connection is established in fractions of a second, but this is the very regular freeze at equal intervals. Check the active session:

netstat -anp | grep <порт>
ss -tnp

If you see that the connection is regularly closed and reopened — that’s it. Next, we go to analyze MTU. On PPPoE connections, the actual MTU is usually 1492, not the standard 1500, and if the receiver sends larger packets — they are fragmented or lost:

ping -M do -s 1472 <ip>

If ping with the “do not fragment” flag and a size of 1472 bytes (plus 28 bytes of headers = 1500) does not pass — reduce the packet size in steps of 10 bytes until you find a working value, and set the MTU in the network settings of the receiver accordingly. A separate painful topic — Wi-Fi dongles on DM920. The USB stack and drivers of wireless adapters on this receiver cause noticeable packet loss under load, especially on a crowded 2.4 GHz band and especially when recording to a USB drive simultaneously — the bus is shared between devices. The fastest diagnostic test: switch the receiver to an Ethernet cable. If the freezes disappear — the issue is closed, no need to dig into CCcam or the config, the problem was in the radio channel. Check the channel as a whole through mtr or traceroute to the sharing server — look not only at the average delay but also at jitter (variance) and the percentage of losses at each hop:

mtr -n -c 50 <ip_сервера>

And finally — some internet providers cut or throttle non-standard outgoing ports. If your ECM port is non-typical (not 80, not 443), it’s worth checking this separately, temporarily trying another internet access channel — for example, a mobile router — to rule out the provider as the cause.

Reason #3: image, memory, and swap — when CCcam crashes, not lags

If the log shows that the PID of the CCcam process changes during freezes — the daemon is actually crashing and restarting, not just waiting for ECM. This is a separate category of problems. First, check the architecture of the binary. DM920 is an ARM platform (Broadcom BCM7252S), and this is critical: old guides and configurations copied from Dreambox 500 or 800 are written for MIPS. A CCcam binary compiled for MIPS simply will not run on DM920 or will crash immediately after startup:

file /usr/bin/CCcam

The output should contain something like “ARM” or “ELF 32-bit LSB executable, ARM.” If it says MIPS — that’s the whole reason, no ECM cycle is involved here, you need the correct binary for the architecture of your image. Next — memory. Check dmesg for OOM-killer activity:

dmesg | tail -50
free -m

Look for lines like “Out of memory: Killed process.” If you find them — it means the system physically lacks RAM at that moment, often due to an inflated EPG cache or a large number of plugins running simultaneously with recording. The DM920 has enough memory for the normal operation of CCcam, so OOM usually indicates an external process that is consuming it, not a lack of resources of the softcam itself. Swap on flash memory is a controversial solution, and I would not recommend enabling it as the first step. Swap on the internal flash drive accelerates its wear, and the flash in DM920 is not rubbery. If OOM is confirmed in dmesg, it’s better to first find and kill the memory-hungry process, and only if that doesn’t help — to create a swap file on an external HDD with its own power supply, not on a USB flash drive and not on the built-in partition. Also, check the autostart and watchdog:

ls /etc/init.d/softcam
ps aux | grep -Ei 'cccam|oscam'

And here is a critical moment that is rarely discussed: if you have both CCcam and OScam running simultaneously, and both are trying to service the same channel — they compete for the same ECM queue to the decoder, and this causes characteristic periodic lags, very similar to a network problem. Stop the extra softcam:

/etc/init.d/softcam stop

And make sure that exactly one emulator is active in the system, not two at the same time.

Reason #4: hardware — power, overheating, and USB drives

This category of causes is almost never associated with CCcam, which is a pity — it covers a significant portion of complaints about dreambox 920 freezing every few minutes cccam fix. If the freezes coincide with disk access — timeshift, recording, scrolling through the EPG guide — the problem is most likely not in sharing at all. A USB-HDD without its own external power supply is a classic source of instability on DM920: under peak load (starting a recording, seeking through timeshift), the disk lacks power from the USB bus, causing a drop, and the entire Enigma2 freezes for a second or two. Overheating of the ARM chip is the second frequent cause, especially if the receiver is placed in a closed niche or cabinet without ventilation. Freezes that intensify 30-60 minutes after being turned on almost always indicate a temperature issue. You can find the file with the sensor readings like this, the path varies depending on the image:

find /sys -iname '*temp*'

Also check /proc — on some images, the temperature is available there. If the value steadily rises and exceeds 70-75°C, it’s due to dust on the radiator or lack of ventilation — regular cleaning and free space around the case will help, not dancing around the CCcam config. Bad sectors on the HDD or flash drive are another reason why the entire receiver freezes, not just sharing: the system tries to read a damaged block and hangs on the I/O operation. The most reliable way to separate hardware from software is to test by elimination. Disconnect all USB devices, turn off timeshift, leave only the antenna cable and Ethernet. If the freezes disappear — start reconnecting peripherals one by one until the problem returns. This will take about fifteen minutes, but it gives a definitive answer.

Reason #5: signal quality from the satellite, which is masked as a CCcam problem

Here’s a test that I have not seen in almost any guide, and it saves hours: open an FTA channel (uncoded, in open access) on the same transponder where the coded channel is freezing. If the FTA channel also stutters and breaks up — the issue is with the antenna, cable, or converter, and CCcam has nothing to do with it. You can confidently close all tabs about softcam configuration and go check the dish. If the FTA is perfectly stable, but the coded channel on the same transponder is freezing — you have just confirmed that the problem is indeed in sharing, and all further steps in this article make sense. In the Enigma2 interface on the channel information screen, look at SNR (signal-to-noise ratio) and AGC (gain level). Normal values depend on the specific dish and converter, but the rule is simple: if the SNR drops below a comfortable threshold for your configuration, ECM requests physically cannot be decoded correctly, and the picture breaks up — and it happens periodically, synchronously with signal fluctuations, not constantly. Banale, but really frequent causes: rain or wet snow on the dish, a neighboring satellite or transponder creating interference, oxidized F-connector on the cable. If everything worked for months without a single freeze, and the problem appeared suddenly without any changes in settings — start with the signal, not with the CCcam config. Seasonal weather deterioration is a much more likely cause of a sudden failure than that the softcam you haven’t touched suddenly “broke.” A separate case for DM920 with two tuners: if the freeze occurs only when viewing from one tuner, while the second works perfectly — the problem lies with the specific input, cable, or DiSEqC settings, and also has nothing to do with sharing.

Reason #6: server side — when there’s nothing to fix because the problem is not with you

If you have reached this section and local diagnostics are clear — the FTA channel is ideal, ping is stable, cable instead of Wi-Fi, memory is normal, CCcam daemon does not crash, the architecture of the binary is correct — further tweaking of the config is pointless. The sharing source is not coping, and this needs to be honestly acknowledged, rather than continuing to adjust the ECM TIMEOUT values in hopes of a miracle. Signs of a problem on the source side are visible directly in the log. The connection is alive, but the card appears and disappears — this is the "card added" / "card removed" cycle, which means that the server itself is losing and re-establishing access to the card, often due to overload or instability on its side. The second sign is consistently high ECM response times, noticeably above normal RTT, say 800-1000 ms with a usual ping of 50-100 ms. And the third — freezes occur simultaneously on all channels of one package, not selectively. Separately about hop. If your C-line specifies a hop greater than one, it means the request is not going directly to the card holder, but through one or more intermediate servers. Each additional hop adds its own delay, and the total delay grows linearly with the number of hops — and along with it, the likelihood of freezing during peak load increases. The longer the resale chain, the less predictable the stability at the output, and it is impossible to influence this with a local CCcam config in principle. Objective quality criteria for the source, without reference to specific names and brands: stable and predictable ECM response time, minimal number of hops in the chain, absence of cyclic reconnects and "card removed" in the log, functionality specifically during prime time — in the evening, when the load on any source is maximum. By the way, if freezes occur only in the evening, while everything is clear during the day — this is almost a diagnostic sign of overload on the source or channel: the number of simultaneous requests during prime time increases, ECM response time rises and starts to exceed your timeout. Checking the hypothesis is simple: if you have the opportunity to temporarily connect to another source with the same card or subscription, compare the logs side by side under the same local conditions. If the new source provides stable response time without reconnect cycles — the question is closed, it was not your receiver and not your network.

Step-by-step checklist: from symptom to solution in 20 minutes

I have gathered everything into a single action order — just follow the steps from top to bottom, each subsequent step depends on the result of the previous one.

Steps 1-3, isolation: open the FTA channel on the same transponder — if it freezes too, go to the signal and antenna, do not read further. Switch from Wi-Fi to Ethernet cable. Disconnect all USB devices and time shift.

Steps 4-6, logs: enable DEBUG 1 in /etc/CCcam.cfg and watch tail -f /tmp/cccam.log at the moment of freezing. Check dmesg | tail -50 for signs of OOM or driver errors. Run free -m and assess the remaining free memory.

Steps 7-9, config: measure RTT to the server via ping -c 20 and recalculate ECM TIMEOUT as 3-4 RTT. Ensure that only one softcam is running — CCcam or OScam, not both at the same time. Check the architecture of the binary with the command file /usr/bin/CCcam — on DM920 it should be ARM.

Step 10, conclusion: if after all checks the FTA is ideal, the network is stable, memory is normal, the daemon does not crash, but freezes still occur and are synchronous across all channels of the package — the problem is on the source side, and this is the final diagnosis.

Symptom	Probable cause	Command for checking
Freeze exactly every N minutes, the interval is stable	ECM/CW cycle or router NAT timeout	tail -f /tmp/cccam.log + stopwatch
Freeze only on HD channels of the package, SD is normal	Lack of bandwidth or a specific CAID problem	Compare the log for HD and SD channels simultaneously
The PID of the CCcam process changes after the freeze	The daemon crashes, likely OOM or incorrect architecture	ps aux | grep -i cccam + dmesg | tail -50
Freeze coincides with recording or time shift	USB/power disk problem, not CCcam	Disconnect USB and repeat the observation
FTA channel also freezes	Signal, antenna, cable, converter	SNR/AGC in the info panel Enigma2
Freezes only in the evening	Source overload during prime time	Compare ECM response time during the day and in the evening
Everything is clear over cable, but it freezes over Wi-Fi	Packet loss on USB Wi-Fi adapter	Switch to Ethernet and compare

If the checklist is fully completed and the local side is clear — you have honestly closed the issue of dreambox 920 freezing every few minutes cccam fix by your own efforts, and further actions are already beyond your receiver.