CCcam: ошибка cannot decode — причины и решение

Если у вас в логах появилась строка с «cannot decode», а канал не открывается — это не значит, что линия упала. Соединение может быть зелёным, пинг нормальным, а картшеринг всё равно не работает. Ниже разберём, что именно происходит в цепочке расшифровки и как найти CCcam cannot decode решение без лишних перезагрузок и слепых правок конфига.

Что означает ошибка «cannot decode» в CCcam

ECM (Entitlement Control Message) — это зашифрованный запрос от ресивера, который нужно расшифровать картой и вернуть обратно как Control Word (CW). Без валидного CW декодер не может открыть видеопоток. «Cannot decode» означает ровно одно: сервер получил ECM, попытался его обработать, но валидного CW так и не вернул.

Цепочка выглядит так: ресивер → CCcam-клиент → C-линия (порт по умолчанию 12000) → ридер/карта → ответ CW → обратно на ресивер. Ошибка может возникнуть на любом звене после того, как соединение уже установлено.

Как выглядит сообщение в логе CCcam и OScam

В /var/log/cccam.log или /tmp/cccam.log типичная строка выглядит примерно так:

20260115 14:32:17 [EMAIL] cannot decode: CAID 0500 PROVID 032830 SID 1A2B

В OScam (/var/log/oscam.log) это выглядит иначе, но смысл тот же:

2026/01/15 14:32:17 c (ecm) user: CAID: 0500, provid: 032830, srvid: 1A2B -> no matching reader!

Или при таймауте:

2026/01/15 14:32:18 r [reader01] CAID 0500 ECM timeout after 3000ms

Разница между «cannot decode», «no card» и «no matching reader»

«No card» — ридер есть, но физической карты нет или она не отвечает. «No matching reader» — ридер с нужным CAID/provider не найден вообще, запрос некуда отправить. «Cannot decode» — ридер нашёлся, ECM туда пошёл, но CW в ответ не пришёл. Это три разных этапа, и путать их при диагностике — гарантированно потерять время.

На каком этапе ECM возникает сбой

Сбой бывает на стороне клиента (неверный CAID в маппинге), на уровне C-линии (hop слишком большой, источник перегружен), или на стороне источника (карта без подписки, пустой CW). Определить точку обрыва можно только по детальному логу — общих симптомов для этого недостаточно.

Основные причины «cannot decode» и как их проверить

Причин несколько, и они нередко комбинируются. Разберём каждую с конкретным шагом проверки.

Несовпадение CAID/Provider ID и SID канала

Самая частая причина. Канал переехал на другой транспондер или сменил SID, а конфиг остался старым. Либо карта покрывает один CAID, а запрос идёт на другой.

Проверить: в веб-интерфейсе OScam на порту 8888 (раздел Status → ECM) видно, какой CAID:provid:SID пришёл в запросе. Сравниваете с тем, что прописано в /etc/oscam/oscam.server в полях caid и ident. Если не совпадает — нашли причину.

Быстрая команда для проверки живого лога:

cat /var/log/oscam.log | grep ECM | tail -50

Превышение hop (расстояние до карты больше 1-2)

Hop — это количество прыжков от клиента до физической карты. Hop 1 означает прямое подключение к карте. Hop 3-4 — это уже несколько серверов в цепочке.

На сложных CAID — Nagra (1801, 1833), Viaccess (0500), Irdeto (0604) — hop больше 1 нестабилен. ECM time растёт, сервер не успевает вернуть CW до таймаута, и получаете cannot decode. В CCcam.cfg при добавлении C-линии можно видеть hop в логах после подключения. Если hop 3+ — это потенциальная проблема.

Карта без подписки или без нужного пакета

Карта может быть активна, но конкретный пакет не входит в подписку. Ридер принимает ECM, отправляет карте, а карта возвращает ошибку или пустой CW. В логе OScam это выглядит как decode failed или просто таймаут на уровне ридера.

Проверить: в oscam-статусе посмотреть, какие ident (provider ID) активны на ридере. Это видно в /etc/oscam/oscam.server в поле ident, и подтверждается в веб-интерфейсе через Services → Readers.

Проблема с AU/EMM и обновлением ключей

AU (Auto Update) — это механизм обновления ключей карты через EMM-сообщения. Если AU отключён или не работает, после смены ключей провайдером карта перестаёт декодировать новые ECM.

В /etc/oscam/oscam.server проверьте:

[reader]
label     = mycard
protocol  = internal
device    = /dev/sci0
caid      = 0500
ident     = 0500:032830
group     = 1
audisabled = 0

audisabled = 0 означает AU включён. Если стоит 1 — EMM не принимаются, ключи не обновляются. В логе OScam при работающем AU должны периодически мелькать строки с меткой EMM.

Неверный или повреждённый CW (00 00 00 00)

Иногда карта отвечает, но возвращает CW вида 00 00 00 00 00 00 00 00. Технически это не таймаут — ответ пришёл. Но нулевой CW не расшифровывает ничего. В таком случае проблема точно на стороне источника или карты, а не в вашем конфиге.

Пошаговая диагностика по логам

Без детального лога диагностика — это гадание. Вот как его включить правильно.

Включение детального лога (debug level)

Для CCcam: в /var/etc/CCcam.cfg или /etc/tuxbox/config/CCcam.cfg добавьте или измените:

DEBUG: 2

После перезапуска CCcam лог станет значительно подробнее. Файл обычно пишется в /tmp/cccam.log.

Для OScam: либо запуск с ключом отладки:

oscam -d 255 -l /var/log/oscam.log

Либо в /etc/oscam/oscam.conf в секции [global]:

[global]
logfile               = /var/log/oscam.log
loghistorysize        = 4096
nice                  = -1

Уровень -d 255 максимальный — пишет всё, включая каждый ECM/EMM. На продакшене лучше снизить до 64-128, иначе лог забьётся за пару минут.

Чтение ECM-запроса: CAID, provider, SID, ECM len

Строка ECM-запроса в OScam выглядит так:

2026/01/15 14:32:17 c [user01] (ecm) CAID: 0500, provid: 032830, srvid: 1A2B, ECMlen: 184

Поля: CAID — система шифрования (0500 = Viaccess, 0604 = Irdeto, 1801 = Nagra), provid — ID провайдера пакета, srvid — ID конкретного канала (SID), ECMlen — длина ECM-пакета. Если ECMlen нулевой или нестандартный — это уже подозрительно.

Определение, где обрывается цепочка

После строки ECM-запроса в логе должна идти строка с ответом ридера. Если следующая строка — таймаут или «no matching reader» — цепочка оборвалась до ридера. Если строка есть, но CW нулевой — проблема в самом ридере/карте.

Конфликт двух ридеров на один CAID — отдельная ловушка. OScam может отправить ECM на оба и использовать первый ответ. Если ридеры с разным приоритетом отдают разные CW (нестабильный источник) — получите периодический cannot decode. Проверяйте поле cccam-приоритет в oscam.server.

Проверка времени ответа (ECM time) и таймаутов

Норма ECM time — до 500 мс для локальной карты, до 1000 мс для удалённой. Всё, что выше 1500-2000 мс — нестабильно и периодически даст cannot decode, особенно в прайм-тайм, когда нагрузка на источник растёт.

В веб-интерфейсе OScam (порт 8888, раздел Readers) видно среднее ECM time для каждого ридера в реальном времени. Если цифра скачет от 200 мс до 3000 мс — источник перегружен.

Таймаут по умолчанию в OScam — 5000 мс (ctimeout в oscam.conf). Если ECM time стабильно около 4500 мс — сервер технически не превышает таймаут, но фактически работает на грани.

Решения для типовых сценариев

Итак, диагностику провели, причину нашли. Вот конкретные действия под каждый случай, здесь CCcam cannot decode решение — это не «перезагрузите», а конкретные строки конфига.

Исправление CCcam.cfg: правильный формат C-линии

Формат C-линии в /var/etc/CCcam.cfg:

C: hostname.example.com 12000 myuser mypassword

Порт 12000 — стандартный для протокола CCcam. Никаких лишних пробелов, никаких кавычек вокруг пароля. Если в конфиге есть старые закомментированные линии с символом #, убедитесь что активна только нужная.

После правки CCcam.cfg — обязательно проверьте, что нет строки с неверным CAID-маппингом типа:

IGNORE CAID: 0500

Такая строка молча блокирует все запросы для Viaccess.

Настройка ридера и AU в oscam.server

Пример рабочего блока ридера в /etc/oscam/oscam.server:

[reader]
label             = card_local
protocol          = internal
device            = /dev/sci0
caid              = 0500
ident             = 0500:032830,0500:032000
group             = 1
audisabled        = 0
ecmwhitelist      = 0500@032830:184

ecmwhitelist ограничивает допустимую длину ECM — это помогает отсечь мусорные запросы. group = 1 определяет приоритет ридера для пользователей OScam.

