Да я бы с удовольствием, но у меня самого такой проблемы не наблюдается. Постараюсь, конечно, еще раз помучать человека и предоставить вам логи работы движка и взаимодействия моего приложения с ним. Но, с другой стороны, логи - это хорошее подспорье, но разработчик движка, обладая знаниями о специфике реализации HTTP API и буду информированным о такой вот проблеме, может провести анализ кода и проверить некоторые предположения даже без лог-файлов.
Смотрите, некоторые еще пишут, что не наблюдают зацикливания при использовании VLC, а вот при использовании MX Player - наблюдают. Это раз.
И я указал, что при использовании старого протокола, зацикливаний нет, а при использовании нового - есть (у человека как раз был mx player). Нюанс тут в том, что при использовании старого протокола, я пропускаю запросы плеера через свой "прокси"-сервер, который со стороны плеера гарантирует прием сколь угодного множества запросов, а на стороне движка гарантирует лишь один запрос от своего имени по указанной движком ссылке воспроизведения. Это два.
Давайте теперь попробуем агрегировать всю эту информацию.
Что объединяет "VLC+новый протокол" и "mx player+старый протокол"? То, что в обоих случаях движок получает один и только один запрос от того, кого он считает плеером. Да, это известный плюс VLC - он не делает двух одновременных запросов. Если и надо, то последовательно.
Итак, на данном этапе можно сказать, что когда на движок всегда прилетает лишь один запрос от плеера, то проблем нет, независимо от того, какой api движка был задействован.
А вот когда включаешь mx player и скармливаешь ему ссылку полученную от нового апи, то ИНОГДА возникают зацикливания. Почему ИНОГДА. а не всегда? Потому что, я заметил, что на разных устройствах тот же mx player по-разному атакует сервер запросами. И в тоже время нам известно, что ссылка, которую выдает новый HTTP API допускает одновременные запросы от одного плеера. Допускаю, что это стало возможным благодаря каким-то специальным усилиям, условно говоря, вы реализовали свой собственный "прокси", который принимает N запросов от плеера и отправляет лишь 1 запрос туда, где осуществляется выдача контента. И возможно, что в этом вашем алгоритме закралась ошибка. Может быть это что-то связанное с заголовком Range, в запросе от плеера?
