Настройка локальных каналов через CCcam: полный гайд

Если ты уже поднял CCcam и подключил C-line от поставщика, но местная карта почему-то молчит — ты по адресу. Локальные каналы через cccam настройка — это отдельная история, которую большинство туториалов просто пропускают. Здесь я разберу именно конфликт приоритетов: почему карта в ридере проигрывает удалённому пиру, и как это починить на уровне конфигов, а не перезагрузками вслепую.

Что значит «локальные каналы» в CCcam и почему они конфликтуют с share

Локальный ридер против удалённых пиров

В терминологии CCcam есть чёткое разделение: локальный ридер — это физическая смарт-карта в картридере ресивера (или эмулятор типа SoftCam), а удалённый пир — это C-line, подключённая к чужому серверу по сети. Оба источника могут отвечать на один и тот же ECM-запрос (зашифрованный сигнал канала), и вот тут начинается проблема.

CCcam отправляет запрос всем доступным источникам одновременно и берёт тот ответ, который пришёл первым. Локальная карта на Enigma2-ресивере отвечает за 50–150 мс. Хороший удалённый пир с пингом 20 мс и быстрым сервером — за 30–80 мс. В итоге доля ECM-ответов уходит на share, хотя карта сидит прямо в слоте ресивера.

Как CCcam выбирает источник по CAID и provider ID

Три параметра определяют, кто обслуживает канал:

• CAID (Conditional Access ID) — идентификатор системы шифрования. Например, Viaccess — 0x0500, Nagravision — 0x1800, Irdeto — 0x0600. Это грубый фильтр.
• Provider ID (ident) — уточняет оператора внутри системы шифрования. Два оператора могут использовать один CAID, но разные ident.
• SID (Service ID) — конкретный канал. Самый точный уровень привязки.

По умолчанию CCcam не знает, что ты хочешь обслуживать конкретный CAID локально. Он просто выбирает наименьшую задержку ECM. Без явного файла приоритетов локальная карта будет проигрывать нормально настроенному share-серверу регулярно.

Зачем разделять локальные и share-каналы

Карта декодирует только то, на что у неё подписка. Share-линии закрывают остальное. Если принудительно погнать запрос локальной карты на remote peer, получишь или отказ, или фриз. Обратное — карта с нужной подпиской, которую CCcam отдаёт на пир — работает, но увеличивает нагрузку на карту и нарушает логику share. Разделение нужно не только для качества картинки, но и для стабильности всей системы.

Настройка локальной карты в CCcam.cfg (приоритеты и ident)

Основной конфиг лежит в /var/etc/CCcam.cfg на большинстве Enigma2-сборок (OpenPLi, OpenATV, VTi). На старых ресиверах Dreambox путь может быть /etc/CCcam.cfg, на некоторых прошивках — /usr/keys/CCcam.cfg. Всегда проверяй init-скрипт запуска: cat /etc/init.d/CCcam — там прописан точный путь.

Параметр PRIO и файл CCcam.prio

Файл CCcam.prio — главный инструмент управления приоритетами. Он лежит рядом с основным конфигом: /var/etc/CCcam.prio. Синтаксис строки:

caid:provid:sid:priority

Где priority — числовой порядок (меньше = выше приоритет). Пример: хочешь, чтобы локальная карта с CAID 0x0500 и ident 040810 обслуживала все каналы этого пакета первой:

0500:040810:0000:0

Здесь 0000 в поле SID означает «все каналы с этим CAID:ident». Локальный ридер в CCcam получает приоритет 0 по умолчанию при правильной записи в prio-файле. Удалённые C-line без записи в prio-файле получают более низкий приоритет.

Чтобы CCcam вообще читал файл приоритетов, в CCcam.cfg должна быть строка:

PRIO FILE : /var/etc/CCcam.prio

Привязка CAID:ident к локальному ридеру

Если у локальной карты и удалённого пира одинаковый CAID, но разный provider ID — это твой спасательный круг. Допустим, карта работает с ident 040810, а пир отдаёт тот же CAID с ident 040820. Записи в prio-файле:

0500:040810:0000:0
0500:040820:0000:1

Первая строка — локальная карта идёт первой для её ident. Вторая — share-пир подхватывает свой ident на уровень ниже. Это работает чисто и без конфликтов.

Хуже, когда ident совпадает полностью. Тогда нужно спускаться до уровня SID. Найди SID каналов, которые должна декодировать карта (в логе CCcam он виден как шестнадцатеричное число рядом с именем канала), и пропиши явно:

0500:040810:2B66:0
0500:040810:2B67:0

Параметр F-line и локальный доступ

F-line в CCcam.cfg — это не то же самое, что C-line. F-line открывает доступ к твоему серверу для других клиентов:

F: username password 1 0 0 0 0 { 0:0:1 }