Ограничение hop и использование локальной карты приоритетом

В /etc/oscam/oscam.user для каждого пользователя можно ограничить максимальный hop:

[account]
user              = client01
pwd               = password
group             = 1
caid              = 0500
ident             = 0500:032830
maxhops           = 2

Параметр maxhops = 1 означает только локальная карта. Это самый надёжный вариант для проблемных CAID. Если нужен шеринг, но без длинных цепочек — ставьте maxhops = 2.

Перезапуск сервисов и очистка кэша CW

Перезапуск CCcam:

/etc/init.d/softcam restart
# или
killall -9 CCcam && CCcam &

Перезапуск OScam с очисткой:

oscam -r 2

Флаг -r 2 перезагружает конфиг без полного рестарта. Для полной очистки кэша CW нужен полный рестарт.

Критический момент — системное время. Неверное время на ресивере или сервере ломает обработку ECM и EMM на уровне протокола. Расхождение больше 30-60 секунд между сервером и источником линии — гарантированные проблемы с AU и периодические cannot decode. Проверьте NTP:

ntpd -qn -p pool.ntp.org
# или
date  # проверить текущее время

Когда проблема на стороне источника линии

Если конфиг проверен, hop минимальный, NTP настроен, CAID совпадает — а cannot decode сохраняется, проблема у источника. Признаки: ошибка только на части каналов того же пакета, CW нулевой в логе, ECM time нестабилен. В таком случае никакие правки локального конфига не помогут. Нужно либо ждать восстановления источника, либо менять линию.

Как выбрать стабильный источник линии (критерии)

Здесь не будет названий конкретных сервисов — их тысячи, качество меняется. Но критерии оценки вполне конкретные.

На что смотреть: uptime, реальный hop, локальные карты

Hop 1 — это локальная карта на сервере источника. Это идеал. ECM time стабильно низкий, нет промежуточных серверов, которые могут упасть. Hop 2 — допустимо. Hop 3 и выше — на сложных CAID это будут регулярные cannot decode в нагруженные часы.

Стабильный ECM time — ключевой параметр. Хороший источник даёт 100-400 мс стабильно. Если в тестовый период ECM time прыгает от 200 до 3000 мс — это не случайность, это характеристика источника.

Прозрачность по CAID и пакетам тоже важна. Источник должен чётко указывать, какие CAID и provider ID он покрывает. Если это не указано явно — узнать можно только из лога после подключения.

Признаки нестабильного источника

Cannot decode на части каналов одного пакета — верный признак того, что карта у источника не имеет полной подписки. Частые реконнекты (в логе CCcam строки «reconnect» чаще раза в час) — нестабильный сервер. Скачущий hop — источник использует несколько уровней шеринга, и цепочка нестабильна.

Периодический cannot decode строго в 20:00-23:00 — это перегрузка источника в прайм-тайм. Такой источник технически работает, но не тянет нагрузку. Для постоянного использования не подходит.

Тестовый период и проверка ECM time

Тестовый доступ на 24-48 часов — минимум для нормальной оценки. За это время мониторьте лог OScam, смотрите на ECM time через веб-интерфейс, проверяйте наличие cannot decode именно на нужных пакетах.

Смена ключей провайдером — отдельный тест. Если AU работает, после смены ключей cannot decode пропадёт за несколько минут (пока придут EMM). Если AU сломан или источник не передаёт EMM — после смены ключей канал не откроется до ручного обновления. Это стоит проверить отдельно.

Хороший CCcam cannot decode решение в выборе источника — это не найти «лучший сервер», а понять свои требования: нужные CAID, допустимый ECM time, важность AU — и выбирать по этим критериям с обязательным тестом.

Нетипичные случаи, которые часто пропускают

FTA-канал или частично кодированный — иногда ресивер шлёт ECM на канал, который вообще не требует расшифровки. В логе будет cannot decode, но проблемы нет — просто отключите картшеринг для этого SID или добавьте его в whitelist как незашифрованный.

Два клиента с разными F/C линиями на один ресивер — распространённая ситуация, когда один ресивер декодирует, а второй нет. Причина обычно в разных hop или разных правах на линии. Проверяйте параметры каждой линии отдельно, не копируйте конфиг между клиентами автоматически.

Канал сменил SID после переноса на другой транспондер — сканирование покажет новый SID, но старый конфиг продолжает слать ECM со старым SID, который источник больше не знает. Решение: пересканировать транспондер и обновить channel list.