Наверное, мы всё-таки о разных вещах говорим. В моем случае, ТВ как бы работает, но, допустим, при сканировании каналов, на каждом 7-ом происходит "разрыв" связи, секунд на 10-25, потом снова работает, и так через каждые 7 каналов... Бывает вообще отваливается капитально, приходится GPON провайдера перезагружать. Ну просто какая-то нестабильность. На другом устройстве нет ни одной из этих проблем (((
Уже не знаю, куда еще копать...

LDSoft
Думаю что причина все же в особенности сети провайдера, ДФЛка она ж построена по принципу "что явно не разрешено то запрещено".
Надо анализировать пакеты на рабочей железке и нерабочей, выяснять чего не хватает. Я для этого готовился уже циску перед ДФЛкой ставить в виде сканера потоков, когда наткнулся на свою находку.

В остальном моя ДФЛка показала полную надежность. Так что думаю Вам надо или провайдеров трясти (мои не сознаются, а может и сами не понимают) на счет организации сети вещания, или самому копать более глубоко, не только на уровне логов ДФЛ.
В любом случае удачи!


UPD
На счет 7 каналов. Мой провайдер сказал что на клиента ограничение на 10 каналов (сейчас пока два) по одновременному подключению (просмотру) но проблема в том что при переключении с канала на канал сервер вещания предыдущий канал закрывает не сразу, а через какое то время, поэтому у меня сейчас можно только два канала переключить, и ждать несколько минут (примерно около 2 минут) пока отвалятся предыдущие каналы.
На мое утверждение что при переключении с канала на канал мой вьювер отписывается от предыдущего канала и по идее сервер должен автоматом прекратить вещание, провайдер ничего не смог ответить вразумительного, буду еще давить.
Это я к тому что у вашего провайдера может аналогичные ограничения? Посмотрите в соединениях, сколько подписок у вас ведется при переключении каналов.

Выяснил, что действительно при переключении зависает 6 подключений, таймаут у которых 130 попугаев, и естественно, возможно из-за ограничения со стороны провайдера, седьмое не открывается, пока не отвалится хотя бы одно из подключений... Уменьшение время жизни проблему не решает, так как прежде, чем пойдет отсчет таймаута на закрытие, проходит еще какое то время.

Вопрос! Как уменьшить интервал жизни этих подключений? Или я ошибаюсь в чем то?

На Вашей стороне уменьшать бессмысленно, я пробовал, блокирует то новый канал не ДФЛ, а сервер вещания. Время жизни канала настраивается на стороне сервера.
Судя по тому что Вы уже рассказали, у Вас не проходит отписка от канала. Я еще толком не знаю, но подозреваю что Вам необходимо правило позволяющее мультикаст из лана в ван, или опять же какой то маршрут на "левую" подсеть. Тут опять же либо пытать провайдера, либо самому вычислять.
У себя с отпиской я пока не разобрался, а провайдер тупит.

Что еще я выяснил - у ДФЛ есть два режима IGMP: Proxi и Snoop
При Proxi ДФЛ следит за последним подписчиком на канал в локальной сети, и это время по умолчанию 5000 миллисекунд, на ответ подписчика, его можно уменьшить по минимум, но все же время какое то пройдет, после чего ДФЛ отправит отписку.
При Snoop отписка происходит от вьювера, ДФЛ за этим не следит, но правило для прохождения отписки, думаю, требуется, какое не знаю пока. При этом не понятно что будет если в локалке один и тот же канал смотрят сразу двое, и тут один из них решил переключится, внешний wan IP то у них один...

Но в общем у меня ни первый ни второй вариант с "быстрой" отпиской пока не работает.

Верно, это и заметил, но как тогда igmpproxy, mcproxy на платформе OpenWRT с этим справляются без всяких танцев с бубном?

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

ЗЫ: Тупик на протяжении многих лет, на выход из которого все тупо забили!

Не ищите злого умысла там где его нет
Суть в том что несмотря на различные высокие технологии, стандарт именно IPTV не разработан и не стандартизирован. И каждый провайдер изгаляется как хочет/может. Более того, есть мнение что это "новшество" не переживет эфирное цифровое ТВ.
Так что возможно зря копья ломаем.
В моем Мухосранске эфирное цифровое ТВ, на обычную "рогатку" уже набирает обороты, и с неплохим темпом.

Победил и эту проблему.
В ходе изучения, у провайдера замечена подозрительная активность кроме сети
10.11.0.0/16 еще и 10.1.0.0/16
Направил через NAT udp трафик на ту и другую сети, и отписка от предыдущего канала происходит в течении пары секунд.
В общем все траблы у провайдера. Пока подключения к интернету нет весь трафик идет в ван через гетвей (единственный) и проблем нет. Как только появляется канал интернета так нужен шаманский бубен.
Надеюсь мои изыскания кому ни будь помогут.
Бубен не просить, самому нужен.

Можно подробнее, что за правила? И как вычислили эти сети?

LDSoft

Да в общем вот все правила:

Правила IGMP

Маршрут для Multicast_group (224.0.0.0/4) создается автоматически

Маршруты:

где в 3-ем маршруте GT_192 это адрес сервера вещания
а wan1_gw это гетвей локальной сети провайдера (без интернета который)

И правила:

IGMP_SAT_to_LAN направляет мультикаст из wan в lan
IGMP_SAT_to_WAN направляет мультикаст из lan в wan (для получения списка каналов, хотя пока не уверен в этом)
IGMP_Allow_to_WAN_LAN соответственно разрешение для предыдущих двух правил, где GroupMulticast это wan+lan
L1 и L2 натирует udp трафик на сетки 10.11.0.0/16 и 10.1.0.0/16 соответственно.

По результатам, заметил что как только мой вьювер отписывается от канала, то с сетки 10.11.0.0 прилетает RAWIP IGMP сообщение для отписываемого канала, то бишь для сети 224.0.0.0/4
И вьювер тут же реагирует (освобождается). Раньше вьювер закрывал канал секунд по 10-15 (не реагируя на команды).
И еще, как только с сетки 10.11.0.0 прилетает RAWIP IGMP сообщение для сети 224.0.0.0/4, тут же начинается обратный отсчет времени жизни канала.

Осталось только вычислить правильные порты, а то "all_udp" немного напрягает.

А вычислял - отключая всех пользователей, все подключения, не относящиеся к вопросу, наблюдал за трафиком (соединения, журнал), сопоставляя свои действия, постепенно отфильтровывая все лишнее. А дальше только интуиция и логика
Не очень практично, потому долго. Но провайдер все еще не сознается.
И пока у них тестовый режим, народу фиг да маленько, кто смог (как я) докопаться, тот смог...
А вот что они через месяц народу будут говорить, когда плату за услугу начнут взымать...


Добавлю еще один пункт, все это работает у меня вот с такими вот настройками интерфейса IGMP


Тоже самое для lan интерфейса

И расширенные настройки интерфейса IGMP

Странно это всё. Ведь ради чистоты эксперимента весь трафик по умолчанию завернут в wan, но отписки при переключении все равно не происходит.

Это действительно странно.
Тут только искать..., больше ничего не посоветую. Как у меня - я уже показал.

Как мой провайдер умудрился так с сетями намудрить - я не понимаю, и они похоже тоже.

Кстати, есть один нюанс, который заметил.
Канал не отпысывается если не показывал в течении нескольких секунд (точно сколько пока не замерял).
То есть если включит канал и через секунду выключить/переключить, отписки нет, и будет в соединениях висеть довольно долго.

И еще одна неясность. Почему тех. поддержка полностью игнорирует эту проблему?!!

В моем случае, они и не помогли бы, так как не знают особенности сетей моего провайдера
Кроме того, IPTV, как уже говорил - "недокументированная фича" (это не баг, это фича)

LDSoft
И еще.
Заметил что проигрыватель PotPlayer при отписке работает четче чем VLC (гарантировано) у VLC бывают глюки.
Но при подключении к каналу VLC отрабатывает быстрее PotPlayer, последний в данном случае может тупить по нескольку секунд.
На телеприставках не пробовал.