Подтверждаю, в описанном сценарии игнорирует. Нужно будет уточнить, это поведение касается в целом беты, или только виндовой ее версии.
Если переименовать/удалить .pickle файлы, и запускать движок как “ace_console.exe --client-console @ace.conf” (где ace.conf - это пользовательский конф-файл со всеми необходимыми ключами), то все работает как ожидается.
Подтверждаю, в описанном сценарии игнорирует. Нужно будет уточнить, это поведение касается в целом беты, или только виндовой ее версии.
Последние версии AceStream всё ещё игнорируют параметры, прописанные в acestream.conf, которые появились в GUI. Ни время буфера, ни расположение кэша в acestream.conf теперь не настроить. Планируете вернуть эту возможность? Держать все настройки в одном файле конфигурации гораздо удобнее.
Да, потому что это не баг, но фича - см. Ace Stream 3.1 for Ubuntu (ru/en).
Т.е AceStream игнорирует эти параметры не потому, что они в ГУИ появились, а потому, что настройки из ГУИ хранятся в “.pickle” файле. А “раньше все работало” просто потому, что их там не было физически.
Пока мы не планируем менять систему приоритетов, но в будущем это не исключено.
Если же кому
то следует запускать файл “ace-console.exe” с указанием пути к “.conf” файлу (не забыв удалить созданный через ГУИ “playerconf.pickle” файл).
Странно, что acestream.conf игнорируется, даже если удалить все настройки AceStream и .pickle-файл в том числе. Я понял, что .pickle стоит выше в приоритете чем acestream.conf, но почему даже при отсутствии .pickle-файла AceStream не берёт настройки из acestream.conf? Это было бы логично.
Систему приоритетов менять не надо, достаточно сделать, чтобы при отсутствии .pickle-файла настройки брались из acestream.conf.
Не “берет” потому, что при запуске движок создает .pickle с дефолтными настройками.
По этому вопросу я солидарен - логичнее, если движок будет не просто создавать дефолтный .pickle-файл, но читать настройки из .conf-файла (как минимум, при явном указании оного). Заявка программистам отправлена, посмотрим, изменится ли чего в свежих сборках.
Спустя столько времени ничего не изменилось… Есть ли надежда, что разработчики сделают так, чтобы при отсутствии .pickle-файла настройки программы брались из acestream.conf?
И ещё, выполняем следующие действия:
Нажимаем Очистка папки кэша в GUI — папка acestream_cache удаляется
Выходим из Ace Stream — папка acestream_cache создаётся заново
Зачем Ace Stream создаёт папку кэша заново при выходе? До версии 3.1.20 всё было нормально.
Раньше при нажатии Очистка папки кэша и выходе из Ace Stream папка с кэшем полностью удалялась и не создавалась заново, но начиная с версии 3.1.20 после выхода из программы приходится удалять acestream_cache каждый раз вручную. Нельзя ли сделать как было?
Надежда, как известно, умирает последней =) Баг по этому вопросу /давно/ создан, но сейчас в принципе десктопная версия “положена под сукно” - все силы на Андроид и серверный бекенд брошены.
А чем мешает пустой каталог - или “внутренний перфекционист” спать не дает? На заметку возьмем, конечно, но приоритет здесь еще меньший, чем у багофичи с конфигами.
Ну а зачем мне нужна эта пустая папка в корне диска, если я Ace Stream раз в неделю запускаю? Раньше было как: попользовался Ace Stream, очистил КЭШ и никаких посторонних папок нет.
Есть ещё такой вопрос: где можно список всех версий Ace Stream для Windows посмотреть? Особенно интересует, было ли что-нибудь между версиями 3.1.16.3.1 и 3.1.20?
Вообще-то вариантов более чем достаточно - включить дебаг-лог в движке, если без этого в логе не видно CID/infohash; без лога - удалить все файлы из collected_torrent_files, и запустить трансляцию - в кеше должен быть искомый транспортный файл (можно и не удалять, а отсортировать по времени, но если кеш забит и CID “старый”, то среди сотен файлов искать его можно долго), можно включить/смотреть дебаг JS в консоли браузера, снифферить трафик на локальном интерфейсе и т.д.
Как я понял, названия этих транспортных файлов — это INFOHASH? В итоге достал ContentID через Медиа-сервер, выбрав ДОБАВИТЬ КОНТЕНТ и указав INFOHASH. Также можно выбрать сам транспортный файл через Медиа-сервер и получить ContentID.