OScam sid assign: настройка приоритета каналов

Если ты уже поднял рабочий OScam и большинство каналов декодируются нормально, но несколько конкретных пакетов постоянно фризят или переключаются с задержкой в 3–5 секунд — скорее всего, дело в маршрутизации ECM. OScam sid assign — это механизм, который позволяет явно сказать серверу: «этот SID обрабатывай только через вот этот ридер». Без этой настройки OScam сам решает, куда слать ECM-запросы, и не всегда выбирает правильно.

В этом материале — конкретика: синтаксис файлов, реальные примеры конфигов, диагностика по логам и webif. Никакой воды.

Что такое sid assign в OScam и зачем он нужен

Само понятие OScam sid assign немного вводит в заблуждение — в конфигах OScam нет отдельной директивы с таким именем. Это общий термин для механизма привязки Service ID к конкретному ридеру через файл oscam.services и параметр services в oscam.server. По сути это маршрутизация ECM на уровне SID канала.

Пути к файлам зависят от прошивки. На Enigma2-боксах это обычно /etc/tuxbox/config/oscam/, на OpenWrt или dvbapi-системах — /var/etc/oscam/. На некоторых прошивках конфиг живёт в /usr/keys/oscam/. Прежде чем что-то редактировать, проверь в oscam.conf параметр configdir.

Разница между sidtab, services и фильтрами ридера

oscam.services — это файл с именованными таблицами SID. Каждая таблица (её называют sidtab) описывает набор каналов по CAID, провайдеру и SID. Параметр services в секции [reader] в oscam.server говорит OScam, какую таблицу применять к этому ридеру. Это два разных уровня — сначала ты описываешь набор каналов, потом привязываешь его к ридеру.

Фильтры ридера (caid, ident, group) работают грубее: они определяют, может ли ридер вообще обработать запрос для данного CAID. Services работают тоньше — на уровне конкретного SID внутри уже разрешённого CAID.

Когда sid assign реально решает проблему фризов

Классический сценарий: у тебя два ридера на одном CAID — например, локальная карта и сетевой источник. Локальная карта быстрее, но обрабатывает только часть пакета. OScam без явных ограничений может слать ECM на сетевой источник для канала, который прекрасно декодируется локально. Результат — ненужная задержка или таймаут.

Ещё один случай — CAID, который используется несколькими провайдерами. OScam без SID-фильтра попробует все доступные ридеры подряд, пока один из них не ответит. Это и есть источник тех самых 3-секундных задержек при переключении.

Как OScam выбирает ридер без явного назначения SID

По умолчанию OScam использует load balancer. Он смотрит на CAID запроса, список ридеров, способных его обработать, и выбирает тот, у которого лучшее среднее время ответа на ECM. Звучит умно, но LB работает на основе статистики предыдущих запросов — если ридер однажды ответил быстро, он получает приоритет. Если у тебя нестабильный источник, LB может упорно слать ECM туда, пока статистика не испортится достаточно. Services позволяют зафиксировать маршрут явно, без оглядки на LB-историю.

Формат файла oscam.services и синтаксис SID-таблиц

Файл oscam.services — это текстовый файл с блоками. Каждый блок начинается с имени в квадратных скобках. Вот реальный пример:

[sport_package]
caid = 0500
provid = 032830
srvid = 00A1,00A2,00A3,00A4,00B7

[news_package]
caid = 0604
provid = 000000
srvid = 1001,1002,1003

Поле srvid — это и есть список SID каналов в шестнадцатеричном формате. Именно они фигурируют в ECM-логе как sid. Запятая как разделитель, пробелы между значениями допустимы, но не обязательны.

Блок [label] и поля caid, provid, srvid

Имя блока (label) — произвольная строка без пробелов. Это имя потом указывается в oscam.server в параметре services. Регистр имеет значение: если в oscam.services написано [Sport_HD], а в oscam.server указано services = sport_hd — привязка не сработает.

