Dreambox 920 зависает каждые 5 минут: фикс CCcam 2026

Если вы гуглите dreambox 920 freezing every few minutes cccam fix в три часа ночи с телефона, пока картинка на экране третий раз подряд встала колом — эта статья для вас. Я через это проходил лично, причём на трёх разных боксах DM920 с разными образами. И в 90% случаев причина находится не там, где её ищут в первую очередь. Ниже — рабочий алгоритм диагностики, а не список из «попробуйте переустановить образ» и «смените сервер». Разберём по шагам, где реально копать: ECM-таймауты, сеть, память, железо, сигнал и, наконец, сторону источника шаринга.

Быстрая диагностика: что именно зависает — картинка, CCcam или весь ресивер

Первое, что нужно сделать — перестать называть проблему одним словом «зависает». Есть три совершенно разных сценария, и лечатся они по-разному.

Сценарий первый: замирает только картинка, при этом пульт реагирует, меню открывается, веб-интерфейс на порту 80 доступен. Это почти всегда проблема ECM-запросов, сети или самого источника шаринга. Enigma2 жив, CCcam жив — просто не успевает получить control word вовремя.

Сценарий второй: демон CCcam падает и перезапускается. Картинка пропадает на несколько секунд, потом канал переоткрывается сам. Тут проблема в памяти, архитектуре бинарника или конфликте софткамов.

Сценарий третий — самый неприятный: весь ресивер уходит в ребут или намертво виснет, пульт не отвечает, веб-морда не открывается. Это уже не CCcam — это питание, перегрев, драйверы или битый образ.

Отличить их легко за пять минут через telnet или SSH (порт 23 или 22, логин root). Подключаемся и смотрим на живую систему:

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

Если во время фриза ping до ресивера продолжает отвечать и веб-интерфейс открывается — проблема точно не аппаратная, идём разбирать ECM и сеть. Если ping пропадает и ресивер полностью недоступен — сразу переходим к разделу про питание и перегрев.

Второй шаг — включить лог CCcam. В /etc/CCcam.cfg добавляем или проверяем строку:

DEBUG              : 1

После рестарта софткама смотрим лог в реальном времени:

tail -f /tmp/cccam.log

Здесь важная деталь, которую почти никто не проговаривает вслух: если зависания приходят строго с одинаковым интервалом — скажем, каждые 4-5 минут секунда в секунду — это почти никогда не аппаратная проблема. Это цикл: либо переотправка ECM, либо реконнект TCP-сессии по таймауту NAT на роутере, либо watchdog, который тихо перезапускает демон. Случайные, «плавающие» по времени фризы куда чаще говорят о сигнале или диске. Возьмите секундомер и замерьте реальный интервал — это первая и самая дешёвая диагностика, которая сразу отсекает половину гипотез.

Причина №1: ECM-таймауты и цикл смены ключей (самый частый случай на DM920)

Вот тут и живёт классический dreambox 920 freezing every few minutes cccam fix, который ищут все. Механика простая, но её редко объясняют по-человечески.

Провайдер меняет control word (CW) — ключ для расшифровки потока — обычно каждые 10 секунд. Ваш CCcam-клиент должен успеть отправить ECM-запрос на сервер шаринга и получить ответ до того, как истечёт окно действия текущего CW. Если round-trip time до сервера выше, чем это окно, картинка замирает ровно до следующей успешной смены ключа. Отсюда и периодичность — фризы приходят не хаотично, а порциями, синхронно с циклом смены CW. Теперь смотрим на реальные директивы в /etc/CCcam.cfg, которые управляют этим поведением:

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

ECM TIMEOUT задаётся в миллисекундах — это время, которое клиент ждёт ответ от карты, прежде чем попробовать следующую в списке. Слишком большое значение — и ресивер долго висит, ожидая ответа от мёртвого или перегруженного источника, вместо того чтобы быстро перескочить на альтернативную карту. Именно это и воспринимается как «зависание на несколько секунд». Слишком маленькое значение — наоборот, приводит к постоянным лишним пересылкам и нагрузке на источник, даже когда тот отвечает нормально, просто чуть медленнее обычного. DEADTIME определяет, сколько секунд карта считается «мёртвой» после неудачи, прежде чем её снова начнут пробовать. MAX HOPS ограничивает число промежуточных серверов, через которые может пройти запрос — об этом подробнее в разделе про сторону источника. Как подобрать вменяемое значение ECM TIMEOUT? Не берите число из чужого форума — измерьте реальный RTT до сервера:

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

