Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Pepsik

Страницы: [1] 2 3 ... 143
1
ВСЕ не правильно в принципе .... было ДО СИХ ПОР ....

zuram дико извиняюсь но я НЕ буду разгребать логи в версии прокси в которой используется HTTP API движка.
Я СОЗНАТЕЛЬНО в полном здравии и ясности ума УБРАЛ это из текущей версии и убрал довольно давно ....Убрал НЕ зря и НЕ просто так от нечего делать ..... Посему берем исходники с git в aceconfig.py делаем loglevel = logging.DEBUG и больше там, желательно, ничего не трогать и пытаемся получить
BrodcastStreamer:ConnectionError(MaxRetryError('HTTPConnectionPool(host=\'127.0.0.1\', port=6878):
  ;)

А вот когда верну HTTP API "взад" , то поверьте , такого там НЕ будет  ::) .... 

p.s.  И еще ... не стоит включать запрос ссылки в hls от движка .... Это ровным счетом ничего не дает при использовании с проксей кроме дополнительной нагрузки на движок ... Если что мое "наглое" мнение можно прочесть вот тут - http://mytalks.ru/index.php?topic=4506.msg77782;topicseen#msg77782 , будет желание возразить - ДОБРО ПОЖАЛОВАТЬ ... только аргументированно с логами движка и примерами  ;) ... ибо hls в движке был сделан исключительно для поддержки плееров яблодевайсов, ChromeCast и web-плееров на основе playerJS  ;)

2
спасибо за направление, поковырял. и все-таки, мне не понятно - какое знание мне добавляет запись из лога /ace/r/308e9c804c6dddf4894d7ddf3a363451b015b6fa/c314b84c24cf370e506a74000a62e47d (Caused by ReadTimeoutError("HTTPConnectionPool(host=\'127.0.0.1\', port=6878): Read timed out. (read timeout=5)"))')) кроме явного указания, что конкретно этот запрос умер по таймауту? мне например не понятно из лога кто и каким образом инициировал этот запрос. а Вам? возможно в песочнице где обращения происходят раз в 100 лет и одновременно подключеных клиентов не бывает больше одного-  этого достаточно, но когда запросов больше и параллельно висят несколько клиентов подобная запись в логе не дает никакой информации о том, кто чего хотел и упал вот с такой ошибкой. может в режиме дебага стоит в логи писать все запросы, которые в итоге приводят к такому запросу? ну или хотя бы возвращать первый запрос, который после всех редиректов приводит к запросу подохшему по таймауту. ну или как вариант создавать уникальный айди каждому запросу от клиента и в логи писать сообщения с выводом этого уникального айди и сообщения об ошибке/нотификейшне?
1) Вам - не добавляет "знание", поскольку Вы его "не приобрели/не дочитали/не вникли/не поняли до конца" по указанному направлению ... И сами написали что Вам - не понятно
2) (Caused by ReadTimeoutError("HTTPConnectionPool(host=\'127.0.0.1\', port=6878): Read timed out. (read timeout=5)"))')) - это сообщение библиотеки requests , да его можно вывести в DEBUG c traceback , но исходя из п.1) , пока НЕ осилите "направление" оно Вам так ничего и не скажет. Вывести к ней еще и PID трансляции  (что-то как вы написали вот такое /pid/3e31d8f1f872dd2f3987641472565db398a7e9cc/) труда не составляет .... Более того данная ошибка НИКАКОГО отношения не имеет к количеству подключенных к проксе клиентов, как и к самой проксе ибо уникальный идентификатор ТРАНСЛЯЦИИ и уникальный идентификатор КЛИЕНТА - это две "космические" разницы .... далее читаем - п.3)
3) У клиентов есть уникальный идентификатор , но ... НИ ОДИН клиент не обращается к движку напрямую, на то она и прокся .... все клиенты - это клиенты соответствующего "reader-middleware" на базе библиотеки requests, которая и сыпет ошибку приведенную в п 2) ... Возникновение данной ошибки не то что крайне редко, оно ничтожно мало... Лично я за ТРИ года ловил ее от силы раза два или три ... И связана данная ошибка с ошибкой в работе web-сервера (python BaseHTTPServer + BaseHTTPRequestHandler) самого движка .... и прокся к ней НИКАКОГО отношения не имеет .... внимание вопрос ... что Вам даст DEBUG данной ошибки в проксе кроме указания модуля и строки в данном модуле библиотеки requests ?
4) Кол-во клиентов на которых проверялась прокся и работала без траблов (это при РАЗНЫХ live трансляциях ибо несколько клиентов на одной трансляции технически = одной трансляции , Вы все таки осильте "направление") - ограничено в основном пропускной способностью Вашего канала интернет и самим движком. Тут проскакивали сообщения о том что "народ" запускал и 20 трансляций одновременно .... Мне, например, отписались представители разрабов движка, и написали что тестировали 50 одновременных клиентов на HD трансляциях , правда при использовании HTTP API (я его пока временно убрал из кода), при этом трафик был под гигабит .... Внимание вопрос сколько надо запросов "с эмулировать" в песочнице для получения озвученной Вами ошибки ? Напоминаю , я ее ловил раза ТРИ от силы ....   