caid — CAID системы условного доступа (Viaccess — 0500, Nagravision — 1801, Conax — 0B00 и т.д.). provid — идентификатор провайдера в рамках этого CAID, обычно 6 hex-символов. srvid — список SID через запятую.

Перечисление нескольких CAID и провайдеров в одной таблице

В одном блоке можно перечислить несколько CAID через запятую:

[multi_caid_package]
caid = 0500,1801
provid = 032830,000000
srvid = 00A1,00A2,1001,1002

Но здесь есть нюанс: OScam применяет условия как пересечение — CAID из списка И provid из списка. Если у тебя два разных CAID с разными provid, и SID каналов разные, лучше сделать две отдельные таблицы. Иначе фильтр может сработать шире, чем ты хочешь.

Комментарии, регистр и частые синтаксические ошибки

Комментарии в oscam.services — строки, начинающиеся с #. Это полезно, когда таблиц много и нужно пояснить, какой пакет есть что.

Три самые частые ошибки: лишний пробел после имени блока ([sport_package ] с пробелом перед скобкой), нули в начале SID (srvid = 00A1 и srvid = A1 — это разные значения), и несоответствие регистра в label между файлами. Если после перезагрузки конфига канал всё ещё не привязывается — первым делом проверяй именно это.

Привязка SID-таблицы к ридеру через services и sidtab

После того как ты описал таблицы в oscam.services, нужно привязать их к конкретному ридеру в oscam.server. Выглядит это так:

[reader]
label = local_card_viaccess
protocol = smartreader
device = /dev/ttyUSB0
caid = 0500
ident = 0500:032830
group = 1
services = sport_package

Теперь этот ридер будет обрабатывать ECM только для SID из таблицы sport_package. Все остальные запросы на этот ридер не пойдут.

Параметр services в секции [reader]

Если указать несколько таблиц через запятую (services = sport_package,news_package), ридер будет обрабатывать SID из обеих. Можно и наоборот: использовать инверсию.

Пример с двумя ридерами на одном CAID 0500, где SID разнесены по источникам:

[reader]
label = card_reader_1
caid = 0500
services = sport_package

[reader]
label = card_reader_2
caid = 0500
services = news_package

Теперь спортивные каналы идут через первый ридер, новостные — через второй. Никакой конкуренции между ридерами за одни и те же ECM-запросы.

Инверсия: что декодировать, а что игнорировать

Перед именем таблицы можно поставить ! — тогда ридер будет обрабатывать всё, кроме этих SID:

services = !sport_package

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

Связка с group и lb_whitelist_services для load balancer

Вот где большинство конфигов ломаются: параметр services ограничивает ридер, но load balancer об этом может не знать. Если LB решит отправить ECM на ридер, не обслуживающий данный SID, — ридер ответит rejected, LB занесёт это в статистику и следующий запрос снова попробует этот ридер. Цикл фризов.

Решение — параметр lb_whitelist_services в секции [global] в oscam.conf:

[global]
lb_whitelist_services = sport_package,news_package

Это говорит LB: не пробуй ридеры, для которых запрошенный SID не входит в их services-таблицу. Без этой строки OScam sid assign работает только наполовину — ридер отфильтровывает запросы, но LB продолжает их слать.

После любых правок в oscam.services и oscam.server делай reload через webif: раздел Configuration → нажми Reload. Полный перезапуск ресивера не нужен, достаточно перезагрузить процесс OScam или нажать кнопку в интерфейсе.

Диагностика: проверяем, что назначение SID работает

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

Путь к логу задаётся в oscam.conf параметром logfile. Обычно это /var/log/oscam.log или /tmp/oscam.log. Временно выставь уровень debuglevel = 255 в секции [global] — это выведет полную картину ECM-маршрутизации. После диагностики верни debuglevel = 0, иначе на боксах с маленьким flash-хранилищем лог быстро его забьёт.

Чтение ECM-лога и поля srvid/caid:provid

Строка ECM в логе выглядит примерно так:

2026/03/15 14:22:31 c (ecm) dvbapi (0500&032830/00A1/0001): found (164 ms) by local_card_viaccess

Здесь 0500 — CAID, 032830 — provid, 00A1 — SID канала (то, что в конфиге называется srvid), 0001 — ONID. Поле found (164 ms) by local_card_viaccess подтверждает, что ECM ушёл на правильный ридер и получил CW.

Если видишь rejected by reader_name — ридер получил запрос, но отклонил из-за несоответствия services. Если not found — ни один ридер не ответил. Если timeout — ридер получил запрос, но не ответил в отведённое время.

Webif: вкладка Status и время ответа (ms)

В webif OScam (обычно порт 8888) открой вкладку Status. При активном декодировании канала ты увидишь строку с текущим SID, CAID, провайдером и ридером, который обрабатывает ECM. Колонка с временем ответа в миллисекундах — твой главный индикатор. Локальная карта должна давать 100–300 ms, нормальный сетевой источник — до 600–800 ms. Если видишь 1500+ ms или прыжки — что-то идёт не так.

На вкладке Readers можно увидеть статистику по каждому ридеру: сколько ECM обработал, сколько rejected, среднее время. Это помогает понять, не застрял ли LB в петле неудачных запросов.

Включение debug-уровня и фильтрация по каналу

При debuglevel = 255 лог генерируется очень быстро. Удобно фильтровать по нужному SID прямо в терминале:

tail -f /tmp/oscam.log | grep "00A1"

Так ты видишь только строки, относящиеся к конкретному каналу. Если ECM уходит не на тот ридер — видно сразу. Если запроса нет вообще — проблема выше, на уровне dvbapi или настроек клиента.

Критерии выбора источника декодирования (без рекламы)

OScam sid assign имеет смысл только тогда, когда источник, на который ты привязываешь SID, действительно надёжен. Иначе ты просто жёстко закрепил канал за плохим ридером.

Вот что реально важно при оценке любого источника декодирования.

Стабильность пинга и время ответа на ECM

Время ответа на ECM — главный параметр. Смотри не на среднее, а на разброс. Источник, который даёт 200 ms в среднем, но иногда скачет до 1800 ms — хуже, чем тот, что стабильно держит 400 ms. Криптопериод большинства CAID — около 10 секунд. Если ECM не пришёл за 8–9 секунд, пойдут фризы.

Пинг до хоста источника — косвенный показатель. Если RTT 250 ms и выше, ECM при любом раскладе будет медленным. Хорошие источники находятся в той же географической зоне или на выделенных серверах с низкой нагрузкой.

Соответствие CAID/provid вашему пакету

Это звучит очевидно, но на практике часто упускается. Источник должен поддерживать именно тот CAID и provid, который использует твой пакет. Если провайдер вещает на CAID 0500 с provid 032830, а источник обрабатывает только 0500:040810 — декодирования не будет, только таймауты.

Проверяй это через лог ECM до настройки services. Увидел not found или rejected с правильным CAID, но чужим provid — источник не подходит для этого пакета вообще.

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

Локальная смарт-карта в USB-ридере или встроенном CAM — идеальный вариант для OScam sid assign. Она не зависит от сети, даёт стабильный и быстрый ECM-ответ, и её CAID/provid всегда точно соответствуют подписке. Если у тебя есть физическая карта — привязывай критические каналы через services именно к ней.

Сетевые источники (cccam, newcamd, camd35) — другая история. Здесь добавляется сетевая задержка, возможная перегрузка источника, лимиты на ECM и риск разрыва соединения. Для них особенно важен параметр reconnecttimeout в секции ридера и правильно настроенный LB, чтобы OScam не зависал в ожидании ответа от упавшего источника.

С точки зрения настройки OScam sid assign — разницы в синтаксисе нет. Но для сетевого ридера дополнительно стоит выставить ecmwhitelist и ecmcache, чтобы снизить нагрузку на источник и ускорить повторный декод тех же ECM.