Дык, может быть он просто не запускается с новыми параметрами, например, в памяти уже есть запущенный udpxy?Quote:
Originally Posted by lsd_777
Printable View
Дык, может быть он просто не запускается с новыми параметрами, например, в памяти уже есть запущенный udpxy?Quote:
Originally Posted by lsd_777
Нет нет, я сначало убиваю его killall udpxy, потом запускаю с новыми параметрами, все запускается, но телик не кажет!Quote:
Originally Posted by AlexeyS
А что значит "Только когда параллелишь ЛАН и ВАН "? Что в вашем случае является источником сигнала?
Ну мост включаю в вебморде WAN=LAN4 например, шнур от ипвт втыкаю в LAN4 так как он второй WAN получается, в этом случае все работает и в локалке и через инет переделаный плейлист, в локалке не переделанный тоже робит, НО надо сделать чтоб в локалке не через udpxy работало, а напряму, тобиш через свитч! Когда так делаю, в локалке все робит, но udpxy либо с LAN порта мултикаст не берет, либо его в WAN не посылает!Quote:
Originally Posted by AlexeyS
В общем пообщался с разрабом udpxy, показал логи, пришли к выводу, что надо рыть в сторону igmp, якобы он мультикаст с ВАН только переадресовывать или как то так...в общем пришел я к выводу, что надо бросать эту идею!!! Я похоже единственный в мире с такой задачей)))))
Мда, действительно, фигня полная, проверил... в тоже время, версия под cygwin такую ситуацию отрабатывает корректно... надо потестировать, в чём дело в ядре или всё-таки в самом udpxy...Quote:
Originally Posted by lsd_777
Я бы шарил в этом всём, дак поразбирался бы, но увы!!! Если найдете какое то решение, буду премного благодарен!!! За веткой буду поглядывать!Quote:
Originally Posted by AlexeyS
попробовал. Абалдеть... Я ест-но еще понаблюдаю, но пока доволен до безобразия... full hd iptv каналa заработали идеально... даже пробовал пускать два за раз... один на телеке, другой на компе - не идеально, но очень даже ниче работает... раньше такое не прокатывало совсем...Quote:
Originally Posted by AlexeyS
Блин, у меня при попытке скормить плееру ссылку http://192.168.1.1:81/udp/233.233.233.233:5000 в vlc вылазит окно авторизации. Какой ещё пароль надо вводить и где или где его убрать? Мой пароль от роутера не подходит. Поиск по теме по ключевым словам не помог.
Tomato Firmware 1.28.0000 MIPSR2-088V K26 USB AIO
Обычно так бывает, когда превышено максимальное число клиентов (3, по-умолчанию).Quote:
Originally Posted by makaka86
Доброе время суток!
Подскажите пожалуйста в последние прошивки уже интегрированы изменения в udpxy (rt-16n). И надо ли производить дополнительные действия (killall udpxy echo 524288 > /proc/sys/net/core/rmem_max и тд) для повышения стабильности работы iptv ?
Автоматически udpxy запускается с параметрами 'по-умолчанию', так что приведённый выше скрипт актуален и для новых прошивок.Quote:
Originally Posted by KRVAD
Значит в системе "по умолчанию" вот такой скрипт правильный?:Quote:
Originally Posted by AlexeyS
#!/bin/sh
killall udpxy
echo 524288 > /proc/sys/net/core/rmem_max
echo 524288 > /proc/sys/net/core/wmem_max
UDPXY_ALLOW_PAUSES=1 UDPXY_SOCKBUF_LEN=1048576 udpxy -p 81 -B 1Mb -R 100
зы. тестирую на последней прошивке 4051 на паре ноутов по wifi - iptv qwerty
Как обойти мультикаст довольно подробно написано тут http://borpas.info/iptvplayer-docs#3
Приветствую!
Пытаюсь настроить udpxy из транка: http://wl500g.googlecode.com/svn/trunk на x86 роутере (OpenWRT) для работы в сети Beeline (Corbina). На клиентской машине, при попытке открыть в VLC адрес вида: http://192.168.1.1:8080/udp/233.33.210.86:5050 ничего не происходит - чёрный экран. Tcpdump-ом собрал траффик на man (eth0) интерфейсе при попытке открыть ссылку.
Attachment 9241 10.254.135.112 адрес на eth0.
На роутере настроен и отлично работает igmpproxy. Параметры с которыми запущен udpxy: /usr/bin/udpxy -T -S -p 8080 -a br-lan -m eth0. Также пробовал запускать udpxy на клиентской машине - отлично работает, а на самом роутере - ни в какую. Готов предоставить любую дополнительную информацию. Заранее благодарю за помощь.
UPD: Все решилось настройкой iptables.
Господа, подскажите пожалуйста в ситуации: у меня роутер asus wl500gp с прошивкой 1.9.2.7-10, решил использовать udpxy для раздачи iptv по wifi и лан, до этого iptv работал около года для лан через multicast; вобщем я выставил в вебморде порт для udpxy, заменил плейлист, а так же отключил multicast, проблема в том, что udpxy работает некоторое время и просто падает, запускается естественно либр руками, либо после ребута роутера, у нее есть параметр -l для записи лога, но овт df -h показывает, что места на диске всего 3 мегабайта, собственно у меня вопрос, для тех, кто сталкивался с этой проблемой: можно как-то обновить или перенастроить udpxy без подключения флешки к роутеру ? подскажите пожалуйста.
http://www.udpxy.com/forum/viewtopic.php?f=3&t=71 ;)Quote:
Originally Posted by bsl45
З.Ы. У нас в прошивке пока ещё udpxy v.1.0.23-0 ... :rolleyes:
http://code.google.com/p/wl500g/source/detail?r=4503
Там по прямой функциональности изменений-то и нет... только всё рюшечки.Quote:
Originally Posted by Omega
в процессеQuote:
Originally Posted by Omega
http://code.google.com/p/wl500g/source/detail?r=4787 :rolleyes:Quote:
Originally Posted by theMIROn
Спасибо :) Всё собралось и отлично работает ;)
Руководство пользователя пакета udpxy :p
З.Ы. Народ и для RT-N66U собирает :eek:
Ситуация такова: у меня WL500GPv2 с прошивкой 1.9.2.7-d-r2624. Я включил мультикаст роутинг и пробросил первый порт пот iptv. смотрел ТВ на компе по меди, а интернет на нем же был подключен по wifi. Все бы хорошо, но купил телек со Смарт Тв. А он умеет работать либо по меди, либо по воздуху. Оба сразу не работают. И возникла необходимость чтобы на медном порту работал и ТВ, и интернет. Фигня вопрос, почитал все форумы - дело не хитрое. Ставлю прошивку 1.9.2.7-10, включаю IPTV UDP Multicast to HTTP Proxy на порт 5050, и... БОЛТ! Не пашет. ПРичем по адресу 192.168.1.1:5050/status ничего нет. Что я только не попробовал, и прошивки разные, и обнулял до заводских настроек и заново настраивал - ничего не помогает. Единственное, что чуть сдвинуло ситуацию - это запустить udpxy вручную через телнет. Запускаю udpxy -a br0 -m ppp0 -p 5050, в http://192.168.1.1:5050/status появляется все что нужно, но ссылки виде httр://192.168.1.1:5050/udp/224.1.1.2:6000 все равно не пашут.
Натолкните на хорошую мысль, как сделать?
Сработало!! Вот спасибо!! Сутки долбался, а тут за минуту все пошло)Quote:
Originally Posted by mehoskrd
При просмотре iptv через udpxy через Wi-fi все прекрасно только первые 2-5 минут. Обычно 3 минуты. Затем вылезает "udpxy[17270]: read_buf: read: Resource temporarily unavailable", роутер перестает мигать, и все останавливается до тех пор, пока я снова не тыркну в канал. Ну и так до бесконечности.
Есть идеи?
ASUS RT-N10U
Одинаковое поведение что на родной прошивке (B1 Firmware 3.0.0.4.260), что на прошивке "от Олега" (RT-N10U-1.9.2.7-rtn-r4772.trx)
Включаю прокси. Через прокси по WiFi работает, но! На ноуте без вопросов, на андроид девайсах (три телефона - HTC Desire HD, LG Optimus L5 и L9, пробовал плеера MX Player, BS Player, VLC) через минуту-полторы картинка чернеет и выдается сообщение "это видео не возможно воспроизвести". Тут же тыкаю снова на канал - опять минуту-полторы смотрю и все... Ошибка... Картинка при этом не "сыпется", показывает хорошо.
Если одновременно смотреть один канал на ноуте и на андроиде, то вроде как работает, но начинает периодически "сыпать кубики" и рассинхронизируется звук и видео.
Куда копать? Кто виноват и что делать? ;-)
Та же связка Модем+Роутер+udpxy, тот же провайдер (Укртелеком), но в другом городе и на андроиде все работало. Переехал в Киев, а тут не взлетает... (((
Счаз полистаю, что за зверь xupnpd...
Я так понимаю что только Томато содержит DLNA сервер? Или есть другие варианты?
И еще - "xupnpd" и "Media server" в томато это то о чем мы говорим?
Хочу сегодня вечерком залить вот это "tomato-K26USB-1.28.RT-N5x-MIPSR2-108-VPN.trx"
З.Ы. Залил, не взлетел WAN порт :-( Ищу решение...
ASUS RT-N10U / B1
Томато, "прошивка от Олега", родная, DD-WRT - перепробовал все - фиг один. После минуты-полторы воспроизведения потока UDP IPTV на андроид девайсе через udpxy видео обрывается с сообщением о невозможности воспроизведения...
Поставил на ноут софтинку UdpProxy.exe
Через нее все пучком, видео не обрывается. Делаю вывод - проблема таки в udpxy... Что-то ему надо настроить или искать старую версию, т.к. раньше на DIR-320 c прошивкой "от Олега" таких проблем не было. Жаль не помню что за версия была.
Хотя, возможно, проблема в роутере...
После переключения на hd-канал, роутер завис - помогло только передергивание питания. Со стандартным udpxy указанный канал не показывает изображение, но не вешает роутер.Quote:
Originally Posted by AlexeyS
Code:$ cat /.version
1.9.2.7-rtn-r5066
Не вис ни разу, иногда бывает самопроизвольно перезагружается на HD, но это вина не udpxy, а ядра...Quote:
Originally Posted by GUID
Да я наверное больше "к сведению", чем проблема/баг.Quote:
Originally Posted by AlexeyS
Насколько я понимаю в это процессе участвуют провайдер+роутер+плеер (в моем случае - vlc).
Самый непредсказуемый это наверное провайдер (невалинк, питер).
Не являюсь ярым фанатом ТВ, поэтому работает "из коробки" - неплохо, если не работает - не трагедия. Но, время тратить на его настройку совсем не хочется.
Всезнающий Олл !
Вопрос следующего плана: есть желание использовать UDP_to_HTTP прокси во избежание тормозов и искажений при просмотре... не важно под какую платформу, важна суть...
Attachment 9666
Соответственно 192.168.1.1 адрес на домашнем роутере который должен принимать мультикаст-пакеты в порт 4022 и транслировать поток по HTTP.
Wan-IP-Address соответственно мой адрес инет-подключения.
Свой провайдер не вещает IP - телевидение, по-этому пользуюсь попавшимися в инете рабочими плей-листами...
Могу ли адреса из попавшегося рабочего плей-листа, например:
#EXTINF:0,5 Канал
http://109.87.126.216:81/udp/238.0.0.6:1234
#EXTINF:0,7 Канал
http://109.87.126.216:81/udp/238.0.64.8:1234
и др.
просматривать используя СВОЙ прокси ? или это глупая затея ?
Помогите решить проблему с udpxy. У меня наблюдается вот что:
После перезагрузки роутера я открываю VLC-плеер и вбиваю адрес интересующего меня HD-канала: http://wan_ip:1212/udp/адрес:1234
Всё показывает идеально, никаких нареканий. После чего я либо переключаюсь на другой канал из плейлиста, либо переподключаюсь по той же ссылке, к тому же каналу.
И начинает жутко хлюпать и квадратить.
Далее я захожу в браузере по ссылке http://wan_p:1212/status и жму Restart. Снова подключаюсь из VLC к каналу и снова всё хорошо. Попытка повторного подключения - и снова всё плохо.
Т.е. проблема заключается в том, что updxy даёт мне возможность безглючно подключаться к себе только один раз после рестарта.
Если что, то у меня роутер Asus RT-N10U, прошивка 1.9.2.7-rtn, версия udpxy там 1.0-23.9 (prod).
Подскажите, кто в курсе, с чем может быть связана проблема? Как решить?
может проблема в том, что при переключении или переподключении роутер считает это другим потоком, т.е. запускает второй процесс.
посмотрите логи и команду ps давайте.
а на второй поток может просто не хватать мощности процессора.
Скажу сразу, что я запуск врукопашную с вручную указанными параметрами в post-firewall не прописывал, переменные окружения не трогал.
Т.е. udpxy запускается как оно и есть в прошивке по умолчанию.
ps сразу после рестарта:
[admin@RT-N10U root]$ ps
PID USER VSZ STAT COMMAND
1 admin 1520 S /sbin/init
2 admin 0 SW< [kthreadd]
3 admin 0 SW< [ksoftirqd/0]
4 admin 0 SW< [events/0]
5 admin 0 SW< [khelper]
27 admin 0 SW< [kblockd/0]
56 admin 0 SW [pdflush]
57 admin 0 SW [pdflush]
58 admin 0 SW< [kswapd0]
109 admin 0 SW< [mtdblockd]
198 admin 1380 S syslogd -m 0 -O /tmp/syslog.log -S -D -l 7 -b 1
200 admin 1380 S klogd
202 admin 956 S eapd
204 admin 1148 S nas
208 admin 1380 S telnetd
211 admin 1184 S dropbear -4
213 admin 1084 S httpd vlan1
218 nobody 1028 S dnsmasq
219 admin 944 S miniupnpd
232 admin 0 SW< [khubd]
236 admin 1016 S lld2d br0 eth1
272 admin 768 S {p910nd} p9100d -f /dev/lp0 0
319 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
322 admin 800 S /usr/sbin/igmpproxy /etc/igmpproxy.conf
323 admin 1392 S /sbin/udhcpc -i vlan1 -p /var/run/udhcpc0.pid -b -O3
325 admin 1520 S watchdog
329 admin 900 S infosrv br0
336 admin 1252 R dropbear -4
337 admin 1388 S -sh
356 admin 1384 R ps
После подключения к прокси из VLC-плеера:
[admin@RT-N10U root]$ ps
PID USER VSZ STAT COMMAND
1 admin 1520 S /sbin/init
2 admin 0 SW< [kthreadd]
3 admin 0 SW< [ksoftirqd/0]
4 admin 0 SW< [events/0]
5 admin 0 SW< [khelper]
27 admin 0 SW< [kblockd/0]
56 admin 0 SW [pdflush]
57 admin 0 SW [pdflush]
58 admin 0 SW< [kswapd0]
109 admin 0 SW< [mtdblockd]
198 admin 1380 S syslogd -m 0 -O /tmp/syslog.log -S -D -l 7 -b 1
200 admin 1380 S klogd
202 admin 956 S eapd
204 admin 1148 S nas
208 admin 1380 S telnetd
211 admin 1184 S dropbear -4
213 admin 1084 S httpd vlan1
218 nobody 1028 S dnsmasq
219 admin 944 S miniupnpd
232 admin 0 SW< [khubd]
236 admin 1016 S lld2d br0 eth1
272 admin 768 S {p910nd} p9100d -f /dev/lp0 0
319 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
322 admin 800 S /usr/sbin/igmpproxy /etc/igmpproxy.conf
323 admin 1392 S /sbin/udhcpc -i vlan1 -p /var/run/udhcpc0.pid -b -O3
325 admin 1520 S watchdog
329 admin 900 S infosrv br0
336 admin 1252 R dropbear -4
337 admin 1388 S -sh
355 admin 828 S /usr/sbin/udpxy -m vlan1 -p 1212
356 admin 1384 R ps
----------
Т.е. второй процесс с pid 355 как бы появился. Но разве это так и не должно быть? Или по-вашему при этом процесс с pid 319 должен был пропасть?
При последующих перезапусках ссылки из VLC процессы не плодятся, их остаётся два, только вместо pid 355- там каждый раз новый pid.
Опытным путём установил, что проблема вот в чём.
Постоянно запущенным является серверный процесс udpxy (с pid 319).
Каждый раз при подключении к прокси создаётся также клиентский процесс, каждый раз с новым pid. (пусть для примера - 355)
Пусть в VLC-плеере у меня показывает канал (поток, соответствующий клиентскому процессу с pid 355). Если (пока канал показывает) я в плейлисте жамкаю на другой канал или даже на этот же - то, судя по всему, происходит попытка запустить новый клиентский процесс перед тем, как не умер ещё старый (с pid 355). Это и приводит к тому, что вновь запущенный клиентский процесс начинает лагать/квадратить.
Если же я перед перещелкиванием на другой канал перезапускаю VLC-плеер или в явном виде убиваю старый клиентский процесс:
kill -19 355
то перезапуск канала приводит к полному успеху (т.е. отсутствию любых лагов).
--------------
Ну то есть вы поняли проблему: при быстром переключении на другой канал в плейлисте VLC (пока показывает первый) - возникает ситуация, что новый клиентский процесс (для нового канала) пытается запуститься пока старый (для проигрывающегося канала) ещё живой. В итоге, конечно, ps мне показывает, что после этого живёт только новый клиентский процесс, но он по факту оказывается ущербным (лагающим).
-----------
Если про эту особенность знать, то конечно перед переключением на другой канал можно перезапускать VLC-плеер (или даже рестартить прокси через страницу статуса), чтобы старый клиентский процесс гарантированно сдох. Вот только все нормальные люди хотят в VLC (или в IP-TV плеере) быстро переключаться по каналам. И, как правило, люди делают именно так: жамкают на другой канал пока старый ещё играет.
Что можно поделать?
У меня такое ощущение, что я разговариваю на этом форуме сам с собой =)
Чтобы окончательно отринуть версию о "нехватке мощности процессора" роутера я специально установил Ubuntu на виртуальную машину. Далее я перепробовал устанавливать все версии udpxy отсюда:
sourceforge.net/projects/udpxy
от самых старых, до самых новых. Во всех версиях одно и то же: начинает квадратить после быстрого переключения на следующий канал без предварительного отключения от уже проигрываемого. Кстати, заметил, что битрейт потока после такого переключения ниже должного. В том смысле, что если остановить просмотр канала кнопкой СТОП, чуть подождать и только потом запускать следующий канал, то битрейт потока у него будет правильный и всё будет чётко. Если же прямо во время просмотра канала щёлкнуть на следующий, то в свойствах потока для него я вижу битрейт вдвое ниже положенного и половина кадра - зелёные квадраты. Баг лучше всего заметен на HD-каналах (битрейты от 8 до 15 Мб/c) в VLC и Ip-tv-плеерах. С телека (в программах Smart IPTV, SS IPTV) эффект схожий, хотя и не так ярко выражен, т.к. эти программы в силу своей тормозной природы долго переключают каналы и, видимо, клиентский процесс udpxy для старого канала всё-таки зачастую успевает сдохнуть до запуска клиентского процесса для нового канала. Но если быстро щёлкать каналы один за другим, то в итоге приходим всё к тому же, к квадратам.
Вроде бы описываемая проблема не является в отдельности ни проблемой VLC, ни проблемой udpxy, но в связке она хорошо выражена.
Испытал также программу для Windows - UDP-to-HTTP прокси (borpas.info/utils). Вот с ней такого бага нету, работает чётко. Но мне нужна прокси именно на роутере, чтоб работала при выключенных компах. Так что программа под винду мне не подходит.
Перепробовал использовать все доступные параметры командной строки для запуска, во всех мыслимых и немыслимых комбинациях. Т.е. жонглирование параметрами -B, -R, -H, -n привело к потере времени, а к успеху не привело.
Есть ли смысл следующим шагом исследовать влияние заявленных переменных окружения? Я имею в виду вот эти:
UDPXY_RCV_TMOUT, UDPXY_DHOLD_TMOUT, UDPXY_SREAD_TMOUT, UDPXY_SWRITE_TMOUT, UDPXY_SSEL_TMOUT, UDPXY_LQ_BACKLOG
UDPXY_SRV_RLWMARK, UDPXY_SSOCKBUF_NOSYNC, UDPXY_DSOCKBUF_NOSYNC, UDPXY_TCP_NODELAY, UDPXY_HTTP200_FTR_FILE, UDPXY_HTTP200_FTR_LN,
UDPXY_ALLOW_PAUSES, UDPXY_PAUSE_MSEC.
Может изменение каких-либо из них помочь проблеме или это будет опять пустая трата времени?
В сущности, мне надо добиться того, чтобы прокси рестартилась перед каждым к ней обращением (перед созданием нового клиентского процесса). Хотя бы так. Или же, если уже установлено соединение прокси с клиентом с определенным ip, то при попытке нового обращения к ней с того же ip - чтобы она в явном виде сначала убивала старый клиентский процесс, а потом только запускала новый.
Автор программы (Паша Черенков), который активно тестировал прогу на первых страницах темы, - уже забросил проект?
Попробуйте ради интереса мою прошивку - там есть udpxy в составе
Под видной понятно -там ресурсов больше
Кстати иногда для решения проблем помогает включение свопа!
Очень мало народа вообще в курсе темы, а уж в потроха udpxy не залезал никто.Quote:
Originally Posted by Npspacer
Это замечательно что проверили работу на Ubuntu со свежими ядрами, значит ньюанс в подписке/отписке на мультикаст в самом udpxy.
Судя по сайту автора http://www.udpxy.com/ они заняты коммерческим вариантом - Gigapxy.Quote:
Автор программы (Паша Черенков), который активно тестировал прогу на первых страницах темы, - уже забросил проект?
AndreyPopov
Самому udpxy своп как рыбке зонтик - если уж поток пойдёт в своп, то это будут уже не квадраты, а треугольники ;)
Там банально не хватает ресурсов процессора на несколько потоков HD одновременно, udpxy очень сильно нагружает любой процессор - а квадратит, потому как не успевает выбирать очереди.Quote:
Originally Posted by lly
В свап может выгружаться что-то другое, чтобы освободить ресурсыQuote:
Originally Posted by lly
А пробовали запускать udpxy с опцией -с 1 - один клиент?Quote:
Originally Posted by Npspacer
С опцией -с 1, честно говоря, не пробовал. Т.к. приемлемым будет не в принципе ограничить число клиентов одним, а ограничить число клиентов с одного конкретного айпи одним (чтобы со всякого ip можно было одновременно смотреть не более одного тв канала). Но всё-таки проверю, помогает ли это в принципе.
Что касается нехватки ресурсов любого процессора на несколько потоков HD одновременно, то получается, что два - уже много что ли? Да и то, после переключения канала старый клиентский процесс (от старого канала) должен бы умирать, а оставаться только один новый клиентский процесс (для нового канала). Связан ли баг с тем, что в какой-то малый миг существуют оба процесса и это приводит к дальнейшим глюкам? Я не знаю..
Виндовая прокси почему-то позволяет смотреть много HD-каналов сразу и процессор даже не жужжит, справляется легко...
В сущности меня бы устроило от прокси добиться того, чтобы она гарантированно убивала все старые клиентские процессы перед каждым новым обращением, т.е. созданием нового клиентского процесса.
----
Или даже устроило бы рестартить прокси перед каждым новым обращением. Ну типа перед каждым переключением на другой тв-канал (http://ip_роутера:1212/udp/адрес:1234) засылать GET-запрос на URL "http://ip_роутера:1212/restart/". Занимает рестарт, как я понимаю, около 15 миллисекунд. Ведь "на свежую голову", т.е. сразу после рестарта прокси показывает прекрасно любой HD-канал, это факт. Увы, ни VLC-плеер, ни имеющиеся программы IPTV для телевизоров - этого не делают, т.е. запросы на рестарт прокси не посылают (даже не знают, что получают поток от udpxy).
----
Я понимаю, что код udpxy никто особо не ковырял. Но может кто-то в принципе неплохо шарит и подскажет, какое изменение нужно внести в исходный код udpxy, чтобы прокся сама себя рестартила перед каждым новым подключением?
рассмотрим примерно как все происходит:Quote:
Originally Posted by Npspacer
- вы смотрите один канал, под него сформировался поток
- потом вы переключаетесь на другой канал
ведь udpxy не в курсе, что вы просто переключили канал. udpxy получил запрос на формирование нового потока
но старый-то поток убить ему кто-то должен сказать. делает ли это плеер? или udpxy сам решает когда убить поток по отсутствию запросов на поток?
ну мягко говоря - это НЕправильное поведение, потому что вдруг у udpxy несколько клиентов подключены? и что? каждый раз, когда кто-то переключает канал у всех должна прерываться трансляция?Quote:
Originally Posted by Npspacer
Ну да, судя по всему сам решает. Потому что по факту старый поток (точнее старый клиентский процесс) после переключения реально не существует. Во-всяком случае, ps показывает, что появился новый клиентский процесс с другим pid, а старого уже нету. Вот только этот новый клиентский процесс почему-то становится ущербным и квадратит. Хотя, если в плеере нажать в явном виде кнопочку СТОП (а не просто даблкликнуть по другому каналу), а потом запустить новый канал - то всё хорошо.Quote:
Originally Posted by AndreyPopov
Понимаю, что неправильное. Но на крайняк меня устроит и это для моих целей. Ну а GET-запрос на рестарт может всё равно послать кто угодно, это не запрещено. Т.е. каждый может итак оборвать трансляцию всем простым переходом по ссылке "http://ip_роутера:1212/restart/" в браузере...Quote:
Originally Posted by AndreyPopov
убивание(остановка) процесса тоже занимает некоторое время.
я так понимаю с начала создается новый процесс, а уж потом убивается старый. вот новому ресурсов не хватает.
а ресурсы освобождаются уже после убийства старого процесса.
потому и предлагаю свап - при недостатке ресурсов неактивный процесс может быть выгружен в свап.