Подзапустил тему.
1. В схему работы - самое главное что бы прокси имея хотя бы один байт, тут же его отдал клиенту. Ничего не буферил. Остальное не так важно.
2. HLS же прокси формирует? Почему от "hls или ts" зависит аудио?

1) так и есть .. байт в байт , как только получили - сразу отдали ...

по состоянию на этот момент алгоритм работы такой :
1) При старте трансляции пытаемся "паковать" в буфер трансляции по максимуму сколько движок отдает по текущему каналу чанками по 8192 байта....
2) На клиента сразу начинаем выдавать чанки из буфера трансляции без всякой задержки ... параллельно ...

О! И еще , кроме отсутствия видео на каналах и наличия звука .. .Очень часто при старте наблюдается вот такое "кино"
https://b.radikal.ru/b26/1805/ef/b8a2ef5a74dd.png
https://a.radikal.ru/a31/1805/e9/53dca44ad753.png
Часто если стартануть повторно тот же канал то стартует .. правда при этом ...

А не должен ли при этом плеер при этом ещё и соврать, что у него идёт васпроизведение

Не, не нужно.
Похоже, я дезинформировал общественность, утверждая, что прокси закрывает соединение, если у нее долго не кто не забирает поток, вчера как раз обсуждал этот момент с Dorik...
Соединение ...

А почему пропадают звуковые дорожки? Даже если они через hls то ProgTV их должен уметь?

Подскажите как по http ответу можно определить этот прокси?

1) Пропадание звуковых дорожек, точнее "оставляние" только одной нужной - это особенность работы acestream engine при выборе типа потока в hls ...

Парни .. я убрал это "жизнеописание" и добавил пару строк логгирования в проксю ... таки да .. есть каналы на которых подкачка идет архимедленно на старте .... и 1000 чанков - не успеваем накачать ни при каких раскладах ... Сча сижу сушу голову как "надуть" буфер и автоматом поддерживать его в ...

........
Может нужно увеличить last, а то движок не успел получить его новое значение и считает, что поток закончился?
Может Надо открыть талмуд по движку - wiki.acestream.org , или поставить себе https://www.wireshark.org , потратить 10-15 минут "пялясь" в логи и НЕ писать фантазии на тему "Есть ...

Лично у меня версия с увеличенным таймаутом реконнекта - работает при "рекомендованном" буфере в 8Мбайт... если не считать отсутствие видео на каналах .. есть только звук ... Причем тип потока OpenMAX определяет одинаково как там где показывает так и там где есть звук и нет картинки... Ниже слайды ...

Выше есть версия которая >40с ждёт. Отдельно настройки нет, их там несколько на разные случаи. Нужно каким то образом прокси отнести к "длительным" случаям.
Качнул .. щас поиграюсь ... а как быть с отсутствием видео на проце Quallcomm Snapdragon 835 ? При АБСОЛЮТНО одинаковых настройках с одной и ...

Не поможет буфер. если таймшифт увеличить то сколько угодно провалится в него.
Я вот подумал, что в http наверяка есть заголовок максимального времени ожидания. Не помню на вскидку и не поддерживаю, но это был бы выход.


Дык этот заголовок прокся "чудесным" образом отдает клиенту ... я буквально ...

Не очень понимаю. Да ProgTV качает всё что дают и считает соеденение разорванным если не дают больше N секунд. Это никак не зависит от состояния буферов внутри (которых несколько, включая ограниченый размером флеши timeshift). То есть факт разрыва соеденения никак не зависит от того сколько байт ...

OpenMAX это часть прошивки - и даже не знаю какой там размер буфера. Но не маленький.
Проблема в том что ProgTV 12-15 секунд не видит ни байта трафика и перезапускает соеденение. Причём выше была тестовая версия с 3x большим значением timeout-а и тоже не помогло.
Нужно передавать трафик более ...

Вы автор прокси? Отлично. Ну тогда должны разобраться.
Openmax отличается тем что много трафика набирает в свой буфер, который я не контролирую.
Вопрос, почему нет трафика с прокси так долго? Нет на входе или где то кешируется в прокси? В идеале бы ему работать "байт получил - байт передал ...

Сервер действительно не отдаёт трафик по 12-15 секунд, потом ProgTV обновляет соеденение. В принципе такие большие задержки для torrent tv - это нормально. То есть плохая работа самого torrent tv - это нормальное его(!) состояние. Если интересно сделаю версию с более длинным ожиданием.

С другой ...