Ошибка приведенная Вами - это connect timeout (indicates the time that the appliance waits to establish a connection to the server before it generates an error message) , т.е. превышение времени ПОДКЛЮЧЕНИЯ к ДВИЖКУ и НИКАКОГО отношения не имеет к read timeout .... Грубо говоря Вам движок , выдав ссылку на подключение, отказывает в ее обслуживании в течении заданого времени (по умолчанию 5 сек) .... В логе прокси выводится исключительно в целях информирования "пациента" о том что ошибка имеет место быть... Рядовому "пациенту" все те описанные мной выше "дебри" в п1)-4) - ДО ЛАМПОЧКИ .... Внимание еще раз вопрос зачем там DEBUG? и какое отношение он имеет к функционалу прокси ? ее ошибкам ? А тем более к уникальному идентификатору клиента?

p.s. Кстати о логе прокси ...если включить в настройках DEBUG то всегда можно ОДНОЗНАЧНО установить кому по какому запросу движок вернул ссылку вида /ace/r/308e9c804c6dddf4894d7ddf3a363451b015b6fa/c314b84c24cf370e506a74000a62e47d и сопоставить его с ошибкой вида (Caused by ReadTimeoutError("HTTPConnectionPool(host=\'127.0.0.1\', port=6878): Read timed out. (read timeout=5)"))'))  ... Вне зависимости от кол-ва "детворы" в "песочнице" .... Функцию контекстного поиска , например в nano или NotePad++, по заданной строке еще никто не отменял  :'( Ну и самое забавное во всем этом "эссе" то , что причины возникновения "краша" или отказа в обслуживании ссылки вида - /ace/r/308e9c804c6dddf4894d7ddf3a363451b015b6fa/c314b84c24cf370e506a74000a62e47d, надо смотреть в логе ДВИЖКА, а не прокси, ибо прокся к ней имеет такое же отношение как я "к балету" .... Ну собственно это станет понятно после неоднократного изучения/вникания/познания и т.д. "НАПРАВЛЕНИЯ" - http://wiki.acestream.org ::)

3
Есть у меня "тестовое" решение для вот этой траблы - http://mytalks.ru/index.php?topic=4506.msg88309#msg88309 ... но такое 50/50  .... ибо победить паузу отдачи данных движком во время буфферизации можно только введением промежуточного буфера для данных на проксе (от чего благополучно отказались ранее), да и при условии что этот буфер успевает наполняться между буфферизациями на движке на столько, что перекрывает по времени время следующей буфферизации движка .... В общем KonstantinK свяжись со мной в личке получишь на тест пару-тройку измененных файлов. Лично я проверял на TiviMate (там 6-7 сек read timeout)... По большинству HD каналов ситуацию спасает ... по SD - 70/30 .... А с учетом того что у каждого плеера свой размер встроенного буфера данных и соответственно все они по разному читают данные с одной и той же трансляции .... это походу "борьба с ветряными мельницами" .... Проще у авторов плеера попросить read timeout в 30-40 сек ... И это решает 90% трабл с трансляциями с частой и долгой буфферизацией со стороны движка....

4
Разобрался с проблемой, пока нули вывел. Думаю как нибудь с помощью grep, sed и т.п. выведу. Писать туда долгая история. Есть вопрос с автозапуском. Через init.d стартануть могу проксю. А как быть с рестартом при краше? Если есть у кого опыт с проксей на роутерах и иных кастрированных отпишитесь пожалуйста.
Питон 2.7 есть, раз проксю стартанули .... зависимости ставить умеете?
Вот тут почитать и вникнуть - http://supervisord.org/installing.html
-bash-4.4# pip2 install supervisor                                                                                                                           
Collecting supervisor
  Using cached https://files.pythonhosted.org/packages/ba/65/92575a8757ed576beaee59251f64a3287bde82bdc03964b89df9e1d29e1b/supervisor-3.3.5.tar.gz
Collecting meld3>=0.6.5 (from supervisor)
  Downloading https://files.pythonhosted.org/packages/b6/ae/e6d731e4b9661642c1b20591d8054855bb5b8281cbfa18f561c2edd783f7/meld3-1.0.2-py2.py3-none-any.whl
Installing collected packages: meld3, supervisor
  Running setup.py install for supervisor ... done
Successfully installed meld3-1.0.2 supervisor-3.3.5
А поднапрягшись с поиском по ветке теме найдете готовые конфиги .....

И еще раз тут не форум и не ветка форума по основам линукс систем , разбору "ошибок" сторонних пакетов и систем, а так же повышения знаний по всем вопросам .... По dd-wrt есть тоже форум ;) Меньше ТУДА пишите, больше читайте ТАМ ! Читать - это полезно, особенно задумываясь над прочитанным

