Shara TV: настройка CCcam и OScam сервера в 2026

Если вы только столкнулись с термином shara tv и пытаетесь разобраться, что это вообще такое и как заставить это работать на вашем ресивере — вы попали по адресу. Здесь не будет рекламы провайдеров и волшебных кнопок. Только реальные конфиги, пути к файлам и объяснение того, что происходит под капотом.

Что такое shara TV и как работает cardsharing

«Шара» — жаргонное название технологии cardsharing. Суть простая: одна физическая смарт-карта платного телевидения используется несколькими клиентами одновременно через сеть. Карта физически вставлена в сервер, клиенты подключаются по TCP и получают от неё ключи дешифрования.

Принцип работы: ECM, CW и descrambling

Каждый зашифрованный DVB-поток содержит ECM-пакеты (Entitlement Control Messages). Это зашифрованные данные, из которых карта извлекает Control Word — 8-байтный ключ, которым и расшифровывается видеопоток. Control Word меняется каждые ~10 секунд (crypto period).

Клиент на ресивере перехватывает ECM, отправляет его на шару (сервер с картой). Сервер пропускает ECM через смарт-карту, получает CW и возвращает его клиенту. Клиент передаёт CW в descrambler тюнера — и канал открывается. Всё это должно успеть произойти до смены CW, иначе будут фризы.

Роли в сети: сервер (карта) и клиент (ресивер)

Сервер — это машина с физической смарт-картой и ридером. На ней работает CCcam или OScam в режиме сервера. Клиент — ваш ресивер (обычно Enigma2 на OpenATV, OpenPLi и подобных) с CCcam или OScam в режиме клиента.

Один сервер может обслуживать несколько клиентов одновременно. Лимит зависит от условий провайдера и мощности сервера. Длинные цепочки, где сервер сам является клиентом другого сервера — это решара (reshare), которая увеличивает задержку.

Чем отличается локальная карта от sharing-подключения

Локальная карта вставлена прямо в ваш ресивер. Нет сетевой задержки, нет зависимости от чужого сервера. Но карту нужно купить — и она даёт доступ только к тем каналам, на которые оформлена.

Sharing-подключение — это аренда CW с удалённого сервера. Дешевле, но зависит от качества соединения, стабильности сервера и длины цепочки. ECM-время тут всегда выше нуля, и это нормально — если оно в пределах 300–500 мс.

CCcam против OScam: какой протокол и софт выбрать

Оба варианта используются для работы с shara tv, но это разные инструменты с разной философией. Вот в чём разница на практике.

CCcam: проприетарный протокол и формат строки C-line

CCcam — закрытый протокол, разработанный изначально для Dreambox. Конфиг минималистичный: всё подключение умещается в одну строку формата C-line:

C: hostname 12000 username password

Файл конфига — /etc/CCcam.cfg или /var/etc/CCcam.cfg в зависимости от образа Enigma2. Работает на порту, который назначает сервер — обычно в диапазоне 12000–15000.

Проблема CCcam: разработка фактически остановилась. Баги не фиксятся, новые протоколы не добавляются. Для базового использования работает, но гибкости ноль.

OScam: открытый эмулятор, читеры и модульность

OScam — open source, активно развивается, поддерживает одновременно несколько протоколов: cccam, newcamd, camd35, gbox и другие. Конфигурация разбита на отдельные файлы, что на первый взгляд пугает, но на деле удобнее.

Главные файлы:

• oscam.conf — глобальные настройки демона
• oscam.server — список ридеров (источников CW)
• oscam.user — пользователи (если OScam работает как сервер)
• oscam.dvbapi — настройки дешифрования для DVB-карт

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

Когда использовать OScam как клиент к CCcam-серверу

Большинство провайдеров шары выдают именно C-line для CCcam-протокола. Но вы вполне можете подключиться к CCcam-серверу через OScam — для этого в oscam.server нужно указать protocol = cccam. OScam переводит запросы в нужный формат самостоятельно.

Это лучший вариант: получаете удобство CCcam-сервера провайдера и полную диагностику OScam на своей стороне.

Настройка клиента: конфиг-файлы, пути и порты

CCcam.cfg: расположение и структура C-line

Файл CCcam.cfg на Enigma2-ресиверах обычно находится по одному из двух путей:

• /etc/CCcam.cfg — стандартный путь на большинстве образов
• /var/etc/CCcam.cfg — встречается на некоторых сборках OpenATV

Структура файла элементарная. C-line на подключение к серверу:

C: my.shareserver.net 12000 myuser mypassword

Если у вас несколько подключений — просто добавляете несколько C-line, каждая на новой строке. После редактирования нужно перезапустить демон:

/etc/init.d/CCcam restart

Права на файл должны быть 600: chmod 600 /etc/CCcam.cfg. Иначе демон может отказаться читать конфиг.

OScam: oscam.conf, oscam.server, oscam.user

Минимальный oscam.conf для клиентской работы:

[global]
logfile = /tmp/oscam.log
nice = -1

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

Секция [reader] в oscam.server для подключения к CCcam-серверу провайдера:

[reader]
label = myshare
protocol = cccam
device = my.shareserver.net,12000
user = myuser
password = mypassword
group = 1
reconnecttimeout = 30

Минимальный oscam.user нужен только если OScam работает как сервер для других клиентов. Для чисто клиентской конфигурации — необязателен.

Стандартные пути в Enigma2 и проверка прав доступа

На Enigma2 OScam-конфиги чаще всего лежат в одном из мест:

• /etc/tuxbox/config/oscam/
• /var/etc/oscam/
• /usr/keys/ — встречается на старых сборках