Возьмите среднее время ответа и умножьте на 3-4. Если средний ping — 80 мс, разумный ECM TIMEOUT — где-то 250-350 мс, а не 5000, как часто советуют «для надёжности». Пять секунд ожидания мёртвой карты при 10-секундном цикле смены ключа — это уже половина потерянного окна. В логе ищите строки вида:

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

Если такие строки появляются регулярно и синхронно с фризами на экране — вы нашли причину. Но важно понимать: увеличение ECM TIMEOUT лечит симптом, а не саму причину. Если реальная проблема в перегруженном источнике или плохом канале, вы просто растяните время ожидания зависшей картинки, а не уберёте его. Это маскировка, а не фикс. Отдельно про несколько строк C: в конфиге. Если у вас прописано две-три альтернативные карты, клиент по умолчанию пробует их по порядку. Медленный или мёртвый первый источник с большим ECM TIMEOUT будет блокировать переход к рабочим альтернативам — вы платите за резервную карту, а она вам вредит.

Причина №2: сеть — MTU, Wi-Fi, потери пакетов и NAT-таймауты

CCcam работает поверх TCP на порту, который задаёт сервер (типовые значения — 12000, 15000, 16000 и им подобные, но это всегда конфигурация конкретного источника, а не стандарт). И тут кроется вторая по частоте причина, почему dreambox 920 freezing every few minutes cccam fix ищут именно с привязкой к времени — периодичность. Домашние роутеры по умолчанию закрывают «неактивные» TCP-сессии через какое-то время простоя (часто 300-600 секунд, но у бюджетных моделей встречаются и куда более жёсткие таймауты NAT-таблицы). Если CCcam не шлёт keepalive достаточно часто, при следующем ECM-запросе происходит тихий реконнект — новое TCP-соединение поднимается за доли секунды, но это и есть тот самый регулярный фриз через равные промежутки времени. Проверить активную сессию:

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

Если видите, что соединение регулярно закрывается и переоткрывается — это оно. Дальше идём разбирать MTU. На PPPoE-подключениях реальный MTU обычно 1492, а не стандартные 1500, и если ресивер шлёт пакеты крупнее — они фрагментируются или теряются:

ping -M do -s 1472 <ip>

Если ping с флагом «не фрагментировать» и размером 1472 байта (плюс 28 байт заголовков = 1500) не проходит — снижайте размер пакета шагами по 10 байт, пока не найдёте рабочее значение, и выставляйте MTU в настройках сети ресивера соответственно. Отдельная больная тема — Wi-Fi-донглы на DM920. USB-стек и драйверы беспроводных адаптеров у этого ресивера дают заметные потери пакетов под нагрузкой, особенно на переполненном 2.4 ГГц диапазоне и особенно когда одновременно идёт запись на USB-накопитель — шина делится между устройствами. Самый быстрый диагностический тест: переключите ресивер на кабель Ethernet. Если фризы исчезли — вопрос закрыт, дальше не нужно копать ни в CCcam, ни в конфиг, проблема была в радиоканале. Проверьте канал целиком через mtr или traceroute до сервера шаринга — смотрите не только на среднюю задержку, но и на jitter (разброс) и процент потерь на каждом хопе:

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

И последнее — некоторые провайдеры интернета режут или троттлят нестандартные исходящие порты. Если ECM-порт у вас нетипичный (не 80, не 443), стоит проверить это отдельно, временно попробовав другой канал доступа в интернет — например, мобильный роутер, — чтобы исключить провайдера как причину.

Причина №3: образ, память и swap — когда CCcam падает, а не тормозит

Если по логу видно, что PID процесса CCcam меняется во время фризов — демон реально падает и перезапускается, а не просто ждёт ECM. Это отдельная категория проблем. Первым делом проверьте архитектуру бинарника. DM920 — это ARM-платформа (Broadcom BCM7252S), и это критично: старые гайды и конфигурации, скопированные с Dreambox 500 или 800, написаны под MIPS. Бинарник CCcam, собранный под MIPS, на DM920 просто не запустится или будет падать сразу после старта:

file /usr/bin/CCcam

Вывод должен содержать что-то вроде «ARM» или «ELF 32-bit LSB executable, ARM». Если там MIPS — вот и вся причина, никакой цикл ECM тут ни при чём, нужен правильный бинарник под архитектуру вашего образа. Дальше — память. Смотрим dmesg на предмет активности OOM-killer:

dmesg | tail -50
free -m

Ищите строки вида «Out of memory: Killed process». Если находите — значит системе физически не хватает RAM в моменте, часто из-за раздутого EPG-кэша или большого числа плагинов, работающих одновременно с записью. У DM920 достаточно памяти для штатной работы CCcam, поэтому OOM обычно говорит о постороннем процессе, который её съедает, а не о нехватке ресурсов самого софткама. Swap на флеш-памяти — спорное решение, и я бы не рекомендовал включать его первым шагом. Swap на внутреннем flash-накопителе ускоряет его износ, а флеш в DM920 не резиновый. Если OOM подтверждён в dmesg, лучше сначала найти и убить процесс-пожиратель памяти, и только если это не помогает — заводить swap-файл на внешнем HDD с собственным питанием, не на USB-флешке и не на встроенном разделе. Отдельно проверьте автозапуск и watchdog:

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

И вот критичный момент, который почти нигде не разбирают: если у вас одновременно запущены и CCcam, и OScam, и оба пытаются обслуживать один и тот же канал — они конкурируют за одну и ту же ECM-очередь к декодеру, и это даёт характерные периодические подвисания, очень похожие на проблему с сетью. Останавливаем лишний софткам:

/etc/init.d/softcam stop

И убеждаемся, что в системе активен ровно один эмулятор, а не два одновременно.

Причина №4: аппаратная часть — питание, перегрев и USB-накопители

Эту категорию причин почти никогда не связывают с CCcam, а зря — она закрывает заметную часть жалоб на dreambox 920 freezing every few minutes cccam fix. Если фризы совпадают по времени с обращением к диску — таймшифт, запись, пролистывание EPG-гида — проблема, скорее всего, вообще не в шаринге. USB-HDD без собственного внешнего блока питания — классический источник нестабильности на DM920: при пиковой нагрузке (запуск записи, seek по таймшифту) диску не хватает тока с USB-шины, происходит просадка, и весь Enigma2 подвисает на секунду-другую. Перегрев ARM-чипа — вторая частая причина, особенно если ресивер стоит в закрытой нише или тумбе без вентиляции. Фризы, которые усиливаются через 30-60 минут после включения, почти всегда указывают именно на температуру. Найти файл с показаниями датчика можно так, путь отличается в зависимости от образа:

find /sys -iname '*temp*'

Загляните также в /proc — на некоторых образах температура доступна там. Если значение стабильно растёт и переваливает за 70-75°C, дело в пыли на радиаторе или отсутствии вентиляции — тут поможет обычная чистка и свободное пространство вокруг корпуса, а не танцы вокруг конфига CCcam. Битые сектора на HDD или флешке — ещё одна причина, из-за которой виснет весь ресивер целиком, а не только шаринг: система пытается прочитать повреждённый блок и подвисает на операции ввода-вывода. Самый надёжный способ отделить железо от софта — тест методом исключения. Отключите все USB-устройства, выключите таймшифт, оставьте только антенный кабель и Ethernet. Если фризы пропали — начинайте подключать периферию по одному устройству, пока проблема не вернётся. Это займёт минут пятнадцать, зато даёт однозначный ответ.

Причина №5: качество сигнала со спутника, которое маскируется под проблему CCcam

Вот тест, который я не встречал почти ни в одном гайде, а он экономит часы: откройте FTA-канал (незакодированный, в открытом доступе) на том же транспондере, где фризит закодированный канал. Если FTA-канал тоже подёргивается и рассыпается — дело в антенне, кабеле или конвертере, и CCcam здесь абсолютно ни при чём. Можно смело закрывать все вкладки про настройку софткама и идти проверять тарелку. Если же FTA идёт идеально ровно, а закодированный канал на том же транспондере фризит — вы только что подтвердили, что проблема действительно в шаринге, и все дальнейшие шаги по этой статье имеют смысл. В интерфейсе Enigma2 на экране информации о канале смотрите на SNR (отношение сигнал/шум) и AGC (уровень усиления). Нормальные значения зависят от конкретной тарелки и конвертера, но правило простое: если SNR проседает ниже комфортного порога для вашей конфигурации, ECM-запросы физически не успевают декодироваться корректно, и картинка рассыпается — причём именно периодически, синхронно с колебаниями сигнала, а не постоянно. Банальные, но реально частые причины: дождь или мокрый снег на тарелке, соседний спутник или транспондер, создающий помехи, окисленный F-разъём на кабеле. Если всё работало месяцами без единого фриза, а проблема появилась внезапно без каких-либо изменений в настройках — начинайте именно с сигнала, а не с конфига CCcam. Сезонное ухудшение погоды — куда более вероятная причина внезапного сбоя, чем то, что вдруг «сломался» софткам, который вы не трогали. Отдельный случай для DM920 с двумя тюнерами: если фризит просмотр только с одного тюнера, а со второго всё идеально — проблема в конкретном входе, кабеле или настройке DiSEqC, и тоже не имеет отношения к шарингу.