Последний блок { 0:0:1 } — это разрешённые CAID для этого пользователя. Для локального ридера F-line не нужен — он работает напрямую через внутренний протокол CCcam. Путаница здесь — частая ошибка новичков.

Где лежат конфиги: /var/etc/, /etc/, /usr/keys/

Быстрая шпаргалка по путям в зависимости от прошивки:

Прошивка	Путь к CCcam.cfg	Путь к CCcam.prio
OpenPLi / OpenATV	/var/etc/CCcam.cfg	/var/etc/CCcam.prio
VTi	/var/etc/CCcam.cfg	/var/etc/CCcam.prio
Dreambox DM800/DM8000	/etc/CCcam.cfg	/etc/CCcam.prio
Старые прошивки	/usr/keys/CCcam.cfg	/usr/keys/CCcam.prio

Если после перезагрузки ресивера приоритеты сбрасываются — почти наверняка CCcam читает конфиг из другого пути, чем ты редактируешь. Проверь командой: ps aux | grep CCcam — в строке запуска виден аргумент с путём к конфигу.

Альтернатива на OScam: dvbapi, reader и приоритеты oscam.dvbapi

OScam даёт точнее контроль над приоритетами, чем CCcam.prio. Если тебя раздражает, что CCcam периодически игнорирует твои настройки приоритетов — переход на OScam для управления локальным ридером реально решает проблему.

Файл oscam.server: local reader и protocol

Блок локального ридера в /etc/oscam/oscam.server:

[reader]
label     = local_card
protocol  = internal
device    = /dev/sci0
caid      = 0500
detect    = cd
mhz       = 357
cardmhz   = 357
group     = 1
emmcache  = 1

protocol = internal — для встроенного картридера Enigma2. Для внешнего USB-ридера используй protocol = mouse и device = /dev/ttyUSB0. Параметр group = 1 — важен, он связывает ридер с правилами в других конфигах.

Если OScam должен подключаться к CCcam как клиент (например, CCcam держит share, а OScam — локальную карту), добавляется отдельный reader с protocol = cccam:

[reader]
label     = cccam_share
protocol  = cccam
device    = 127.0.0.1,12000
user      = localuser
password  = localpass
caid      = 1800,0600
group     = 2

Файл oscam.dvbapi: правила P: и I:

Файл /etc/oscam/oscam.dvbapi управляет, что декодировать и через какой ридер. Синтаксис:

P: caid:provid:sid
I: caid:provid:sid

P: — Priority, I: — Ignore. Порядок строк имеет значение — OScam читает их сверху вниз и применяет первое совпавшее правило. Пример настройки, где карта декодирует свой пакет, а share закрывает остальное:

P: 0500:040810:0000
P: 0500:040810:2B66
I: 0500:040820:0000
A: 1800:000000:0000

Строка A: — Accept, разрешает декодирование через любой доступный ридер. Без неё OScam может вообще не пытаться декодировать канал.

Кейс с симулькриптом — когда канал шифруется одновременно несколькими системами (например, 0500 + 0600) — отдельная головная боль. OScam попробует каждый CAID по порядку правил dvbapi. Если приоритет задан только для 0500, но карта не поддерживает 0600, второй CAID уйдёт на share даже если ты этого не хотел. Решение — явно прописать I: для ненужных CAID-систем на уровне группы ридеров.

Связка OScam как локальный ридер + CCcam как share-протокол

Это рабочая схема для многих: OScam держит физическую карту и управляет приоритетами, CCcam обеспечивает share через C-line. Связь между ними идёт через loopback.

В /etc/oscam/oscam.conf включи встроенный CCcam-сервер:

[newcamd]
; не нужен, если используешь только CCcam

[cccam]
port = 16000

Тогда CCcam-клиент (или сам CCcam на ресивере) подключается к OScam на порт 16000 для получения ECM с локальной карты. CCcam отдаёт share-ответы от внешних C-line. В итоге OScam решает, что декодировать локально, и только то, что не умеет карта, улетает во внешний share.

Проверка через веб-интерфейс :8888

OScam поднимает веб-статус на порту, заданном в oscam.conf:

[webif]
httpport  = 8888
httpuser  = admin
httppwd   = admin

Открываешь http://<ip-ресивера>:8888 и видишь в реальном времени: какой ридер обработал последний ECM, сколько миллисекунд занял ответ, из какой группы. Раздел ECM history — незаменимая вещь при отладке. Если там написано reader: cccam_share для канала, который должна декодировать локальная карта, — идёшь в dvbapi и исправляешь приоритет.

Диагностика: почему локальный канал всё равно идёт через share

Чтение лога CCcam (tail -f /var/log/CCcam.log)

Первый инструмент — лог в реальном времени:

tail -f /var/log/CCcam.log | grep -i "ecm"

На OpenPLi лог может лежать в /tmp/CCcam.log. Чтобы включить подробный лог, в CCcam.cfg добавь:

DEBUG : 1

