@m4zuper Вроде починил. Проблема была в антивирусе который жрал 30% оперативы
Выпущена 24.2.0 версия BrowserAutomationStudio
-
@DoctorKrolic Я уже отвечал и не раз на это. Если кратко. Помимо этого ограничения, есть еще и другие. Если их убрать, получим множество сообщений вида "запустил BAS, комп завис, помогла только перезагрузка", в том числе и на мощных ПК.
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Дело в том, что надо делать не ограничение по времени, а так чтобы не возникали никакие случаи таймаута или долгово ожидания.
Долгое ожидание происходит из-за того, как устроен CDP, а не из-за BAS. Я могу только добавить таймаут, что и будет сделано в следующих версиях.
У этой CDP сессии много проблем, отвалы, зависания, таймауты на ровном месте. Мы сами напишем костыли, не буду сострасять воздух.
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Чтобы этого избежать, нужно делать аналог PerfectCanvas только для audio. Это не является приоритетной задачей.
Ого как все плохо, тогда как будет апдейт по PerfectCanvas не забудьте тогда еще про webgl и аудио в придачу :D
-
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Мы сами напишем костыли, не буду сострасять воздух.
Я другого и не ждал. 200 раз написать о том, как все плохо - это пожалуйста, сообщить о проблеме, чтобы ее починили - не буду сотрясать воздух.
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Мы сами напишем костыли, не буду сострасять воздух.
Я другого и не ждал. 200 раз написать о том, как все плохо - это пожалуйста, сообщить о проблеме, чтобы ее починили - не буду сотрясать воздух.
Ну так я сообщил выше о проблеме таймаутов элементов. На что получил отписку, что все ок. "Особенности СDP сессии".
Зачем отвлекать по мелочам, там вон метрика собирается походу проверять канвас и веб гл на фейковость, будет наплыв юзеров с просьбой сделать сбор со своего сайта. -
@FastSpace В ответе, который вы получили было в частности
Для действия "Количество элементов" и "Проверить существование" действительно можно сделать ограничение по времени, скорее всего добавим в новом патче.
Также детальное описание почему так произошло.
То есть, ваш случай детально рассмотрели и пообещали исправить, а отписка, это стандартный ответ, который может даже не касаться вашего вопроса.
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
@FastSpace В ответе, который вы получили было в частности
Для действия "Количество элементов" и "Проверить существование" действительно можно сделать ограничение по времени, скорее всего добавим в новом патче.
Также детальное описание почему так произошло.
То есть, ваш случай детально рассмотрели и пообещали исправить, а отписка, это стандартный ответ, который может даже не касаться вашего вопроса.
И что это изменит? В том состоянии браузера даже если действие выйдет по моему заданному таймауту с браузером всю равно работать нельзя, пока не вылезет эта заглушка хромовская (this site can't be reached) новая и нормально не обработается.
Раньше в таких случаях BAS падал просто в белую страницу и с ней можно было нормально работать. Любые действия не вызывали долгих ожиданий или таймаута. -
@Игорь777 said in Выпущена 24.2.0 версия BrowserAutomationStudio:
@support по поводу тиктока, если честно проверять на 1-2 подписки... То так конечно все работает, но. Смотрите, заходим на аккаунт, делаем 10-20 подписок, конечно же с разумным таймингом... Потом если зайти на этот аккаунт скажем через час, в 95% вам уже не удается подписать или поставить лайк. Однако, если же зайти на этот же аккаунт через браузер на ПК, то я смогу в течении дня по 500 подписок сделать, к примеру делаю 50 подписок, даю отдохнуть аккаунту минут 40 и так в течении дня.
Специально провел эксперимент:
- Зашел в аккаунт из BAS, сделал 10 подписок.
- Подождал 2.5 часа.
- Открыл тот же акк через профиль(без авторизации).
- Проверил старые подписки, все сохранились.
- Поставил несколько лайков и добавил несколько новых подписок, опять все сохранились.
Все записал на видео:
https://www.youtube.com/watch?v=QXi-Ffai7IU пункт 1
https://www.youtube.com/watch?v=rrKWFtXjNm8 пункты 3 - 5
Список акков:
Вы можете посмотреть последний, там было 3 подписчика, стало 4 и это сохраняется в любом браузере.
Проблема может быть в том, что вы либо не используете PerfectCanvas, либо используете не тот запрос.
Обязательно нужно проверить лог PerfectCanvas и убедиться, что все замены произведены.
Когда я использовал запрос PerfectCanvas сгенерированный с CanvasInspector, то в части запросов на получение данных canvas замена не была произведена:
Возможно это из-за устаревшего браузера в CanvasInspector. Поэтому браузер был обновлен. Архив нужно перекачать.
Еще лучше использовать специальный модуль для получения запроса.
В любом случае, если вы посмотрите видео, там все работает идеально.
При возникновении проблем с tiktok, пишите на почту с детальной информацией и проектом.
-
И что это изменит? В том состоянии браузера даже если действие выйдет по моему заданному таймауту с браузером всю равно работать нельзя, пока не вылезет эта заглушка хромовская (this site can't be reached) новая и нормально не обработается.
Это изменит то, что действие вернет false и оно будет возвращаться мгновенно.
Я напомню, что изначально проблема была именно в этом:
Исправьте пожалуйста этот самый бесячий баг и костыля ему не придумал (
Случаи когда он возникают гораздо больше, но думаю из этого одного будет понятно что на самом деле там.
Просто любое маленькое браузерное действие возвращает ошибку таймаута (проверить существование, ява скрипт из 1 строки) и т.д.Дело в том, что надо делать не ограничение по времени, а так чтобы не возникали никакие случаи таймаута или долгово ожидания. Раньше в CEF во время загрузки страницы я вызывал действие "Количество элементов" или "Проверить существование" и оно мгновенно возвращало - ответ. Сейчас таймаут, либо долгое ожидание.
Тоже самое касается и действие проверить существование.А на деле - НЕ мгновенно.
Теперь оказывается, что проблема в том, что вы не сможете работать с браузером.
Ну тогда нужно смотреть в сторону флагов с рекконектом для сайта или features, которые тоже можно менять параметрами командной строки. Но это совсем другая проблема.
В чем состоит отписка в вопросе который вы задавали изначально?
Какой ответ был бы для вас приемлемым?
И чем он отличается от оригинального, который вас не устроил?
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
В чем состоит отписка в вопросе который вы задавали изначально?
Какой ответ был бы для вас приемлемым?
И чем он отличается от оригинального, который вас не устроил?
В том что нужно устранить наверно причину бага, а не его последствия.
Я думал это очевидно. -
@support Ну так и всё же в чём проблема запускать одновременно n процессов хромиума вместо 1? Пусть даже это будет и "экспериментальная" настройка с предупреждением о возможных последствиях её использования, но у юзера будет хотя бы минимальный выбор. То, что есть сейчас, слишком инерционно
-
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
В том что нужно устранить наверно причину бага, а не его последствия.
Напомню, баг в том что выполнение действие "Проверить существование" завершается не мгновенно на странице, которая не может загрузиться из-за прокси.
Вы говорите, что причина этого бага в том, что браузер тратит некоторое время на попытки установить соединение через прокси.
Я соглашусь, действительно можно так сказать.
Но проблема в том, что если убрать/сократить это время, мы получим другую проблему, на недостаточно качественных прокси сразу будет ошибка, соответственно скрипт сразу забракует его, и если подождать, то окажется, что этот прокси можно еще использовать.
Мое решение, просто сделать так, чтобы действие "Проверить существование" завершалось мгновенно, а страница продолжала грузиться не имеет таких проблем, кроме того, оно решает проблему заявленную изначально. Все таки Chrome умеет работать с сетью, не нужно ему мешать.
Но знаете, тут даже можно поспорить, кто-то скажет, не хочу долго ждать, у меня быстрые прокси.
Но вы все равно утверждаете "я описал проблему и толку, вы отмахнулись от меня отпиской".
Мне кажется, вы не замечаете того, что я искренне пытался помочь и дал вполне конкретный и практический ответ.
Вы очень любите критиковать, и это не является чем-то плохим. Но почему-то вы все равно продолжаете критиковать, даже когда для этого нет повода.
-
@DoctorKrolic Проблема в том, что даже со всеми оптимизациями(изменено больше 20 файлов специально для оптимизации, которые нужно мерджить при каждом релизе), браузер все равно не предназначен для того, чтобы создавать множество профилей одновременно.
Кто-то все равно включит эту настройку, забудет о ней, запустит скрипт, ПК зависнет, этот человек напишет, "запустил BAS, комп завис" и это в самой мягкой форме. Никто прикладывать проект и разбираться не станет. Поэтому я не буду этого делать.
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Поэтому я не буду этого делать
Жаль... Выпилите тогда хотя бы эту настройку, чтобы эти мёртвые куски в интерфейсе не мешались
Кстати, об оптимизации. Когда поток пытается загрузить какую-либо ссылку, он рендерит страницу и делает это, занимая максимально возможные мощность GPU. Из-за этого график использования GPU во время работы БАСа выглядит как зловещие пики потребления 0-100%. Если попадётся, что 2 потока одновременно что-то рендерят, то происходит лаг всей системы, так как в этот момент не хватает ресурсов GPU даже для отрисовки интерфейса ОС. Это происходит, например, когда 2 уже открытых потока загружают в себе новый url. Неплохо было бы сгладить потребление GPU, заставив, например, браузер "думать", что количество доступных вычислительных блоков меньше, чем оно есть на самом деле. Потому что как минимум такой режим работы явно не добавляет жизни видеокарте. + иногда по вышеописанной причине вызывает подлагивания
-
@support said in Выпущена 24.2.0 версия BrowserAutomationStudio:
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Мое решение, просто сделать так, чтобы действие "Проверить существование" завершалось мгновенно, а страница продолжала грузиться не имеет таких проблем, кроме того, оно решает проблему заявленную изначально. Все таки Chrome умеет работать с сетью, не нужно ему мешать.
Хорошо сделайте хотя бы так, потому что я даже эту заглушку не могу проверить вылезла она или нет.
Вот ее селектор и действие проверить существование может завершиться с таймаутом проверки этой заглушки, либо ждать ее лишних секунд 10-30-40, когда я могу перезагрузить страницу и скрипт наверно :) поедет дальше хорошо. В моем шаблоне нет лишних затупонов, лишних ненужных ожиданий, каждая секунда бота грелки продумана. Это единственное на что я не могу повлиять, ловлю долгие ожидания или таймауты на ровном месте.>MATCH>div id="cf-error-details"Хотя из вышесказанного я не понял каким образом установка собственного таймаута для браузерных действий поможет завершится мгновенно. Мне нужно всю равно ждать то количество секунд, которое я поставил.
-
@DoctorKrolic said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Жаль... Выпилите тогда хотя бы эту настройку, чтобы эти мёртвые куски в интерфейсе не мешались
Если профиль создается медленно, эта настройка имеет влияние.
Когда поток пытается загрузить какую-либо ссылку, он рендерит страницу и делает это, занимая максимально возможные мощность GPU.
Есть наверное более совершенные инструменты, но TaskManager Delux не показывает таких скачков
https://www.youtube.com/watch?v=x5j_cHZ85qk
https://www.youtube.com/watch?v=cF9tQmxxyy0
Если попадётся, что 2 потока одновременно что-то рендерят, то происходит лаг всей системы
Не уверен, что это связано именно с GPU.
-
@FastSpace said in Выпущена 24.2.0 версия BrowserAutomationStudio:
Хотя из вышесказанного я не понял каким образом установка собственного таймаута для браузерных действий поможет завершится мгновенно. Мне нужно всю равно ждать то количество секунд, которое я поставил.
Я сделаю короткий таймаут для внутреннего запроса, который выполняется при использовании действия проверить существование, поэтому действие будет возвращать отрицательный результат почти мгновенно при этом таймауте.
И я не уверен, что это получится, это может вызвать другие проблемы.