5
Все вокруг п******ы,
С половины .... хотя нет ... процентов 80 .... ибо не хотят ни читать , ни вникать, ни знать ... фантазии одни ...
ибо НЕ владеют , а уж тем более НЕ понимают ....  НО! "Философствуют" со знанием дела  ;)

p.s. Не стоит все воспринимать на свой счет ..... но я Вам ДВАЖДЫ повторил где НЕ работает и из-за чего в конкретно Вашем случае ....
РАЗ - http://mytalks.ru/index.php?topic=4506.msg88460#msg88460
ДВА - http://mytalks.ru/index.php?topic=4506.msg88465#msg88465
Но Вы продолжаете цитировать комментарии из исходников psutil ни на секунду "не понимая/не задумываясь" о чем там речь. Главное ссылочку запостить и "вывод" о ядре в dd-wrt ... КОМУ ? ЗАЧЕМ ?

ТРИ - дело именно в "кривизне" содержимого файла /proc/meminfo ( http://mytalks.ru/index.php?topic=4506.msg88465#msg88465 ) в вашей системе . Ибо вывода команды free внутри данного файла быть НЕ должно
-bash-4.4# free -b
             total       used       free     shared    buffers     cached
Mem:        256004     178164      77840          0      29660      59084
Swap:            0          0          0
-bash-4.4# cat /proc/meminfo
MemTotal:         256004 kB
MemFree:           77076 kB
Buffers:           29684 kB
Cached:            59124 kB
SwapCached:            0 kB
Active:           111720 kB
Inactive:          26676 kB
Active(anon):      49668 kB
Inactive(anon):      160 kB
Active(file):      62052 kB
Inactive(file):    26516 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB

ЧЕТЫРЕ - куда писать "философские" трактаты я Вам тоже намекнул ....

6
В новых ядрах есть строка MemAvailable, а в dd-wrt 3.10 ядро.
И что ?

Вам это:
        for line in f:
            fields = line.split()
            mems[fields[0]] = int(fields[1]) * 1024[/quote]
О чем-то говорит ? 
Для "фантазеров", слабо владеющих английским, ОПЕРАЦИЯ в ПЕРВОЙ строке возникающая в результате "парсинга" ВАШЕГО файла /proc/meminfo вида 
used: * 1024
которая получается в результате выполнения вот этих ДВУХ строк кода
            fields = line.split()
            mems[fields[0]] = int(fields[1]) * 1024[/quote]
НЕ ДОПУСТИМА НИ В ОДНОЙ ФАНТАЗИИ ни в одном языке программирования ... ибо строку "used:" НЕВОЗМОЖНО умножить на число 1024 о чем Вам "благополучно" и "настойчиво" сообщает лог прокси вот тут - http://mytalks.ru/index.php?topic=4506.msg88458#msg88458 ....

КАКОЕ 3.10 ? А ?

ЗАКРЫЛИ ТЕМУ ! ВАМ - на форум по dd-wrt "фантазировать" , тут форум и ветка форума НЕ про ЭТО

7
        total:    used:    free:  shared: buffers:  cached:
Mem:  242569216 59752448 182816768        0  5726208 38850560
Swap:        0        0        0
MemTotal:         236884 kB
MemFree:          178532 kB
MemShared:             0 kB
Buffers:            5592 kB
Cached:            37940 kB
SwapCached:            0 kB
Active:            20144 kB
Inactive:          25528 kB
Active(anon):       2136 kB
Inactive(anon):        0 kB
Active(file):      18008 kB
Inactive(file):    25528 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        131068 kB
HighFree:          90664 kB
LowTotal:         105816 kB
LowFree:           87868 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2140 kB
Mapped:             2748 kB
Shmem:                 0 kB
Slab:               9124 kB
SReclaimable:       2856 kB
SUnreclaim:         6268 kB
KernelStack:         312 kB
PageTables:          252 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      189504 kB
Committed_AS:       4800 kB
VmallocTotal:    1015800 kB
VmallocUsed:         256 kB
VmallocChunk:    1003784 kB
я правильно понимаю что сделал cat /proc/meminfo ? Если да, то данный файл "не в стандарте" что это за три первых строки?? .... Пишите письма на форум по поддержке dd-wrt

8
Можно отключить мониторинг RAM в конфиге? Мне это значение особо и не нужно, главное видеть что с трансляцией
Да . Лезьте в исходники /stat и отключайте ... точнее задайте какие-то фиксированные значения , например НОЛЬ , иначе прийдется Вам кроме освоения кода на питоне еще вникать в js и html  ;) 