После перезапуска (/etc/init.d/CCcam restart) лог начнёт показывать каждый ECM-запрос.

Определение источника ECM по строке лога

Типичная строка лога CCcam выглядит так:

ECM caid:0500 prov:040810 sid:2B66 -> found (time: 87ms) from reader[local_card]

или

ECM caid:0500 prov:040810 sid:2B66 -> found (time: 32ms) from peer[user@server:12000]

Если в строке написано from peer для канала, который должна декодировать карта — приоритет не работает. Обрати внимание на время: 32 мс против 87 мс. CCcam без prio-файла возьмёт пир, потому что он ответил быстрее. Именно это и ломает логику локального декодирования.

Проблема дублирующихся CAID у карты и пира

Это самый частый кейс. Локальная карта имеет CAID 0500, удалённый пир — тоже CAID 0500. CCcam видит два источника с одинаковым CAID и выбирает по скорости ответа. Здесь одного файла CCcam.prio с записью на уровне CAID недостаточно — нужно спускаться до ident или SID.

Как найти ident карты: посмотри в веб-интерфейсе CCcam (порт 16001) раздел Cards — там показаны все CAID и provider ID, которые видит CCcam от каждого источника. Или используй команду:

grep -i "local\|card\|reader" /var/log/CCcam.log | head -50

FTA-каналы и пустой ECM

FTA (Free To Air) — незашифрованные каналы. Они не отправляют ECM вообще, и CCcam их не трогает. Если ты ждёшь, что CCcam «декодирует» FTA-канал, а он просто не показывает — дело не в конфигурации share. Дело в том, что канал не требует декодирования. Проверяй через transponder info в ресивере: если Encryption: None — это FTA.

Проблема в другом: иногда канал физически FTA, но ресивер ошибочно помечает его как зашифрованный из-за неверного SI (Service Information) в потоке. В логе CCcam будет бесконечная очередь ECM без ответов. Решение — добавить SID канала в список игнорируемых через CCcam.prio или oscam.dvbapi с директивой I:.

Ещё один нюрс с несколькими тюнерами: если на ресивере два DVB-адаптера (/dev/dvb/adapter0 и adapter1), oscam.dvbapi применяет правила ко всем адаптерам по умолчанию. Но если хочешь разделить политику по адаптерам — используй директиву [dvbapi] с параметром boxtype и настраивай приоритеты отдельно. Без этого правило P: может применяться к не тому тюнеру.

Как выбрать поставщика share для остальных каналов (общие критерии)

Локальные каналы через cccam настройка — это только половина задачи. Остальные каналы, которые карта не покрывает, нужно закрыть через внешний share. И здесь качество C-line имеет прямое влияние на стабильность всей схемы.

Стабильность и аптайм линий

Главное — не пинг, а стабильность. C-line с пингом 80 мс, но без дропов лучше, чем линия с 20 мс и ежедневными обрывами. Смотри в лог CCcam: если видишь частые строки lost connection to peer или ECM timeout — линия нестабильна. Нормальный показатель: не более 1–2 дропов в сутки при стабильном интернете на твоей стороне.

Локальность серверов и пинг

Для декодирования в реальном времени критичен суммарный RTT между ресивером и share-сервером. ECM должен уйти и вернуться за время до следующего crypto period — обычно это 10 секунд, но у некоторых операторов crypto period сокращён до 2–5 секунд. При пинге выше 200–300 мс начинаются фризы. Проверяй командой:

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

Важен не только средний пинг, но и джиттер (разброс). Если min 20 мс, max 350 мс — это плохая линия даже со средним 60 мс.

Поддержка нужных CAID и протоколов

Перед подключением убедись, что поставщик поддерживает именно твои CAID. Если нужен Nagravision 1800 для определённого спутника — спрашивай конкретно. «Поддерживаем всё» — это не ответ. Хороший поставщик скажет точно: CAID 1800, ident 000000, спутник такой-то.

Протокол: CCcam 2.1.x или 2.3.x — уточняй совместимость. Некоторые сервера работают только со старой версией протокола, и если у тебя новая прошивка с другой версией CCcam — могут быть проблемы рукопожатия.

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

На что смотреть в логе CCcam при проблемном share:

• Строки ECM time: 4500ms и выше — сервер перегружен или связь плохая
• Частые card not found — сервер не держит нужную карту постоянно
• Цикличный реконнект каждые 30–60 секунд — нестабильное соединение
• Фризы ровно каждые N минут — crypto period истекает раньше, чем приходит новый CW

Хороший признак стабильной линии: время ECM в логе стабильно 30–100 мс без выбросов, нет потерянных соединений за несколько часов работы. Тестируй минимум 24–48 часов перед тем, как принимать окончательное решение о качестве линии. Локальные каналы через cccam настройка требует понимания, что нестабильный share влияет и на локальный ридер — перегруженный CCcam начинает замедлять обработку всех ECM-очередей.