Dreambox One 4K black screen after changing channels solution: step-by-step diagnostics 2026

If you googled something like "dreambox one 4k black screen after changing channels solution," you have probably already passed the stage of "just reboot the receiver" and want to get to the point. The good news is that the problem almost always boils down to one of three reasons: HDMI and video mode, decryption timeouts in the softcam, or the network to the server. The bad news is that they can be easily confused if you don't know where to look first. Below is a working methodology with real commands, paths to configs, and logs, not just general advice.

Quick diagnostics: three different "black screens" — do not confuse them

The first thing to do is not to dive into the configs, but to understand what kind of black screen you have. There are three of them, and they are treated in completely different ways.

Black screen with sound — almost always video/HDMI, not sharing

If after zapping the sound is there but the picture is not — the stream has already been decrypted. The control word has been obtained, the decoder is working, so the softcam and server are not to blame. The video part is at fault: resolution change, frame rate change, or HDMI handshake with the TV. Go straight to the section about videomode.

Black screen without sound, but the channel is "live" — decryption problem (ECM)

There is neither sound nor picture, but the EPG is loading and the clock in the corner is ticking — this means the transport stream is going normally, the tuner has caught the signal, but the decryption has not started. This is a classic sign that OScam or CCcam did not manage to obtain the control word in time. We dig into ECM time and softcam settings.

Black screen + tuner message/"No signal" — signal, DiSEqC, multi-stream

If the receiver honestly shows "No signal" or a tuner error — this is not about the softcam and not about HDMI at all. Here we look at SNR/BER, DiSEqC switches, and multi-stream/PLS parameters on the specific transponder.

Quick test in 60 seconds: FTA channel vs coded

Switch to an open (FTA) channel on the same transponder. If the picture appears normally — the tuner and HDMI chain are fine, and all diagnostics go towards the softcam. If the black screen is also caught on the FTA channel — the issue is with the video mode, HDMI, or signal, and OScam can be temporarily left alone. Also, open Menu → Information → Service (or press Info twice) and check the PIDs, CAID/PROVID, and ECM status. In the OScam web interface, this same decryption status is visible in real-time on the Status tab — it is immediately clear whether ECM requests are going through and whether the box is receiving responses.

Reason #1: HDMI handshake and video mode switching (SD/HD/UHD, 50/60 Hz)

This is the most common reason that on Dreambox One 4K the black screen after changing channels solution is found without a single line in the softcam configs. The mechanics are simple: with each zapping, the receiver can change the output resolution and frame rate according to the characteristics of the new stream. The TV is negotiating over HDMI at this moment — re-reading the EDID, raising HDCP — and some panels, especially AV receivers and HDMI switches in the chain, simply do not keep up. The screen goes black for a second or two, and sometimes does not return at all.

Why does the screen go black for 1–5 seconds and not return when zapping from 1080i to 576i/2160p

Each such change is a complete reinitialization of the HDMI link, not just a "redrawing of the frame." The longer the chain of devices between the receiver and the panel, the higher the chance that someone in this chain will not manage to re-establish. Some TVs even have a bug with hanging on a negative handshake — in this case, only physically disconnecting the HDMI cable helps.

Checking and fixing the video mode: /proc/stb/video/videomode and videomode_choices

Via SSH, log into the box and check the available modes:

cat /proc/stb/video/videomode_choices

The current mode looks like this:

cat /proc/stb/video/videomode

Next, we firmly fix one mode, for example:

echo 1080p50 > /proc/stb/video/videomode

The point is to force the receiver to scale any incoming stream (576i, 1080i, 2160p) to the same output, instead of pulling the HDMI handshake on each channel. The same is duplicated through the GUI: Menu → Setup → Video, and is actually recorded in/etc/enigma2/settings with keys likeconfig.av.videomode,config.av.autores.* andconfig.av.videorate.*.

Disabling automatic frame rate switching (Auto Frame Rate, MRUA)

It is AutoResolution and Multi-Rate (Auto Frame Rate) that most often initiate HDMI reinitialization with each switch because they try to adjust the output to the frequency of the source content — 50 Hz for the European stream, 60 Hz for something else. On Dreambox One 4K, a typical problem is the transition between 2160p channels and 1080i channels: this is where auto-adjustment most often drops the link. Disable both options in Menu → Setup → Video and fix one mode — 1080p50 or 2160p50, depending on what you need.

HDCP 2.2, "smart" TVs and AV receivers in the chain

If the black screen disappears when directly connected to the TV and returns as soon as a soundbar, AV receiver, or HDMI switch is added to the chain — this is HDCP handshake. Solutions in order: try another HDMI input on the TV, use a High Speed cable rated for 18 Gbps (HDMI 2.0), temporarily exclude the switch/receiver from the chain, and on the TV itself, enable the extended input mode — on Samsung, this is usually called HDMI UHD Color, on LG — Enhanced Format, and on some models, you may find the wording Input Signal Plus or Deep Color.

Deinterlacer/scaler and policy settings: /proc/stb/video/policy and policy2