p.s.  /proc/meminfo  покаж из своего dd-wrt

9
  File "/opt/lib/python2.7/site-packages/psutil/__init__.py", line 2051, in virtual_memory
    ret = _psplatform.virtual_memory()
  File "/opt/lib/python2.7/site-packages/psutil/_pslinux.py", line 404, in virtual_memory
    mems[fields[0]] = int(fields[1]) * 1024
Никаким боком к проксе не относится .. Все вопросы к своей  "операционке" и функционалу psutil ... дело в том что инфо по RAM ищется вот так в исходниках psutil
        mems = {}
        with open_binary('/proc/meminfo') as f:
            for line in f:
                fields = line.split()
                mems[fields[0]] = int(fields[1]) * 1024
Подозреваю что у Вас   - /proc/meminfo - содержатся строки значений с '.' вместо целых значений в Kb вот оно и "гавкает" так что "озадачьте" создателей dd-wrt чтобы они формировали значения в /proc/meminfo в целых значениях БЕЗ точки-разделителя ;)

Еще одна трабла. На роутер повесил tvheadend сервер. Он каким то образом мешает жить проксе. При запущеном TVH прокси не видит движок который расположен на другой машине, но в локальной сети роутера. Останавливаю TVH сервер и после прокси видит движок. В конфиге прокси адрес движка естественно прописан. Телнетом с роутера порт движка при запущенном TVH бьется. Мистика какая-то
Спасение утопающих - дело рук самих утопающих
На роутере нет swap'а
И что ?

