CCcam vs OScam: что выбрать и как настроить бесплатно

Если вы уже разбирались с ресивером на Enigma2 и дошли до вопроса cccam vs oscam бесплатно — это хорошо. Значит, маркетинговую шелуху вы уже отмели и хотите понять, что реально работает. Коротко: оба эмулятора бесплатны, но это разные инструменты с разной философией, и выбор зависит от того, что именно вы строите.

Я прошёл через обе конфигурации на нескольких образах — OpenATV 7.4, OpenPLi 9.x и VTI — и ниже расскажу, что нашёл на практике, без воды.

CCcam и OScam: ключевые отличия простыми словами

Главное, что надо понять сразу: CCcam — закрытый проприетарный эмулятор, последняя активная ветка 2.x.x уже несколько лет не получает обновлений. OScam — открытый проект, исходники на GitHub, сообщество коммитит патчи регулярно. Это не просто маркетинговое различие — это влияет на то, что вы можете с ними делать.

И да, на вопрос «cccam vs oscam бесплатно» ответ один: оба эмулятора распространяются бесплатно. Деньги берут только за источники — легальные подписки у операторов. Сам бинарник не стоит ничего, и это не изменится.

Что такое CCcam и его протокол

CCcam — это одновременно и программа, и протокол. Протокол CCcam описывает, как клиент запрашивает ECM у сервера-источника, как передаются CW (control words) и как аутентифицируются соединения. Протокол закрытый, но давно реверс-инжинирован. Именно поэтому OScam его понимает, а не наоборот.

Демон CCcam слушает входящие подключения по протоколу CCcam — обычно на порту 12000, но это конфигурируется вручную. Конфиг один: /var/etc/CCcam.cfg на Enigma2. Никакого веб-интерфейса, никакой статистики. Работает — и ладно.

Что такое OScam и почему он открытый

OScam (Open Source Conditional Access Module) поддерживает не один, а несколько протоколов: cccam, newcamd, camd35, mgcamd, constcw. Можно одновременно принимать соединения по разным протоколам и раздавать через разные порты. Конфигурация разбита на несколько файлов: oscam.conf, oscam.server, oscam.user, oscam.services, oscam.dvbapi.

Открытый код означает, что баги фиксятся, а не ждут патча от закрытого вендора. На практике это важно, когда источник начинает слать нестандартные ответы или меняет поведение при таймаутах.

Сравнительная таблица: лицензия, обновления, гибкость

Параметр	CCcam	OScam
Лицензия	Проприетарный, закрытый код	Open source (GPL)
Последнее обновление	Ветка 2.x.x, обновлений нет	Активные коммиты в 2026
Поддерживаемые протоколы	Только CCcam	CCcam, newcamd, camd35, mgcamd и другие
Веб-интерфейс	Нет	Да, порт 8888 по умолчанию
Логирование ECM	Минимальное	Подробные метрики ECM time
Цена	Бесплатно	Бесплатно

Производительность и стабильность: что важнее для сервера

Вот где начинается реальное сравнение, а не пересказ фич-листов.

Скорость декодирования и время отклика ECM

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

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

Нагрузка на CPU и потребление памяти на слабом железе

Это та часть, где CCcam иногда выигрывает. На совсем старых ресиверах — Dreambox DM800, VU+ Solo с 256 МБ ОЗУ — OScam с десятком активных ридеров и включённым webif может потреблять заметно больше памяти. CCcam в базовой конфигурации проще архитектурно и потребляет меньше.

Но: если ОЗУ не хватает, OScam упадёт с понятным сообщением в логе. CCcam просто зависнет или перестанет отвечать на ECM — без внятной диагностики. Выбирайте своё приключение.

Поведение при множественных подключениях (reader/account)

OScam позволяет точно управлять ридерами через group и services в oscam.server — можно направить конкретные CAID/SID через конкретный ридер. CCcam такой маршрутизации не умеет: он идёт по первому доступному источнику. При нескольких источниках с перекрывающимися пакетами это может привести к неоптимальным запросам и ненужной нагрузке на ридеры.

Настройка CCcam: конфиг, порты и подключение

Конфигурация CCcam — это один файл. Плюс в простоте, минус в том, что больше ничего и не настроишь.

Структура файла /var/etc/CCcam.cfg

На Enigma2-образах (OpenATV, OpenPLi, VTI) файл лежит по пути /var/etc/CCcam.cfg. Иногда встречается /etc/CCcam.cfg — зависит от сборки и плагина. Основные директивы выглядят так:

SERVER LISTEN PORT : 12000
ALLOW TELNET : yes
NEWCAMD LISTEN PORT : 0
GLOBAL LIST : 1
SHARE INDENT : 0
DEBUG : 0

После правки файла нужно перезапустить демон: /etc/init.d/CCcam restart или через меню плагинов. Права на файл должны быть 644, иначе CCcam его не прочитает — и вы увидите пустой экран без каких-либо сообщений об ошибке.

