OScam fallback reader: настройка резервного reader

Если ваш основной источник декодирования иногда падает и картинка замирает — значит, у вас нет нормально настроенного резерва. OScam fallback reader решает эту проблему на уровне конфигурации, без сторонних скриптов и костылей. Ниже — как это работает и как настроить правильно.

Что такое fallback reader в OScam и как он работает

OScam не опрашивает все reader подряд при каждом ECM-запросе. Есть чёткая иерархия: сначала идут основные (primary) reader, и только если они не отдали валидный CW в пределах таймаута — подключается резервный. Это и есть механика fallback.

Схема прохождения запроса примерно такая: клиент (dvbapi или CCcam-клиент) шлёт ECM → OScam смотрит, какие reader подходят по caid и group → опрашивает primary reader → если таймаут или rejection — передаёт запрос fallback reader. Всё это происходит в рамках одного ECM-цикла.

Логика приоритетов: primary, fallback и порядок опроса

По умолчанию OScam опрашивает reader в том порядке, в котором они перечислены в oscam.server, с учётом group. Если у reader стоит fallback = 1, он исключается из первичного опроса и резервируется. То есть он физически не участвует в гонке за CW, пока есть живые primary.

Порядок внутри primary-группы при отключённом lb_mode определяется позицией в конфиге. При включённом load balancing логика меняется — об этом отдельно в разделе про тонкую настройку.

Чем fallback отличается от обычного reader и от cache

Обычный reader участвует в опросе всегда, когда совпадают caid и group. Fallback reader — нет: он молчит, пока primary справляются. Это важно для понимания времени отклика: переход на резерв всегда даёт небольшую задержку, это нормально.

Cache (cwcache / cacheex) — отдельная история. Кэш отдаёт уже расшифрованный CW из памяти, без обращения к reader вообще. Fallback — это именно живой reader, который делает реальный ECM-запрос к источнику.

Когда OScam переключается на резервный reader

Переключение происходит в трёх случаях: основной reader не ответил в пределах ctimeout, вернул rejection (нет подписки или неверный ident), или ушёл в статус OFFLINE. В первых двух случаях OScam сразу пробует fallback в рамках того же ECM-запроса. В третьем — на следующем запросе, после того как пометит primary как недоступный.

Настройка fallback reader в oscam.server

Конфиги OScam обычно лежат в /etc/tuxbox/config/oscam/ (Enigma2-боксы) или /var/etc/oscam/. На Linux-серверах чаще всего /etc/oscam/. Файл с reader — oscam.server.

Минимальный рабочий блок для CCcam-источника выглядит так:

[reader]
label        = main_cccam
protocol     = cccam
device        = 192.168.1.10,12000
user          = myuser
password      = mypassword
group         = 1
caid          = 1830,0604
fallback      = 0

И резервный reader к нему:

[reader]
label        = backup_cccam
protocol     = cccam
device        = 10.0.0.5,12000
user          = backupuser
password      = backuppassword
group         = 1
caid          = 1830,0604
fallback      = 1

Ключевая строка — fallback = 1. Всё остальное стандартно.

Параметр fallback и fallback_percaid

fallback = 1 делает весь reader резервным для всех его caid. Это грубый инструмент: если у reader несколько caid, он становится резервом по всем сразу.

fallback_percaid работает тоньше. Пример:

fallback_percaid = 1830:1

Это значит: reader является резервным только для caid 1830, а по остальным caid он работает как обычный primary. Удобно, когда у вас один источник хорошо держит один пакет и посредственно — другой.

Можно комбинировать несколько caid через запятую:

fallback_percaid = 1830:1,0604:1

Связь group в oscam.server и oscam.user

Вот где большинство застревает. Параметр group в блоке [reader] и параметр group в блоке [account] файла oscam.user должны пересекаться. Если они не совпадают — ECM-запрос от клиента просто не дойдёт до reader, и fallback никогда не сработает.

Пример oscam.user:

[account]
user         = client1
password     = clientpass
group         = 1

Если у вас reader в group = 2, а клиент в group = 1 — связи нет. Это самая частая причина, почему fallback "не работает", хотя конфиг reader выглядит правильно.

Пример блока [reader] для CCcam-источника

Полный рабочий пример с типичными параметрами:

[reader]
label            = fallback_cccam
protocol         = cccam
device            = backup-server.example.com,12000
user              = fbuser
password          = fbpass
group             = 1,2
caid              = 1830,0604,09C4
ident             = 1830:000000,0604:000000
fallback          = 1
cccmaxhops        = 2
cccwantemu        = 0
connectoninit     = 1
reconnecttimeout  = 15

cccmaxhops = 2 ограничивает глубину прыжков в CCcam-сети, что снижает latency. cccwantemu = 0 отключает запрос эмуляторов — для легальных карт это правильно.

Тонкая настройка: таймауты, приоритеты и group

Настройка OScam fallback reader не ограничивается одной строкой в oscam.server. Чтобы резерв срабатывал быстро и без фриза, нужно покрутить несколько параметров в oscam.conf.

Параметры ctimeout и lb_reopen_seconds

ctimeout в секции [global] определяет, сколько миллисекунд OScam ждёт ответа от reader, прежде чем считать его таймаутом. Дефолт — 5000 мс (5 секунд). Это много: при таймауте в 5 секунд картинка замирает заметно.

[global]
ctimeout         = 3500
zapping          = 1

На практике 2500–3500 мс — нормальный компромисс. Если ваши reader пингуются до 200–300 мс — можно ставить 1500–2000 мс. Слишком мало — начнут отваливаться медленные, но рабочие источники.

lb_reopen_seconds управляет тем, через сколько секунд OScam снова попробует reader, помеченный как нерабочий. Дефолт обычно 900 секунд (15 минут). Если основной источник вернулся через 2 минуты, а OScam будет ждать 15 — вы всё это время сидите на fallback. Для динамичных ситуаций стоит снизить до 120–300 секунд.

Взаимодействие fallback с load balancing (lb_mode)

При lb_mode = 1 (или выше) OScam сам решает, какой reader опрашивать первым, основываясь на статистике ответов. Это меняет логику: fallback reader не просто "ждёт своей очереди", он исключён из lb-выборки вообще — до момента, пока все primary не исчерпаны.

Проблема возникает, когда несколько fallback reader попадают в одну group при включённом lb_mode. OScam будет опрашивать их последовательно, и суммарный response time может вырасти до неприемлемого. Рекомендация: держите не больше одного-двух fallback reader на группу.

Параметр lb_nbest_readers в секции [global] задаёт, сколько primary reader OScam держит "в активной ротации" по lb-статистике. Если поставить слишком мало — часть primary просто не будет опрашиваться, и fallback будет срабатывать чаще, чем нужно.

Раздельный fallback по caid через fallback_percaid

Допустим, у вас два пакета: Viasat (caid 0604) и Tricolor (caid 4B02). Основной reader хорошо держит оба. Резервный хорошо держит только Viasat. Тогда правильная конфигурация резерва:

fallback_percaid = 0604:1

По caid 4B02 этот reader будет работать как обычный primary (если есть подписка). По caid 0604 — только как fallback. Это позволяет точечно распределять нагрузку без лишних таймаутов.

Важный edge case: если у основного и резервного reader совпадает caid, но разный ident — резерв не отдаст CW. OScam сматчит reader по caid, попробует запрос, получит rejection из-за несовпадения ident и в лучшем случае попробует следующий reader. В худшем — залогирует timeout. Всегда проверяйте параметр ident в обоих блоках.

Проверка работы fallback через веб-интерфейс и логи

Прежде чем считать настройку завершённой — проверьте. Теория без теста не стоит ничего.

Раздел Readers в webif и статус ENTITLEMENT

Включить веб-интерфейс OScam просто. В oscam.conf:

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