10
Установил проксю на роутер RT-N66U с dd-wrt, entware отсюда http://bin.entware.net/mipselsf-k3.4. Трансляция работает, но статистика нет. В лог падает Plugin exception: ValueError("invalid literal for int() with base 10: 'used:'",) Ставил по этой инструкции http://mytalks.ru/index.php?topic=4506.msg77261;topicseen#msg77261 Проблем во время установки практически не было. Только это в конце упало в консоль There are no *-dev packages in Entware(with few exceptions)!, но не думаю что из-за этого ошибка со статистикой. Как можно исправить?
Дико извиняюсь .... а исходники прокси с гита ? ... дело в том что в текущих исходниках в  stat нет даже намека на озвученную вами ошибку
раскомментируйте вот так в acehttp.py
        # Handle request with plugin handler                                                                                                                 
        if self.reqtype in AceProxy.pluginshandlers:                                                                                                         
           try: AceProxy.pluginshandlers.get(self.reqtype).handle(self, headers_only)                                                                       
           except Exception as e:                                                                                                                           
              import traceback                                                                                                                             
              logger.error(traceback.format_exc())                                                                                                         
              self.dieWithError(500, 'Plugin exception: %s' % repr(e))
И еще раз поймайте эту же ошибку

11
p.s. http://mytalks.ru/index.php?topic=4506.msg88309#msg88309  -  В ForkPlayer нажать КРАСНУЮ кнопку пульта телика затем - НАСТРОЙКИ - НАСТРОЙКИ ПРИЛОЖЕНИЯ - ТАЙМАУТ ПЛЕЕРА - и выставить , например 55 сек ? ну или 60 чтобы отключить вовсе ?
Отвечал Вам ранее в личку, что 50, что 55, что 60 абсолютно не изменяет картину - "КИНА НЕМА", только при 60 с. переподключение не происходит.
Лог где при таймауте в 55 сек? В котором будет видно что плеер таки держит заданную паузу ..Зачем мне "сказки"? Мне кроме логов ничего не нужно, рассказы - то девочкам "по весне".... Если в логе будет буфферизация более 55 сек , то при чем тут прокся? Копайте в сторону своего провайдера. Если при выставленном таймауте в 55 сек отвал будет ранее - добро пожаловать на форум по форкплееру, при чем тут прокся если плеер отваливается ранее заданного в его настройках таймаута? Прокся что взяла от движка то и отдала , "от себя" ничего не добавляет ... У меня  в эксплуатации Samsung и LG разных моделей ForkPlayer работает сутками напролет не затыкаясь на точно такой же проксе .... Может таки в  Skyworth 32E3 чет поправить надо ? а ? Это "некая экзотика"  на  ОС Opera Smart TV мало ли что там китайчики недореализовали .... ПРОКСЯ ТУТ ПРИ ЧЕМ ?