/proc/stb/video/policy is responsible for behavior when aspect ratios do not match (scale, panscan, letterbox), andpolicy2 — specifically for how SD content is stretched in HD output mode. If the picture on SD channels looks distorted after fixing the videomode, it can be corrected here, rather than rolling back the video mode. A separate warning: if after the commandecho the screen goes completely dark in videomode and nothing helps — do not reset the box. Access via SSH and blindly revert the value, for example back to what was first in the videomode_choices list — usually this is the factory safe mode.

Reason #2: the softcam does not have time to decrypt the channel (ECM timeouts in OScam)

If the FTA test showed that the issue is not with the video — we move on to the softcam. OScam configurations are usually located in/etc/tuxbox/config/oscam/ (in some images — directly in/etc/tuxbox/config/, keys in/usr/keys/):oscam.conf,oscam.server,oscam.user,oscam.dvbapi. For CCcam — one file,/etc/CCcam.cfg.

The mechanics are as follows: when zapping, enigma2 informs the softcam of the new CAID/PID of the channel via dvbapi. The softcam sends an ECM request to the remote reader and waits for the control word. If the response comes later than the box is ready to wait — the picture does not start, and you get a black screen with no sound while the EPG is live, even though the channel is technically working.

How to read ECM time: OScam webif, port 8888 and real-time status

Enable the web interface inoscam.conf, section[webif]:

httpport = 8888
httpuser =<user>
httppwd =<pass>

After restarting, openhttp://<box IP>:8888 and look at the Readers tab — there is an ECM time column for each reader, and a Status column for clients showing Idle/Last. This is the fastest way to see what exactly is causing the lag: a specific reader or decryption in general.

Key parameters in oscam.conf: [global] and logs in /var/log/oscam.log

The live log is viewed with the command:

tail -f /var/log/oscam.log

Keep it open during zapping — it shows both the ECM response time and connection drops with the reader at the moment the picture disappears.

What really fixes zapping: ecmtimeout, lb_retrylimit, lb_nbest_readers, cachedelay

Guideline for ECM time: up to 300–500 ms — zapping feels fast and comfortable, 500–1000 ms — pauses are noticeable, and above one second — this leads to consistently regular black screens during switching. The levers inoscam.conf:lb_mode enables balancing between readers based on actual response speed,lb_nbest_readers limits the number of readers to which the softcam actually sends requests (there's no need to spam all lines at once — this only adds overhead), andlb_retrylimit sets how long to wait for a slow reader before switching to the next one.ecmtimeout should be adjusted last — it does not fix the cause, but simply gives the softcam more time to wait for a slow response, at the expense of the zapping speed itself.

oscam.server: cccmaxhops, cccwantemu, reconnecttimeout, keepalive for card sharing

Inoscam.server for card sharing readers, the parametercccmaxhops is critical — keep the value at 1–2. Each additional hop in the chain exponentially increases ECM time because the request physically passes through another server and incurs another network delay — hence the black screens with a high hop count.keepalive = 1 prevents the TCP connection from "falling asleep" during idle time, andreconnecttimeout determines how quickly the softcam will raise a broken session — this is especially noticeable during the first zapping after a long idle period of the receiver.

Why CCcam.cfg behaves differently and which lines to change there

In/etc/CCcam.cfg the logic is similar, but without the flexible balancing of OScam: look at the linesMAXHOP (analogous to cccmaxhops),KEEPALIVE and the reconnect timeout. It is also useful to remove unnecessary local readers from the config that CCcam polls anyway with each ECM request — this adds delay without benefit. Also, check the dvbapi mode in OScam (parametersau,boxtype = dreambox,delayer) — sometimes it is the pmt-mode that affects how quickly decryption starts immediately after switching channels.

Reason #3: network and channel stability to the server

ECM time is not only processing on the server but also the network between it and your box. Half of the cases where everything seems to be set up correctly, but a black screen still appears intermittently — it's precisely the network.

Wi-Fi vs Ethernet: why card sharing hates wireless networks

Wi-Fi introduces jitter — not a loss of speed, but rather instability in delay from packet to packet. For streaming IPTV, this is not critical because video is buffered. However, ECM exchanges cannot be buffered: the softcam waits for a specific response in a specific time window. Connect the box with a cable if you haven't done so already.

Diagnostics: ping, mtr, packet loss, and jitter to the server

Look at the spread, not the average:

ping -c 100<host>

In the output, max and mdev are important, not avg. The average ping can be excellent with 5 spikes of 2-3 seconds over a hundred packets — and it is these spikes that cause misses beyond the ECM timeout, that is, the very effect of "zapping intermittently."

MTU, power saving of the network adapter, and "sleeping" TCP session

If the black screen appears strictly during the first zapping after a night of inactivity, and everything works afterwards — this is a NAT timeout on the router or the provider closed the idle TCP session. The softcam has to re-establish the connection right at the moment when you are waiting for the picture. This is treated withkeepalive and reasonablereconnecttimeout in the reader's config.

Ports and firewall: typical ranges 12000–20000 and why port consistency is important

Card sharing protocols usually operate over TCP on a user port in the range of approximately 12000–20000. For outgoing connections from the box, nothing special needs to be forwarded on the router, but checking the port's availability is useful:

nc -zv<host> <port>

If the nc utility is not available on the image — the same result can be achieved with telnet on the required port.

DNS and dynamic addresses: when the black screen appears "on schedule"

If the server is behind a dynamic domain, and the box has cached the old IP — sooner or later everything breaks at once, and no timeout settings will help until the DNS record on the box side is updated.

Reason #4: signal, transponder, and the peculiarities of the channels themselves

Changing the channel can mean not only changing the CAID but also changing the codec — switching from H.264 to HEVC/H.265 in UHD channels. Some black screens occur precisely at this boundary.

SNR/BER and why "100% signal" guarantees nothing

The signal level scale on most receivers is ACG, it almost always shows a number close to the maximum. You need to look at SNR (signal-to-noise ratio) and BER (bit error rate). At the threshold, zapping "intermittently" catches a black screen precisely because the decoder sometimes fails to synchronize with the stream.

Multistream, T2-MI, and channels that Dreambox One 4K pulls differently

Multistream transponders require the correctly specified PLS code during scanning. If the settings were imported from another receiver or downloaded from someone else's list, some multistream parameters may be lost — hence the instability on specific channels, not on the entire package.

HEVC/H.265 vs H.264: black screen when switching to UHD channel

If there is sound but no picture strictly on HEVC channels, while H.264 channels work normally — the issue is not with the decoder (Dreambox One 4K can handle HEVC hardware-wise), but with the HDMI handshake: changing the codec almost always entails a change in resolution and HDMI input mode on the TV.

Corrupted bouquet and outdated channel list after satellite reconfiguration

After changing the satellite position or a major import of settings, it makes sense to manually rescan problematic transponders and remove duplicate services — outdated PIDs lead to attempts to decode a non-existent stream.

AC-3/E-AC-3: when there is sound but video "stutters" (and vice versa)

On some channels, the main audio track is AC-3 or E-AC-3, and if the receiver starts it faster than the video decoder can grab the frame, you hear the sound a fraction of a second before the picture. This is normal and does not require fixing if the delay is less than a second.

Step-by-step plan: from logs to a working solution

We gather everything into a single checklist. This is how the answer to the question "dreambox one 4k black screen after channel change solution" is found in practice — not through guesses, but through a systematic elimination of causes.

Step 1. Gather facts: SSH, tail logs enigma2 and oscam.log at the moment of zapping

Connect:ssh root@<box's ip>. Open in one windowtail -f /var/log/oscam.log, in another — enigma2 log (the path depends on the image, often it's the systemd journal, accessible vialogread or files in/home/root/logs/). Switch the channel and watch what happens at the moment the picture disappears.