Строка C-line: формат host port user pass

Клиентская строка для подключения к источнику:

C: hostname.example.com 12000 myusername mypassword

Здесь C: — это тип строки (Client), затем хост, порт (стандартный 12000, но источник может использовать любой), логин и пароль. Никаких лишних пробелов и невидимых символов — CCcam к этому чувствителен. Если редактировали файл в Windows и сохранили с CRLF-переносами, CCcam тихо проигнорирует строку.

Раздача F-line и параметры лимитов

Если ваш ресивер сам является раздающим сервером, нужны F-lines — строки для клиентов:

F: clientlogin clientpassword 1 0 0 0 { 001:000000 }

Формат: F: user pass reshare downhop uphop deskey { CAID:PROVID }. Параметр reshare определяет, на сколько уровней клиент может переотдавать карту дальше. Для большинства случаев ставят 0 или 1.

Настройка OScam: oscam.server, oscam.user и webif

Здесь конфигурация разнесена по файлам — это сначала раздражает, но потом начинаешь ценить, когда нужно менять одного ридера, не трогая остальное.

Файлы конфигурации в /etc/tuxbox/config/ или /var/etc/oscam/

Пути зависят от образа и сборки OScam. На OpenATV и OpenPLi чаще всего это /etc/tuxbox/config/oscam/. На некоторых VTI-сборках файлы лежат в /var/etc/ с префиксом: /var/etc/oscam.conf, /var/etc/oscam.server и т.д. Проверить можно командой:

find / -name "oscam.conf" 2>/dev/null

Если OScam не стартует — первым делом проверяйте права. Файлы должны быть доступны на чтение пользователю, под которым запущен демон. Типичная причина проблем: файл создан под root, а OScam запускается под oscam. Команда chown oscam:oscam /etc/tuxbox/config/oscam/* решает это.

Секция [reader] в oscam.server для источников

Чтобы OScam подключился к CCcam-источнику, в oscam.server нужна такая секция:

[reader]
label        = my_cccam_source
protocol     = cccam
device        = hostname.example.com,12000
user          = myusername
password      = mypassword
group         = 1
reconnecttimeout = 30
cccversion    = 2.0.11

Параметр cccversion иногда важен — некоторые источники проверяют версию клиента и отвергают соединение при несоответствии. Попробуйте 2.0.11, 2.1.4 или 2.3.0 если первый вариант не проходит.

Секция account в oscam.user и доступ через webif

Аккаунты для клиентов описываются в oscam.user:

[account]
user          = clientlogin
pwd           = clientpassword
group         = 1
au            = 1

Webif включается в основном конфиге oscam.conf:

[webif]
httpport      = 8888
httpuser      = admin
httppwd       = yourpassword
httprefresh   = 10

После перезапуска демона веб-интерфейс будет доступен по адресу http://IP_ресивера:8888. Если недоступен — проверьте, не занят ли порт 8888 другим сервисом (netstat -tlnp | grep 8888) и не закрыт ли он фаерволом (iptables -L).

Для локального декодирования на ресивере нужна секция в oscam.dvbapi:

[dvbapi]
enabled       = 1
au            = 1
pmt_mode      = 0
request_mode  = 0

Что выбрать: CCcam, OScam или оба сразу

Вопрос cccam vs oscam бесплатно не имеет универсального ответа — зависит от сценария. Вот три конкретных случая.

Сценарий: простой клиент на одном ресивере

Один ресивер, один источник, хочется просто смотреть — CCcam справится. Редактируете /var/etc/CCcam.cfg, вставляете C-line, перезапускаете. Работает. Никаких лишних файлов, никакого webif, ничего сложного.

Но если источник внезапно перестаёт отвечать или картинка зависает раз в несколько часов — вы будете в темноте. CCcam не скажет, где проблема.

Сценарий: сервер-раздача и мультипротокольность

Если вы хотите раздавать нескольким клиентам, подключать несколько источников разных протоколов или просто иметь контроль над происходящим — OScam. Через webif на порту 8888 вы видите ECM time для каждого запроса, статус каждого ридера, количество активных клиентов. Это не luxury, это необходимость при отладке.

Плюс: источники по протоколу newcamd или camd35 CCcam подключить не сможет вообще. OScam — без проблем.

Связка OScam + CCcam на одном устройстве

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

При этом важно избежать конфликта: dvbapi должен быть включён только в одном демоне. Если оба попытаются перехватить /dev/dvb — получите хаос. Обычно dvbapi остаётся за OScam, а CCcam запускается только как ридер.

Порты тоже не должны пересекаться: если CCcam слушает на 12000, а у OScam есть listener на тот же порт — один из них не стартует. Проверяйте заранее через ss -tlnp.

По большому счёту вопрос cccam vs oscam бесплатно решается просто: если сомневаетесь — берите OScam. Переход с CCcam безболезненный, потому что OScam умеет подключаться к CCcam-источникам через protocol=cccam в oscam.server. Обратная миграция гораздо сложнее.