p.s. переподключение - это функционал плеера, а не прокси.... Включите оттplayer вместо форка ... И будет тоже переподключение  ;) прокся тут каким боком? На компе где у Вас прокся с движком "крутятся" в VLC все показывает? Не мрет?  Вы не с тем боретесь....
p.s.s. НЕ используйте эту проксю .... Есть альтернативы (например - http://mytalks.ru/index.php?topic=6716.0 ПРЕКРАСНЫЙ ПРОДУКТ) , попробуйте их. Они пользуют HTTP API движка и там есть некоторые отличия .... Попробуйте встроенную в движок родную проксю ....

12
скорей всего плеер шлет запросы на http://127.0.0.1:6878/content  измени на локальный адрес прокси с плей листом, должно все заработать.
Не стоит ... это ПРОКСЯ обращается к движку , а у него что прокся что движок на одном компе ....

Мистика продолжается, HD каналы отлично показывают, SD обрываются каждые ~2-5 мин. Пробовал трансляцию в hls - обрыв стабильно через 100 сек любых каналов, что это может быть?
Ничего мистического ... Вот кусок Вашего лога с 632 страницы где "само" померло
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:36] <<< STATE 3
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:36] <<< STATUS main:buf;0;0;0;0;262;0;237;9;0;22806528;0;12353536
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:36] <<< EVENT livepos last=1549436252 live_first=1549434452 pos=1549436251 first_ts=1549434452 last_ts=1549436252 is_live=1 live_last=1549436252 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:37] <<< STATUS main:buf;0;0;0;0;261;0;234;16;0;23068672;0;12533760
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:37] <<< EVENT livepos last=1549436254 live_first=1549434454 pos=1549436251 first_ts=1549434454 last_ts=1549436254 is_live=1 live_last=1549436254 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:38] <<< STATUS main:buf;17;0;0;0;261;0;246;8;0;23330816;0;13025280
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:38] <<< EVENT livepos last=1549436255 live_first=1549434455 pos=1549436251 first_ts=1549434455 last_ts=1549436255 is_live=1 live_last=1549436255 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:39] <<< STATUS main:buf;17;0;0;0;261;0;248;8;0;23592960;0;13320192
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:39] <<< EVENT livepos last=1549436256 live_first=1549434456 pos=1549436251 first_ts=1549434456 last_ts=1549436256 is_live=1 live_last=1549436256 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:40] <<< STATUS main:buf;17;0;0;0;260;0;240;8;0;23855104;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:40] <<< EVENT livepos last=1549436257 live_first=1549434457 pos=1549436251 first_ts=1549434457 last_ts=1549436257 is_live=1 live_last=1549436257 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:41] <<< STATUS main:buf;17;0;0;0;247;0;228;7;0;23855104;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:41] <<< EVENT livepos last=1549436258 live_first=1549434458 pos=1549436251 first_ts=1549434458 last_ts=1549436258 is_live=1 live_last=1549436258 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:42] <<< STATUS main:buf;29;0;0;0;241;0;217;7;0;23969792;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:42] <<< EVENT livepos last=1549436259 live_first=1549434459 pos=1549436251 first_ts=1549434459 last_ts=1549436259 is_live=1 live_last=1549436259 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:43] <<< STATUS main:buf;29;0;0;0;248;0;206;7;0;24379392;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:43] <<< EVENT livepos last=1549436259 live_first=1549434459 pos=1549436251 first_ts=1549434459 last_ts=1549436259 is_live=1 live_last=1549436259 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:44] <<< STATUS main:buf;29;0;0;0;236;0;196;6;0;24379392;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:44] <<< EVENT livepos last=1549436261 live_first=1549434461 pos=1549436251 first_ts=1549434461 last_ts=1549436261 is_live=1 live_last=1549436261 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:45] <<< STATUS main:buf;41;0;0;0;231;0;187;6;0;24526848;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:45] <<< EVENT livepos last=1549436262 live_first=1549434462 pos=1549436251 first_ts=1549434462 last_ts=1549436262 is_live=1 live_last=1549436262 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:46] <<< STATUS main:buf;41;0;0;0;225;0;178;8;0;24641536;0;13402112
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:46] <<< EVENT livepos last=1549436263 live_first=1549434463 pos=1549436251 first_ts=1549434463 last_ts=1549436263 is_live=1 live_last=1549436263 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:47] <<< STATUS main:buf;41;0;0;0;251;0;174;9;0;25427968;0;13500416
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:47] <<< EVENT livepos last=1549436264 live_first=1549434464 pos=1549436251 first_ts=1549434464 last_ts=1549436264 is_live=1 live_last=1549436264 buffer_pieces=15
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:48] <<< STATUS main:buf;64;0;0;0;239;0;171;6;0;25427968;0;13631488
aceclient.py         [LINE:203 ]# DEBUG    [06.02 08:57:48] <<< EVENT livepos last=1549436265 live_first=1549434465 pos=1549436251 first_ts=1549434465 last_ts=1549436265 is_live=1 live_last=1549436265 buffer_pieces=15
acehttp.py           [LINE:227 ]# INFO     [06.02 08:57:49] Streaming "Дом кино" to 192.168.0.102 finished
Сравните его с моими пояснениями для TiviMate вот тут - http://4pda.ru/forum/index.php?s=&showtopic=933497&view=findpost&p=82358682 Ничего не напоминает ?[06.02 08:57:49] - [06.02 08:57:36] = 13 сек ....  ;) Плеер Вашего телика САМ закрывает соединение если не получает данные в течении 12-13 сек .... Кроме как увеличить read timeout  плеера ЭТО никак не победить ..... Никакие videoseekback и прочие танцы с бубном НЕ помогут ... Как только НА ЛЮБОМ канале, HD или SD, движок уйдет в STATE 3 (BUFFERING) и этот режим затянется более чем "встроенный" read timeout Вашего плеера - то все .... КИНА НЕМА ....     

