Судя по вашему видео, у вас не через udpxy поток идет.
В IPTVPlayer в настройках на первой вкладке, есть поле "Интерфейс". В нем должен быть указан ipвашегороутера:порт (который слушает udpxy) _________________ DIR-320,DIR-300rev.A&B,WR741ND,WR1043ND
JID: xsowie@seekwell.ru
Судя по вашему видео, у вас не через udpxy поток идет.
В IPTVPlayer в настройках на первой вкладке, есть поле "Интерфейс". В нем должен быть указан ipвашегороутера:порт (который слушает udpxy)
Да, у меня было настроено не так - в интерфейсе указан
IP wi-fi компутера, на котором пытаемся смотреть IPTV, но в списке каналов указан полный адрес.
http://192.168.11.2:4022/udp/239.1.1.1:1234
Сейчас попробую очередной заход с учётом новых знаний...
P.S.
Странно, ведь сами по себе IGMP не могут проходить - проверил что igmprt/igmpproxy режало.
P.S.S. Ещё больше расстраивает что древний DIR-300 на штатной прошивке ботает.
Еще раскажу про свои грабли в процессе поиска комфортного просмотра IPTV.
Вроде все настроил, все хорошо. Однако периодически пропадал интренет и IPTV показывал кубиками.
Выяснилось следующее.
"Фильтр многоадресных потоков" у меня был отключен.
А у ребенка в соседней комнате я как то забыл настроить IPTVPlayer. Так вот когда ребенок включал свой проигрыватель чтобы "телек позырить" начинался "интернет капут"
Поэтому "Фильтр многоадресных потоков" должен быть включен обязательно.
и в IPTABLES правило режущее igmp тоже должно должно быть удалено обязательно
Напрямую не пробовал сейчас но на той неделе работало исправно.
В конфигурации (Провайдер) -> DIR300 -> LAN / WiFi работает прекрасно сутками.
Думаю с правилами всё нормально если в самом начале идёт нормальный поток. Но что то его прерывает (udpxy), причём - штатно.
Может быть роутер должен на пакеты от "следящего" роутера давать какой-то отклик а его не дает и поток штатно гасится?
А вот это в логах настораживает
Code:
1970-01-01 00:32:55.523091 UTC 9617 read_buf: read: Resource temporarily unavailable
1970-01-01 00:32:55.523420 UTC 9617 read_data - EOF
1970-01-01 00:32:55.523617 UTC 9617 Exited relay loop: received=[-1], sent=[0], quit=[0]
1970-01-01 00:32:55.523938 UTC 9617 multicast-group [DROP]
1970-01-01 00:32:55.524170 UTC 9617 Mcast listener socket=[1] closed
1970-01-01 00:32:55.524655 UTC 9617 Child process=[9617] exits with rc=[0]
1970-01-01 00:32:55.525655 UTC 9513 *** Caught SIGCHLD in process=[9513] ***
1970-01-01 00:32:55.529311 UTC 9513 Client [9617] has exited.
1970-01-01 00:32:55.529561 UTC 9513 Deleted client: pid=[9617]
Тем более после прекращения показа каке-то время udp-пакеты всё равно идут.
"Фильтр многоадресных потоков" когда включен то не запускает igmprt (igmp proxy). Когда галка снята то igmprt запускается.
А его задача пробросить внутрь "домашней" подсетки мультикаст который запрашивает один из клиентов (например запустив VLC c обычным плейлистом типа udp://@238.0.0.1). Так вот проброс он делает конкретный и мультикат этот начинает кидать на всю подсетку и тому кто просил и тем кто его не запрашивал. Если вопрошающий был на шнурке, то у него всё тип топ, а вот если есть в подсетке клиенты на вайфае то им становится от этого мусора плохо и они загибаются вплоть до отрубания. Возможно этот процесс можно както подкрутить в /tmp/igmpproxy.conf но ни к чему, для этого и придуман собственно udpxy что бы отдавать поток по хттп только тому кто запросил и не мусорить в подсетке. Вывод: "Фильтр многоадресных потоков" - включать (причём оно срабатывает и при работающем и при неработающем SPI, хотя и пытается быть неактивным)
Last edited by DJArtyUA on Mon Feb 14, 2011 9:17; edited 1 time in total
Интересует в двух словах про сборку для Atheros.. где что взять(на ДИР-320 что-то там делал, а на ДИР-615 развернуться негде). Или просто 19-ю udpxy заполучить :о)
По логам похоже что именно следящий роутер не получает подтверждения о том что клиент ещё в онлайне и запрашивает поток, потому и решает поток больше не кидать. Видимо не все следители выловлены (у меня был один раздающий и один следящий, мне проще). Но если то же самое происходит и по обычной схеме.. тогда уж нечего сказать. Одно могу сказать что мне тоже кажется что на DIR-320 ранее показывало как то лучше что ли.. а сейчас на DIR-615 какието квадраты иногда даже по шнурку..(но тут и провайдер мог подиспортиться). Странно, проц в два раза сильнее только поменялся на атерос, имеет ли это значение пока непонятно.
Если вопрошающий был на шнурке, то у него всё тип топ, а вот если есть в подсетке клиенты на вайфае то им становится от этого мусора плохо и они загибаются вплоть до отрубания.
Дома проверю.
Тест простой. Берем файлик, начинаем его гнать через тракт LAN-WiFi, замеряем скорость.
Включаем на WiFi IPTV, проверяем скорость, засекаем просадку.
Отключаем WiFi IPTV, включаем на LAN.
По твоей теории просадка должна быть одинакова, так ?
Ну а вот и результаты тест драйва.
Копирование файла (54mbps wifi) = 1.9Мб/сек.
Копирование файла (54mbps wifi) + IPTV по LAN= 1.89МБ/сек.
0.01 можно списать на то что подтормаживает роутер или ещё как то но уж точно HD-видео поток на 5 мегабит как минимум не просачивается на WiFi а идёт тому кто запросил (LAN).
Уважаемый XGhosT192, а вы на каком устройстве udpxy запустить пытаетесь?
DIR-300? rev.A или B? если на нем?
или все же на Buffalo WZR-HP-G300NH? _________________ DIR-320,DIR-300rev.A&B,WR741ND,WR1043ND
JID: xsowie@seekwell.ru
Уважаемый XGhosT192, а вы на каком устройстве udpxy запустить пытаетесь?
DIR-300? rev.A или B? если на нем?
или все же на Buffalo WZR-HP-G300NH?
прикрутить iptv пытаюсь всеми силами к
Buffalo WZR-HP-G300NH, который взят на замену старичку DIR-300 H/W Rev.A1 и держится всё ещё на оригинальной прошивке (хорошо хоть туда telnet есть).
DIR-300 работает прекрасно на igmpproxy.
WZR-HP-G300NH не работает с IPTV никак :-(