Причина №6: сторона сервера — когда чинить нечего, потому что проблема не у вас

Если вы дошли до этого раздела и локальная диагностика чиста — FTA-канал идеален, ping стабилен, кабель вместо Wi-Fi, память в норме, демон CCcam не падает, архитектура бинарника верна — дальше крутить конфиг бессмысленно. Источник шаринга не справляется, и это нужно честно признать, а не продолжать перебирать значения ECM TIMEOUT в надежде на чудо. Признаки проблемы на стороне источника видны прямо в логе. Соединение живо, но карта то появляется, то исчезает — это цикл «card added» / «card removed», который означает, что сервер сам теряет и переустанавливает доступ к карте, часто из-за перегрузки или нестабильности на его стороне. Второй признак — стабильно высокое время ответа ECM, ощутимо выше нормального RTT, скажем за 800-1000 мс при обычном пинге в 50-100 мс. И третий — фризы происходят одновременно на всех каналах одного пакета, а не выборочно. Отдельно про hop. Если в вашей C-строке указан hop больше единицы, это значит запрос идёт не напрямую к держателю карты, а через один или несколько промежуточных серверов. Каждый дополнительный хоп добавляет свою задержку, и суммарная задержка растёт линейно с числом прыжков — а вместе с ней растёт и вероятность зависания в моменты пиковой нагрузки. Чем длиннее цепочка перепродажи, тем менее предсказуема стабильность на выходе, и повлиять на это локальным конфигом CCcam невозможно в принципе. Объективные критерии качества источника, без привязки к конкретным именам и брендам: стабильное и предсказуемое время ответа ECM, минимальное число hop в цепочке, отсутствие циклических reconnect и «card removed» в логе, работоспособность именно в прайм-тайм — вечером, когда нагрузка на любой источник максимальна. Кстати, если фризы появляются только вечером, а днём всё чисто — это почти диагностический признак перегрузки источника или канала: число одновременных запросов в прайм-тайм растёт, время ответа ECM увеличивается и начинает вылезать за ваш таймаут. Проверить гипотезу просто: если у вас есть возможность временно подключиться к другому источнику с той же картой или подпиской, сравните логи бок о бок при одинаковых локальных условиях. Если новый источник даёт стабильное время ответа без циклов reconnect — вопрос закрыт, дело было не в вашем ресивере и не в вашей сети.

Пошаговый чек-лист: от симптома к решению за 20 минут

Собрал всё в единый порядок действий — просто идите по шагам сверху вниз, каждый следующий шаг зависит от результата предыдущего.

Шаги 1-3, изоляция: откройте FTA-канал на том же транспондере — если фризит и он, идите к сигналу и антенне, дальше не читайте. Переключитесь с Wi-Fi на Ethernet-кабель. Отключите все USB-устройства и таймшифт.

Шаги 4-6, логи: включите DEBUG 1 в /etc/CCcam.cfg и смотрите tail -f /tmp/cccam.log в момент фриза. Проверьте dmesg | tail -50 на признаки OOM или ошибок драйверов. Выполните free -m и оцените остаток свободной памяти.

Шаги 7-9, конфиг: измерьте RTT до сервера через ping -c 20 и пересчитайте ECM TIMEOUT как 3-4 RTT. Убедитесь, что запущен только один софткам — CCcam или OScam, не оба сразу. Проверьте архитектуру бинарника командой file /usr/bin/CCcam — на DM920 должен быть ARM.

Шаг 10, вывод: если после всех проверок FTA идеален, сеть стабильна, память в норме, демон не падает, а фризы всё равно есть и синхронны у всех каналов пакета — проблема на стороне источника, и это финальный диагноз.

Если чек-лист пройден полностью и локальная сторона чиста — вы честно закрыли вопрос dreambox 920 freezing every few minutes cccam fix своими силами, и дальнейшие действия лежат уже за пределами вашего ресивера.