p.s. http://mytalks.ru/index.php?topic=4506.msg88309#msg88309  -  В ForkPlayer нажать КРАСНУЮ кнопку пульта телика затем - НАСТРОЙКИ - НАСТРОЙКИ ПРИЛОЖЕНИЯ - ТАЙМАУТ ПЛЕЕРА - и выставить , например 55 сек ? ну или 60 чтобы отключить вовсе ?

13
По поводу плеера TiViMate - с движком работает криво. Подтверждаю. Попробую поиграться с размером буффера live, но сомневаюсь, что поможет.
http://4pda.ru/forum/index.php?showtopic=933497&st=300#entry81593237
Я вечером гляну ... не думаю что это трабла прокси ... Скорее всего плеер не закрывает сокет  при переключении на следующий канал или попытке рекконекта из за таймаута неполучения данных на текущей трансляции. Он там скорее всего манюсенький. Прокся же, в свою очередь, закрывает соединения через 15 сек после того как плеер перестал принимать данные если сокет не закрыт... Вот и возникает ситуация когда этот "чудо-плеер" долбит как дятел проксю не закрывая предыдущие коннекты , а прокся их отключит через 15 сек ... Отсюда и лог в проксе о максимальном пороге подключений.... Задайте там автору простой вопрос какой таймаут у данного плеера по не получению данных после которого он делает рекконект ... думаю что сек 5 .... если он его сделает более-менее "стандартным" , например как на пеерах Samart теликов - 30 сек .. то все заработает аж бигом ....  Специфика движка такова что во время буфферизации данных он не отдает ни байтика на 6878 порту и если время буфферизации превысит таймаут ожидания данных у плеера , то ...... имеем то что имеем с TiViMate. Я бы в TiViMate сделал настройку , например, "восстанавливать соединение при обрыве" ... + увеличил паузу реконнекта для определения отсутствия данных  .... Если убрать галочку - то нет рекконекта .... В таком случае прокся и движок с его встроенной проксей нормально бы работали с данным плеером + нормуль было бы с другими источниками требующими функции рекконекта

p.s. Таймаут отключения "подвисших" сокетов в 15 сек в проксе можно поменять ... но тут тоже есть специфика. Поскольку прокся выдает в Transfer-encoding: chunked , то время не должно быть меньше чем время "впихивания" одного чанка в плеер (максимальный возможный размер чанка 1Мбайт), а учитывая то что у разных плееров разный размер "собственного" буфера данных, да и еще то что одну и ту же трансляцию может смотреть хоть 10 разных плееров одновременно, а еще кто-то из этих 10-ти "умудриться" поставить на паузу live трансляцию, то 15 сек - оптимальное время "синхронизации" всех этих "параметров"  ::) чтоб у всех все работало и прокся отключала в случае чего "тугодумов"

14
Во все плагины добавлена поддержка и анализ заголовков 'last-modified' во избежание "дятлования" источников. Изменения на гите.

15
Стоит у меня прокси вместе с официальным движком в докер контейнере, более менее работает.
Решил попробовать новую версию с движком acestream_3.1.33.1_x86_wbUI.tar.gz переключал каналы ....
И тут
                                                                                                                                                                                                                                             CID, self.channelName = AceProxy.clientcounter.idleAce.GETINFOHASH(self.reqtype, paramsdict[self.reqtype], self.sessionID, paramsdict['file_indexes'])                                                                                                                                                                 
AttributeError: 'NoneType' object has no attribute 'GETINFOHASH'                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                           Вот тебе бабушка и Юрьев день. Приплыли. Больше не принимает соединения....
Это лечится?
Это в принципе не должно возникать и говорит о том что движок "помер" или прокся его "не видит". Но и это не должно вызывать такую ошибку ....  Есть два варианта решения "оживить" движок:
1) Авторестарт движка самой проксей для этого acespawn = False
2) Если acespawn=False, то использовать различные доступные "шедулки" для рестарта движка, типа systemd или supervisord
Мне не удалось повторить такую ошибку у себя никак :( Мне надо или более полное описание как этого добиться и более полный лог + aceconfig.py .... Лучше в личку в виде ссылок на pastebin.com 

Страницы: [1] 2 3 ... 143