Когда открываю плейлист, AcePlayer начинает грузить их . Идут запросы типа
s1.torrentstream.info/gettorrent?_n=3.1.2&_r=697233358&_v=3003800&pid=…&_s=…
по одному. Если в плейлисте сотня ссылок, загрузка занимает продолжительное время.
Как это отключить, чтобы он грузил, только ту ссылку, которую я собираюсь смотреть?
В настройках выставлено:
playlist-autostart=0
ace_player каким-то макаром парсит строку в плейлисте на предмет .acelive и через WS2_32.send отправляет ссылку в ace_engine. ace_engine уже пытается скачать файл LOADASYNC.
Причем , если ace_player в момент открытия плейлиста не прочитает файл (напр. отключен LAN-кабель), то повторно оно уже не может его прочитать.
Кто придумал такую бестолковую логику? Если у пользователя 100 ссылок в плейлисте, но он будет смотреть 1 канал, то прога будет бесполезно парсить и качать , замедляя работу компьютера и давая ненужную нагрузку на канал связи.
Не “не может”, а “не хочет”, и это было сделано специально - таким образом при открытии плейлиста отсеиваются “мертвые” ссылки.
Как бы не отрицая, что работа с плейлистом могла бы быть и более “логичной”, и основная проблема в том, что чем больше элементов в подобном плейлисте, тем больше времени нужно на запуск первого канала, следует отметить, что:
человек, который в принципе качает/открывает ради просмотра 1 канала плейлист с 100 каналами - ССЗБ;
“замедление компьютера и нагрузку на канал связи” в случае пользователя даже не стоит упоминания. При открытии подобного плейлиста для каждого элемента оного скачивается транспортный файл размером около килобайта. “Нагрузку на канал связи” для 100 таких файлов не сложно посчитать самостоятельно - курс математики для средних классов. А потом сравнить полученные значения с битрейтом одного даже не “HD” канала из этого самого плейлиста, и ужаснуться выросшей в разы “нагрузке на канал связи”.
А вот уже в нашем случае (запросы/скачивание транспортных файлов с серверов) эти “килобайты” при тысячах пользователей превращаются в реальную проблему, и таки с этим нужно будет что-то делать, благо сейчас большинство использует плейлисты с “http://” ссылками к движку, для которых описанная проблема не актуальна.
Так проверка всех ACE Stream ссылок в плейлисте через ACE Stream Engine никак не отключается? Это неудобно! Для примера - экспериментальный плейлист от сайта Торрент-ТВ в формате xspf с архивом. Даже если грузить только избранные каналы (5 шт.), то с архивом получается 50кБ и под 130 ссылок. И, естественно, загрузка занимает ощутимое время. Я уже не говорю про полный плейлист на 1400 каналов - его я даже и не проверял.
P.S.
Ссылки имеют вид http://[…].acestream.
Тема про плеер, а не про движок.
И если в случае с плеером лично я согласен с претензией, что нет смысла при открытии плейлиста проверять все позиции в нем, то в случае движка (импорта плейлиста в медиа-сервер) это просто необходимо, иначе ломается логика работы многих фич (включая “автопоиск”).
Неудачно сформулировал. Я про плеер и пишу - медленно открывается плейлист с acestream ссылками. Как я понял, происходит проверка каждой ссылки движком.
Да, это известный фичебаг, и он врядли будет правиться до того, как мы созреем пересобрать плеер со свежей версией VLC.
В случае с плейлистами из ЛК ТТВ есть как минимум два варианта:
обработать скачиваемый плейлист самому (вручную или автоматизировав этот процесс), добавив в начало каждой ссылки “http://127.0.0.1:6878/ace/getstream?url=”, например - тогда его можно будет открыть в обычном VLC. А если после конвертнуть этот плейлист в M3U, то оно вообще в любом плеере будет открываться.
использовать сторонний прокси (Форум ТВ), там давно это все реализовано.
Можно попробовать написать в поддержку ТТВ, чтобы они добавили больше опций при генерации плейлистов в ЛК (как это сделано на сайте той же “помойки”, например). Но, учитывая, что до сих пор этого нет, то либо не актуально, либо это сознательный отказ от.