Проблема с нестандартными образами: демон OScam при запуске ищет конфиги в пути, который прописан при компиляции. Если конфиги лежат не там — они просто не читаются. Проверить, откуда демон грузит файлы:

oscam --help | grep config

или посмотреть стартовый скрипт демона в /etc/init.d/oscam на наличие параметра -c /путь/к/конфигам.

Все конфиги OScam должны принадлежать пользователю, под которым запускается демон. Обычно это root на ресиверах. Права — 600:

chmod 600 /etc/tuxbox/config/oscam/*

Диагностика: почему не открываются каналы

Вот где большинство руководств по shara tv полностью сливают. Дают C-line и говорят «всё заработает» — а когда не работает, человек остаётся один на один с пустым экраном.

Чтение логов OScam и веб-интерфейс на порту 8888

Первым делом открываем веб-интерфейс. Если настроили httpport = 8888 в oscam.conf, то по адресу http://<IP-ресивера>:8888 доступен полноценный дашборд.

Что смотрим: вкладка «Readers» — статус вашего ридера (CONNECTED/DISCONNECTED). Если ридер не подключился — проблема в сети или в данных подключения. Вкладка «Clients» и лог показывают живые ECM-запросы.

Лог в реальном времени через SSH:

tail -f /tmp/oscam.log

Ошибки FOUND/NOT FOUND, ECM time и статусы reader

В логе каждый ECM-запрос заканчивается одним из статусов:

• found — CW получен, канал должен открыться. ECM time показывает время ответа в мс.
• not found — карта не смогла расшифровать ECM. Чаще всего неверный CAID или provid.
• timeout — сервер не ответил за отведённое время. Проблема с сетью или перегрузкой сервера.
• invalid — ECM-пакет повреждён или неверный формат. Редко, но бывает.

ECM time выше 800–1000 мс — почти гарантированные фризы. Норма — до 300–500 мс. Если видите 100–150 мс — отличный сервер с локальной картой.

Проверить доступность порта сервера руками:

nc -zv my.shareserver.net 12000
# или
telnet my.shareserver.net 12000

Если соединение не устанавливается — либо порт закрыт на сервере, либо ваш провайдер интернета блокирует нестандартные порты.

Проблемы DVBAPI, CAID/provid и неправильный пиринг

DVBAPI — это интерфейс между OScam и DVB-стеком ресивера. Без правильной настройки oscam.dvbapi OScam может получать CW, но не передавать их тюнеру. Минимальный рабочий вариант:

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

CAID (Conditional Access Identifier) — идентификатор системы шифрования (например, 0x1800 для Nagravision, 0x0500 для Viaccess). Provid — идентификатор провайдера внутри системы. Если в oscam.server в параметре caid указано что-то не то — OScam просто не будет отправлять ECM на этот ридер.

Частая ошибка: несколько ридеров с одинаковым CAID без явного приоритета. OScam отправляет дублирующие запросы на оба, нагружает лишний раз. Решается через cccversion и параметр priority в oscam.dvbapi:

[dvbapi]
enabled = 1
prio = /etc/tuxbox/config/oscam/oscam.prio

Ещё одна ломающая вещь, о которой мало где пишут: рассинхрон системного времени на ресивере. CCcam и многие OScam-серверы проверяют время клиента. Расхождение больше нескольких минут — и соединение рвётся или вообще не устанавливается. Настройте NTP:

ntpdate -u pool.ntp.org

И добавьте его в автозапуск — на ресиверах без батарейки время сбрасывается при каждой перезагрузке.

Как выбрать сервер: технические критерии без имён

Провайдеров шары много. Называть конкретные сервисы не буду — это реклама. Но оценить качество источника можно объективно по нескольким метрикам, не доверяя словам.

Стабильность, локальные карты vs решары

Локальная карта на сервере даёт стабильное ECM-время — сервер обращается к картридеру напрямую, без дополнительных узлов. Решара (reshare) — когда сервер сам клиент другого сервера — добавляет переменную задержку. Каждый дополнительный hop добавляет 50–200 мс и точку отказа.

Признак длинной решары: ECM-время скачет. В один момент 200 мс, в другой — 600 мс. При локальной карте время стабильное, отклонения небольшие.

Как проверить: смотрите ECM time в веб-интерфейсе OScam в течение нескольких минут. Нарисуйте в голове картину: стабильно низко — хорошо, прыгает — решара.

Пинг, ECM-время и аптайм как метрики качества

Пинг до сервера — базовый показатель. Если сервер в Нидерландах, а вы в Москве — ждите 30–50 мс только на RTT. Это нормально. Но если пинг 150+ мс — ECM-время будет 400–700 мс даже на локальной карте. Ищите географически близкий сервер.

Аптайм важен не за сутки, а за недели. Сервер, который падает раз в неделю на час — это постоянные замороженные экраны в самый неподходящий момент. Нормальный показатель — 99%+ аптайм за месяц.

Суммарно: хороший источник для shara tv — это стабильный ECM time 200–400 мс, пинг до сервера не более 50–80 мс, и аптайм выше 99%. Всё это можно измерить самостоятельно через OScam.

Признаки ненадёжного источника

Несколько сигналов, что источник стоит сменить:

• Каналы открываются через 2–3 секунды после переключения — ECM-время явно выше нормы
• Фризы каждые ~10 секунд — сервер не успевает обновлять CW до следующего crypto period
• Ридер в OScam периодически уходит в DISCONNECTED и переподключается — нестабильное соединение или лимит на подключения
• После смены ключей или портов на стороне провайдера — никаких уведомлений, старый C-line просто перестаёт работать без объяснений

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