После перезапуска OScam открываете http://<ip>:8888 и видите раздел "Readers". Там отображается статус каждого reader: CONNECTED, OFFLINE, CONNECTING. Для fallback reader должно быть CONNECTED и в колонке "FB" — отметка, что это резерв.

В разделе ENTITLEMENT для каждого reader видны доступные caid. Если у резервного reader caid не отображается — значит, либо он не получил ENTITLEMENT от сервера, либо не прошла авторизация. Это объяснит, почему он молчит при переключении.

Чтение oscam.log: строки fallback и timeout

Включите детальный лог в oscam.conf:

[global]
logfile      = /var/log/oscam/oscam.log
debuglevel   = 64

В логе ищите строки вида:

2026/03/15 14:22:31 c [dvbapi] ECM 1830 > backup_cccam (fallback) <-- 350ms

Метка (fallback) рядом с именем reader — подтверждение, что запрос ушёл на резерв. Если метки нет, а reader name — это ваш backup, что-то пошло не так с конфигурацией.

Строка timeout выглядит так:

2026/03/15 14:22:28 c [dvbapi] ECM 1830 > main_cccam timeout (3500 ms)

Именно после такой строки должна идти строка с fallback reader. Если её нет — OScam не нашёл подходящего резерва.

Тест: принудительное отключение основного reader

Самый честный тест. В webif нажмите "Disable" на основном reader или временно измените его group на несуществующую (например, group = 99) и сохраните конфиг через oscam.conf reload. Запустите видео.

Если fallback настроен правильно — картинка на секунду подвиснет (это нормальный ctimeout) и восстановится. В логе появится строка с (fallback). Response time при этом будет выше обычного — это тоже норма, не пугайтесь.

Если картинка не восстановилась — смотрите лог: до какого reader дошёл ECM-запрос и что он вернул.

Troubleshooting: почему fallback reader не срабатывает

Разберём конкретные сценарии, потому что "не работает" — это не диагноз.

Несовпадение group между reader и user

Это причина номер один. Проверяется за 30 секунд: откройте oscam.server, найдите блок fallback reader, запомните значение group. Откройте oscam.user, найдите нужный аккаунт, проверьте его group. Они должны иметь хотя бы одно общее значение.

Reader с group = 2 и клиент с group = 1 — запросы до reader не дойдут никогда. В логе это выглядит как ECM без ответа, без строки с именем reader вообще.

fallback reader без валидной подписки или caid

Резерв подключён, CONNECTED, group совпадает — но CW не приходит. Скорее всего, у резервного reader нет активной подписки на нужный caid, или caid не указан в его блоке.

В логе это будет выглядеть как rejection:

2026/03/15 14:23:01 r [backup_cccam] ECM 1830 rejected (no entitlement)

Решение: проверить ENTITLEMENT в webif и убедиться, что в блоке [reader] перечислены нужные caid. Если caid есть, но ident отличается от основного — прописать правильный ident явно.

Конфликт с lb_mode и nofallback в oscam.user

В oscam.user есть параметр nofallback. Если он выставлен в 1 для конкретного аккаунта — fallback для этого клиента отключён полностью, независимо от настроек reader. Проверьте oscam.user.

При lb_mode = 1 бывает ситуация: OScam по lb-статистике считает primary reader "плохим" и перестаёт его опрашивать, но в fallback так и не уходит, потому что ждёт lb_reopen_seconds. В итоге вы получаете паузы без переключения. Лечится снижением lb_reopen_seconds до 60–120 секунд и проверкой lb_nbest_readers.

Ещё один кейс: после рестарта OScam fallback reader долго висит в CONNECTING. Это происходит из-за lb_reopen_seconds — сервер ждёт, прежде чем "доверять" reader снова. В этот период, если упал primary, fallback тоже недоступен. Workaround: в webif нажать "Reconnect" на нужном reader вручную, или снизить lb_reopen_seconds.