NCam cannot decode: причины и решение (2026)
Если вы столкнулись с этой ошибкой — вы уже прошли половину пути. Базовая связь есть, reader отвечает connected, а каналы всё равно не открываются. Классическая ситуация. Ниже — конкретная диагностика, потому что NCam: cannot decode решение не одно, их несколько, и каждое зависит от звена, где рвётся цепочка. Разберём по порядку.
Что означает ошибка 'cannot decode' в NCam
NCam получил ECM-пакет от тюнера, отправил его на reader (локальный или сетевой), но в ответ либо не пришёл Control Word (CW), либо пришёл уже после того, как канал сменил ключ. Итог — кадр не расшифрован, вы видите чёрный экран или фриз.
Строка в логе выглядит примерно так:
2026/03/15 21:14:02 c (ecm) client XXXXXX CAID 0500 provid 042300 srvid 1234 ecmtime 4800 ms - cannot decodeЗдесь CAID 0500 — система кодирования, provid 042300 — идентификатор провайдера, srvid 1234 — ID канала, ecmtime 4800 ms — сколько прошло до ответа. Это именно та строка, с которой начинается любая диагностика.
Где в логах появляется сообщение и как его прочитать
По умолчанию лог пишется в /var/log/ncam.log. Путь можно переопределить в /etc/ncam/ncam.conf через параметр logfile = /путь/к/файлу. Там же задаётся cwlogdir — директория для записи Control Word отдельно от основного лога.
Смотреть лог в реальном времени удобно через tail -f /var/log/ncam.log | grep -i "cannot decode\|ecm\|cw". Так видно все ECM-запросы без лишнего шума.
Чем 'cannot decode' отличается от 'no matching reader' и 'ECM timeout'
no matching reader — NCam не нашёл ни одного reader под этот CAID/provid. Это проблема конфигурации, не сети. ECM timeout — reader нашёлся, запрос ушёл, но ответ не пришёл вообще в отведённое время. cannot decode — более широкое сообщение: включает и таймаут, и ситуацию, когда CW пришёл, но уже невалидный или опоздал. Разница важна для диагностики.
Какие уровни логирования включить для точной диагностики
В ncam.conf выставить debuglevel = 255 и logduplicatelines = 1. Это даст полный поток: видно, на какой reader уходит ECM, что вернулось, сколько миллисекунд заняло. Предупреждение: лог на 255 растёт быстро, после диагностики лучше вернуть на 64 или 128.
Проверка reader и совпадения CAID/provider
Самая частая тихая причина — несовпадение CAID или provid между тем, что запрашивает канал, и тем, что умеет обслуживать reader. NCam не кричит об этом явно, просто выдаёт cannot decode.
Берём строку ECM из лога (CAID и provid), открываем /etc/ncam/ncam.server и смотрим настройки нужного reader:
[reader]
label = my_cccam_reader
protocol = cccam
device = 192.168.1.100,12000
caid = 0500,1830
ident = 0500:042300,042400
group = 1Если provid канала — 042500, а в ident его нет — дешифровка не пройдёт. Добавляем нужный provid и перезапускаем reader через webif или killall -HUP ncam.
Сверка CAID и provid канала с тем, что отдаёт reader
Смотрим ECM-строку: CAID 098C provid 000000. Идём в ncam.server, ищем reader с caid = 098C. Если его нет вообще — это no matching reader, а не cannot decode. Если reader есть, но ident = не покрывает provid — вот ваша причина.
Для CAID 0500 (Viaccess) provid очень важен — разные пакеты у одного оператора имеют разные ident. Для CAID 1830 (Nagravision) ident часто оставляют пустым, и это нормально.
Настройка ident, caid, services в ncam.server
Параметр services в ncam.server позволяет привязать reader к конкретному списку каналов из /etc/ncam/ncam.services. Если services заданы и нужного SID там нет — reader проигнорирует запрос без единого сообщения об ошибке. Классическая невидимая ловушка.
Также проверьте group у reader и у account клиента. Reader с group = 1 обслуживает только тех клиентов, у которых group = 1 тоже прописан. Несовпадение group — одна из самых частых причин cannot decode, которую игнорируют другие инструкции.
Проверка через веб-интерфейс и раздел Readers/ECM
Webif по умолчанию на порту 8888: http://ip-адрес:8888. В разделе Readers видно колонки: decoded / not found / cache / ratio. Если ratio низкий (ниже 80%), при наличии подключённого reader — это верный путь, но неверный CW или ident. Если decoded = 0 при нескольких запросах — смотрим group и ident.
Раздел ECM в реальном времени показывает, куда конкретно ушёл каждый запрос. Там же видно время ответа в миллисекундах. Это самый быстрый способ понять, на каком reader висит проблема.
Команда проверки активных reader и группы
Через webif: Status → Readers. Через лог: искать строки вида reader activated или reader not activated при старте NCam. Также помогает grep "group" /etc/ncam/ncam.server и сравнение с grep "group" /etc/ncam/ncam.user — должны пересекаться.
Сетевые причины: таймауты ECM, фриз и нестабильный источник
Даже правильно настроенный reader даёт cannot decode, если CW возвращается слишком поздно. У каждого провайдера своё окно смены ключа — обычно несколько секунд, и если ответ не укладывается в это окно, кадр уже не расшифровать.
Проверить ping до сервера: ping -c 20 ip-адрес-reader. Если средний ping выше 150–200 мс или есть потери пакетов — CW будет опаздывать на перегруженных мультиплексах. NCam: cannot decode решение в этом случае начинается не с настроек, а с выбора более близкого по пингу источника.
Параметры ecmwt, lb_max_ecmcount, lb_reopen_seconds и нагрузка load balancing
В ncam.conf:
[global]
ecmwt = 2000
lb_mode = 1
lb_max_ecmcount = 10
lb_reopen_seconds = 120
lb_nbest_readers = 2ecmwt задаёт, сколько миллисекунд NCam ждёт CW перед тем, как списать попытку. Значение должно быть меньше реального окна смены ключа провайдера, но больше вашего реального времени ответа. Ориентир: реальный ping × 3–4 + запас 200 мс.
lb_nbest_readers = 2 — load balancer пробует два лучших reader параллельно. Помогает при нестабильных соединениях, но увеличивает нагрузку на сервер-источник. lb_reopen_seconds — как долго reader считается "нерабочим" после серии ошибок, прежде чем NCam попробует его снова.
Влияние пинга и потерь пакетов между клиентом и сервером
Прайм-тайм — отдельная история. В вечернее время число клиентов на сервере-источнике растёт, очередь ECM-запросов увеличивается, время ответа CW прыгает с 300 мс до 1500–2000 мс и выше. То, что работало в 14:00, в 21:00 начинает давать cannot decode именно по этой причине.
Диагностика: смотреть ecmtime в логе в разное время суток. Если в off-peak оно 200–400 мс, а в prime-time улетает за 1500 — проблема в перегруженном источнике, не в вашей конфигурации.
Проверка протокола и версии
Для CCcam-reader в ncam.server проверить cccversion = 2.3.2 (или актуальную). Устаревшая версия протокола иногда даёт ошибки при обмене CW. Для newcamd — порты обычно из диапазона 12000–12010, и обязательно проверить DES-ключ: 14 байт hex в параметре key =. Неверный DES-ключ даёт картину "connected, но cannot decode" — соединение есть, а расшифровка нет.
cs378x (Camd35 over TCP) работает на других портах и требует отдельного пароля. Если смешать протоколы при копировании конфига — получите именно эту ошибку.
Дублирующиеся reader и hop-петли как причина битых CW
Если ваш NCam-сервер одновременно является клиентом самого себя через цепочку посредников — ECM уходит по кругу и возвращается битый CW или не возвращается вовсе. В логе это выглядит как серия cannot decode без видимой причины при нормальном ping.
Проверить: в webif раздел Readers → Hops. Значение hop для каждого reader показывает глубину цепочки. Если видите hop = 5+ на reader, который должен быть прямым — скорее всего петля. Решение: убрать дублирующийся reader или явно ограничить максимальный hop через ccchop = 2.
Локальная карта, эмуляция и шифрование канала
Отдельный случай — когда источник не сетевой, а локальный. Смарткарта или эмулятор дают cannot decode по другим причинам, и диагностика там отличается.
Проверка локального reader через смарткарту
В ncam.server для физического reader:
[reader]
label = local_card
protocol = mouse
device = /dev/sci0
caid = 0500
group = 1Устройства sci0 и sci1 — встроенные картридеры на ресиверах. На Linux-серверах это обычно /dev/ttyUSB0 или /dev/ttyS0 с внешним ридером. Если устройство не определяется — ls -la /dev/sci* или dmesg | grep tty. Без правильного device физическая карта недоступна независимо от любых других настроек.
Когда нужен эмулятор и ограничения встроенной эмуляции
NCam поддерживает встроенную эмуляцию через protocol = constcw или через внешние ключи в SoftCam.Key. Но эмуляция работает только для конкретных систем: BISS, Tandberg, PowerVU, частично Irdeto и Nagravision в режиме фиксированных ключей. Для Viaccess (0500), Conax (0B00) и живых Nagravision — нужна реальная карта или сетевой reader.
Если CAID требует живой авторизации на сервере оператора — никакой эмулятор не поможет. Cannot decode в этом случае — ожидаемый результат.
BISS, Tandberg, PowerVU и форматы ключей
Для BISS строка в SoftCam.Key выглядит так:
F 0D 00 01 23 45 67 89 AB CD EF 01 23 45 67 89 ABКлюч — ровно 8 байт (16 hex-символов после пространства под тип). Если длина неверная — NCam молча не применяет ключ и выдаёт cannot decode. Для PowerVU формат другой, и там важна привязка к srvid (ID канала), не только к CAID.
Tandberg (CAID 1010) использует статичные ключи в формате F 1010 ключ, привязанные к частоте или transponder ID. Если транспондер сменился — ключ уже не подойдёт.
Обновление SoftCam.Key и совпадение длины ключа
Файл ключей лежит обычно в /etc/ncam/SoftCam.Key или по пути, заданному в ncam.conf через softcamfile =. После обновления файла NCam нужно перечитать его — либо через webif (кнопка Reload softcam), либо killall -USR1 ncam.
Если канал сменил ключ (BISS rekey — стандартная практика перед крупными трансляциями), а SoftCam.Key не обновлён — cannot decode гарантирован до обновления. Это не баг NCam, а устаревший ключ.
Пошаговый чек-лист устранения 'cannot decode'
Здесь собрано всё вышесказанное в воспроизводимый порядок. NCam: cannot decode решение находится быстро, если идти по этой цепочке, а не гадать.
Алгоритм диагностики от ECM до CW за 7 шагов
- Включить debug 255 в ncam.conf, перезапустить NCam, открыть нужный канал и поймать строку ECM с CAID, provid, srvid и ecmtime.
- Определить путь дешифровки: смотреть в логе, куда ушёл запрос — на local/sci, на сетевой reader или на эмулятор (constcw).
- Сверить CAID и ident: открыть ncam.server, найти reader, проверить совпадение caid, ident (provid), и group с group клиента.
- Проверить таймаут: ecmtime в логе — если выше 1500 мс стабильно, проблема в задержке. Проверить ping до источника.
- Для локальной карты/эмулятора: проверить device, наличие SoftCam.Key, длину и актуальность ключей.
- Исключить петли: проверить hop в webif, убрать дублирующиеся reader на одном CAID.
- Подтвердить по webif: открыть порт 8888, раздел Readers — смотреть decoded/ratio в течение 3–5 минут на нескольких каналах.
Что проверять в первую очередь по типу источника
Сетевой reader (CCcam/newcamd/cs378x): начать с group и ident, потом смотреть ping и ecmtime. Для newcamd — дополнительно DES-ключ и номер порта.
Локальная смарткарта: проверить device (/dev/sci0), что карта вставлена и определяется (grep sci /var/log/ncam.log | head -20). Потом CAID карты против запрашиваемого.
Эмулятор/SoftCam.Key: актуальность ключа, длина (особенно для BISS), правильный формат строки, путь к файлу в ncam.conf.
Как зафиксировать, что проблема решена
Критерий успеха — не "один канал открылся". В webif раздел ECM History или Readers: наблюдать decoded без всплесков cannot decode в течение 5–10 минут, переключить 3–4 канала на разных CAID. Если ratio decoded держится выше 95% и фризов при переключении нет — NCam: cannot decode решение найдено и применено.
Также проверить лог: grep "cannot decode" /var/log/ncam.log | tail -50 — если строки перестали появляться после изменений, всё работает.
Частые вопросы
Почему NCam пишет 'cannot decode', хотя reader подключён и status = connected?
Connected означает только успешную сетевую авторизацию на сервере-источнике. Дешифровка — это следующий шаг, и он может упасть из-за несовпадения CAID или provid, неверного ident, несовпадения group между reader и account, опоздания CW или неправильного ключа. Статус connected не гарантирует, что этот reader умеет работать именно с нужным вам CAID и provid. Смотреть нужно строку ECM в логе, а не статус соединения.
Как отличить проблему сети от проблемы карты при ошибке cannot decode?
В логе с debug 255 видно, куда именно ушёл ECM-запрос. Строка sending to reader: my_cccam_reader и потом cannot decode — это сеть или таймаут. Строка sending to reader: local_card и cannot decode — проблема в физической карте, ключе или эмуляции. Ещё один способ: в webif → Readers смотреть колонку "decode source" для последних ECM — там явно указано, откуда пришёл (или не пришёл) ответ.
Какие значения ECM timeout ставить, чтобы убрать фризы и cannot decode?
Нет универсального числа — всё зависит от реального ping до источника. Логика такая: измерить средний ping (ping -c 20), умножить на 4–5 и добавить 200 мс запаса. Если ping 50 мс, то ecmwt около 400–500 мс разумен. Завышенный таймаут (например 5000 мс) не решает проблему — он только маскирует опоздание, и вы получаете фриз вместо чёрного экрана. Оптимально: ecmwt чуть меньше реального окна смены ключа провайдера, которое обычно составляет 2–10 секунд в зависимости от системы.
Cannot decode только на каналах BISS — что не так?
В 90% случаев — неверный или устаревший ключ в SoftCam.Key, либо ключ правильный, но неправильной длины. BISS требует ровно 8 байт (16 hex-символов). Иногда ключи публикуются в сокращённом виде — убедитесь, что вы используете полный. Также проверьте привязку: ключ должен соответствовать правильному CAID (обычно 2600) и srvid канала. После обновления файла не забыть перезагрузить его через webif или сигнал USR1.
Помогает ли смена протокола с CCcam на newcamd при cannot decode?
Иногда да, но не само по себе. CCcam с многоуровневыми hop'ами накапливает задержку и иногда передаёт битые CW. Newcamd с прямым подключением убирает hop-проблему. Но если причина cannot decode — несовпадение CAID или устаревший ключ, смена протокола ничего не даст. При переходе на newcamd обязательно проверить: номер порта (диапазон 12000+), DES-ключ (14 байт hex) и то, что сервер вообще поддерживает этот протокол. Неверный DES-ключ — типичная причина "connected, но cannot decode" именно для newcamd.
Как понять, что ошибка ушла, а не временно пропала?
Временное исчезновение cannot decode — обманчивый признак. Смотреть нужно на ratio в webif (раздел Readers) в течение 5–10 минут при активном просмотре нескольких каналов на разных CAID. Стабильный decoded выше 95%, отсутствие всплесков cannot decode в логе при переключении каналов и нормальное ecmtime (без скачков в прайм-тайм) — вот три признака того, что проблема реально решена, а не просто затихла.