Step 2. Separate video and decryption (FTA test)

Repeat the test from the first section on several encoded and open channels from different transponders to rule out randomness.

Step 3. Fix the videomode and disable auto-adjustment

If the FTA test indicated a video issue — we fix the mode via/proc/stb/video/videomode and disable AutoResolution/Auto Frame Rate in Menu → Setup → Video.

Step 4. Configure timeouts and hops in the softcam

If the problem is with decryption — reducecccmaxhops, enablekeepalive, configurelb_nbest_readers andlb_retrylimit, and only as a last resort adjustecmtimeout.

Step 5. Check the network and keepalive

Switch the box to Ethernet if it’s still on Wi-Fi, and take 100 pings to the server, looking at max and mdev, not the average.

Step 6. If nothing helped: clean firmware and restore settings

Reflashing should be done as a last resort and only with a backup: copy/etc/tuxbox/config and/etc/enigma2 to your computer before making any changes. After updating the image, softcam configs may sometimes be overwritten or the path to them may change — this is a separate and common reason why the problem returns right after the update.

The main rule at all steps — change one parameter at a time and after each change perform a series of 10–15 switches between HD and UHD channels. If you change several settings at once, it becomes impossible to understand what exactly helped.

How to choose a card sharing source to avoid black screens (without names)

Separately about the source of decryption, without mentioning specific services — only the assessment methodology.

Criteria: stable ECM time, not the number of channels in the list

The number of channels in the package says nothing about the quality of operation. The only metric that really affects whether you will have a black screen while zapping is the stability of ECM time, which you measure yourself in the webif OScam over at least several days, including prime time.

Hops, local cards, and why a long chain = slow zapping

The more intermediate servers between the source and your reader, the higher and more unstable the ECM time. This is network physics, not a matter of luck — a long chain of hops almost certainly leads to black screens during zapping sooner or later.

Signs of a resold channel: increase in ECM time during prime time

If the black screen appears strictly in the evening, 19:00–23:00, while everything works fast during the day — this is visible directly in the logs as an increase in ECM time specifically during peak hours. This is a signal of an overloaded source, not a problem on your side.

Legal aspect: legal scenarios and your own card

The only completely legal scenario here is using your own, legally obtained subscription or card within your home network, between your receivers. The legal status of card sharing and its specific forms depends on the country and the terms of the contract with the broadcasting operator, so the material is educational-technical in nature and does not replace consultation on local legislation.