-
В версии a5, в настойках бродкастинга добавлены параметры позволяющие задать количество слотов. Укажи для теста количество, которое будет = (равно) ( исходящая скорость канала - (минус)20%) / ( разделить) на средний битрейт трансляции. Это будет оптимальное значение, которое тебе по максимуму загрузит исходящий канал. P.S. Учитывая нестабильность домашнего интернета не рекомендую ставить под потолок. Собственно основная задача теста это стабильность трансляции, а не забивка на полную канала. И если с домашнего компа, при 7-10 открытых слотах, при битрейте 1- 1,5 мбит/с , у всех будет все стабильно показывать, это и будет тот результат которого мы хотели добиться.
-
Таймшифт в этой версии отключен, так как в новой версии эта функция/логика также будет переписана.
-
Проблем с кадрированием не увидел.
Автообновление включено (закройте браузер и перезапустите движок)
Не получилось… 
В следующий раз попробую… 
…
Написал не туда, переспрошу: что там про обновления дял *nix’ов?..
Потестировал ещё, уже в качестве клиента, заметный результат версии 3.0. проявляется только после того как я изменяю “Макс. кол слотов” и жму на кнопку Применить.
До этого ситуация с отдачей видна на нижнем скрине, хотя количество слотов стояло практически такое же = 500.
Отсюда делаю вывод, что механизм чем-то блокирован до того момента пока не нажмёшь кнопку Применить. Такое же было я помню с ограничениями скорости ещё в самом начале, они не работали пока кнопку применить не нажмёшь. Чтобы ещё понятнее было объясняю: если я закрываю АСЕ плагин, открываю его снова, то даже если у меня стоят значения как до закрытия, они не работают, до тех пор пока я “Применить” не нажму.
Ещё мне очень не нравится, что отдача идёт кусками, то пусто, то густо и по моему это не правильно, а ещё говорит о том, что пиры “гуляют” и не “держатся” за хороший источник… впрочем подтверждение этому можно увидеть в любом анализаторе трафика.
с а1 у меня не обновлялся о чем писал… поставил в ручную а4. вчера автоматом обновилась до а5
Зачем же так грубо )) Перед тем, как писать, мы все проверили и убедились, что должно работать нормально.
Если у кого-то не работает автообновление, давай найдем причину.
Во вложении два файла. Нужно их положить в папку %APPDATA%\ACEStream. Затем запустить файл stop_updater.bat (он остановит менеджер обновлений, если он запущен). Затем запустить файл run_updater.bat (он запустит менеджер обновлений в режиме отладки). После этого пусть поработает около 30 минут, потом можно остановить, запустив файл stop_updater.bat. После этой операции будет создан лог %APPDATA%\ACEStream\updater\ace_update.exe.log. Вот его просьба выложить на форуме.
Не плохо бы в run_updater.bat добавить в начало start /min …
Ну и переименовать их в .cmd до кучи… 8)
Пур, я ведь уже написал что нас интересует этом этапе тестирования! Нас интересует как будет происходить распределение при большом количестве зрителей, и именно с настройками которые сейчас выставлены в клиенте по умолчанию. Не нужно их трогать! Когда будет нужно, мы скажем, и уж точно не нужно выставлять 500 слотов, если у тебя канал не меньше 1 Гбит/с, так как неправильные настройки кроме вреда больше ничего не принесут. Если есть возможность обеспечь массовку на какой-то трансляции под новым движком, будем очень признательны.
P.S. Я понимаю что многим пользователям не с руки переустанавливать софт, поэтому, в ближайшее время мы вероятнее всего включим этот тестовый режим в основной релиз, чтобы у пользователей была возможность смотреть трансляции и по старому протоколу и по новому.
Моё мнение, что вы выбрали изначально в корне не правильную методику для тестирования.
Есть очень простая и крайне эффективная метода:
Берём поток с постоянным битрейтом скажем в 4 Мбит/с, раздаём его через сервер АСЕ, шейпим его на скорости 6 Мбит/с и подключаем к нему 3-5 удалённых клиента. И всё, больше ничего не нужно, если в этом случае недостающий трафик будет нормально перераспределяться между 3-5 пирами, то вся система будет работать с любым масштабированием и любым количеством пиров.
Так вот, в моих тестах Линуксовые клиенты и серверы с этой простейшей задачей справлялись, а вот у тех же клиентов и серверов, но с виндовым софтом, были большие проблемы, если битрейт потока был значительно больше 1-2 Мбит/с, с чем это связано я не знаю, хотя и догадываюсь.
- Пур, если бы мы на таких тестах и еще на многих др.(причем более детализированных и с полным мониторингом поведения клиентов) видели проблемы с распределением и отдачей, то мы бы эту версию не выпускали даже в альфа-релиз (На большинстве машин у нас все дефолтное, как и обычных пользователей) Поэтому, нас сейчас не интересуют локальные микротесты, как и вопросы почему чья-то винда раздает лучше или хуже чем винда другого, а нас сейчас интересует картина в целом, и поведение разноплановых клиентов в общем пуле, чтобы трансляция обеспечивалась минимальными ресурсами/затратами и при этом у пользователей не возникало проблем с ее просмотров. Ну а к упомянутым вопросам мы вернемся тогда, когда мы увидим и проанализируем работу алгоритма в целом. А тесты на максимальную скорость отдачи с винды, ты в частности и другие бродкастеры могут провести путем увеличения количества конектов и слотов при указании параметров при создании трансляции.
В общем, нужны трансляции с большой массовкой и тогда уже будет что обсуждать!
- Если у тебя или у кого-то есть проблема с организацией трансляции из под винды с битрейтом свыше 1-2 мбит/с, дай знать и чуть позже попробуем с этим разобраться, так как это не общая проблема, а именно какая-то локальная. И если ты сомневаешься, то в качестве примера я могу организовать запуск тестовой трансляции из под винды с гораздо более высоким битрейтом. Ну и если есть какие-то предположения с чем это связанно, то конечно пиши, так как если такая проблема есть у тебя, то вероятно она есть еще и кого-то другого, и если это можно будет решить на стороне нашего софта, то мы это решим, а если мы увидим что это никак не относится к нашему софту, то тут уж мы ни чем не поможем.
P.S. Трансляция из под винды ID: 8be015424abf120b41f2fd18dcfdba6c24273a23 ( будет крутится пару часиков)
Проверил у себя… Буферит…
А вот эта проблема уже не винды, а маршрута. И вот если бы еще пару человек подцепилось с UA-IX, вот тогда бы у тебя не буферило, P.S. Собственно и проблему с маршрутами, при передачи данных от одного пира к другому можно решить, применив скайповскую схему, когда используются связующие/промежуточные пиры ( как прокси). Но учитывая что наша система рассчитана не на передачу данных между двумя пирами, а для организации трансляций для массовки (для большого количества зрителей), то это не актуально.
Я бы конечно принял версию с маршутизацией, но вот какая фигня получается: маршрутизация у меня одна и та же и не меняется, однако если я отдаю напрямую через VLC (без всяких там р2р в один поток), то у меня хоть 20 Мбит/с битрейт уходит к каждому клиенту, но стоит мне тот же стрим сделать на АСЕ в винде, у меня больше 1-2 Мбит/с почему-то не уходит, а если и бывает такое, то это скорее исключение чем правило, при этом стоит поставить линукс и начать раздавать с АСЕ - проблемы как и не было… Можно конечно всё свалить на кривого провайдера и его шейпы-шмейпы в р2р, но никаких шейпов нет, да и в сопке всё улетает к клиентам на ура через тот же р2р (однако с одной оговоркой, нужно запускать второй клиент).
Пур, ну значит не судьба тебе с винды транслировать, посмотрим как у других получится.
Какая у тебя проблема с раздачей из под винды я не знаю, так как проблема с маршрутизацией была на трансляции, ID которой я выложил, так как этот источник уж чересчур далековато находится от точек входа в мир. Ну а чтобы в этом убедится, то я завтра выложу трансляцию с этого источника, но только с узлом поддержки подключенным к ua-ix , и который имеет более-менее нормальный выход в мир. Вот тогда поглядим, маршрутизация это или нет.
P.S. У тебя при таких настройках, которые показаны в твоем скрине (с таким количеством разрешенных конектов) комп случайно не взорвался? ))) И зачем ты установил столько допустимых конектов и открыл столько слотов? Ты что хотел проверить на выносливость свою машину и на полную забить свой исходящий канал (проверить максимальную скорость отдачи)? Ты главное другим, менее экстремальным пользователям, не советуй такие настройки ставить! И пожалуйста, если будет какая-то массовая трансляция на 3.0, то верни взад все настройки ( поставь которые были по умолчанию) и если кто еще выставлял, то тоже верните, чтобы нам не приходилось выпускать спец. версию софта где это будет заблокировано наглухо, чтобы сейчас их никто вообще не трогал. А вот на следующем этапе, когда мы увидим что распределение работает так как нужно, тогда уже все вместе и поэкспериментируем с этими настройками, чтобы определить оптимальное соотношение конектов и открытых слотов, после чего мы сможем сделать опцию автоматической настройки( зависящей от битрейта трансляции и скорости исходящего канала пользователя) , которая будет работать по умолчанию у всех пользователей, что позволит по максиму использовать возможности пиров.
И конечно же, спасибо тебе за помощь и активное участие в тестировании новой версии!
Если совсем коротко, то - ДА
А так, каждый параметр выполняет свои определенные функции
Я правильно понимаю что в этой версии улучшения касаются только трансляций?
Т.е. если я например не смотрю трансляции, а только фильмы на трекерах, то эту версию можно не ставить?
Да, все верно, изменения касаются только прямых трансляций.
does the live option not work with alpha? many users telling me they click the live button and nothing happens
Резиз 3.0.0-a6
Включена авторегулировки конектов (соединений) и слотов (опция вкл. по умолчанию). Ручная настройка доступна, путем отключения авторегулировки в расширенных настройках клиента/движка ( Настоятельно не рекомендуем отключать авторегулеровку!)
Ручную настройку используете только для проверочных тестов максимальной скорости отдачи ( не ставьте количество слотов превосходящих трехкратный уровень битрейта, к скорости вашего исходящего интернет-канала. К примеру: если битрейт трансляции 3 мбит/с, а максимальная скорость вашего исходящего интернет-канала 50 мбит/с, то для такой трансляции не открывайте более 50 слотов)
При включенной авторегулировке, выставляется оптимальное значение конектов/соединений и слотов для каждой отдельной трансляции. Значения выставляются автоматически исходя из битрейта трансляции, максимальной скорости отдачи пользователя и процессорной мощности пользовательского устройства. Значения изменяются динамично во время трансляции ( динамику роста можно будет увидеть в расширенных опциях во время трансляции, если от вас будет идти хорошая отдача)
Если вы захотите попробовать в ручную поиграться этими параметрами, пожалуйста, не забудьте потом опять включить опцию авторегулировки (поставив галочку и нажав Ок/Применить)
Также в этой версии были устранены разные баги, и если в ближайшее время нами или вами не будут выявлены какие-либо др. критичные баги, то мы переведем ее в статус “beta” и подготовим так называемую “переходную версию” для массового обновления версии 2.* ( чтобы основная релизная версия также могла позволить осуществлять просмотр тестовых трансляций идущих по новому протоколу)