Разбивка выделения при закачке на части

[vdemidov]

Ну так и стартуй ее - и сразу после старта открывай из нее дочерние окна.

НИЗЗЗЯЯЯ дочерние окна можно открывать только из потока ГУЯ.

Я даже готов на то, чтобы не отдельными окошечками - а доп.полосками в том же окне закачки, или как угодно еще (на свое усмотрение).

А я не готов.

Вообще, конечно, можно просто из одного потока закачки ставить в праллель несколько запросов на закачку как это делает сейчас закачка видимой области экрана, но тогда возникают вопросы с обработкой ошибок и паузами при признаках бана. Становится непонятно что считать последним обработанным тайлом при сохранении sls. И еще куча мелких вопросов.

[Parasite]

НИЗЗЗЯЯЯ дочерние окна можно открывать только из потока ГУЯ.

Ну, значит, придется обойтись одним окошком - но задачу в пределах оного качать в N потоков. Я не против, мне визуализации без разницы.

паузами при признаках бана.

Тормозить все потоки при признаке бана.

Становится непонятно что считать последним обработанным тайлом при сохранении sls.

Наименьший по X\Y тайл (из первого из всех потоков).
При рестарте закачки с теми же установками - она так же и разобьется, качаться начнет с точки останова (строчка выше), уже укачанные ранее другими потоками тайлы (заведомо большие по X\Y, чем точка останова) отработаются как "имеется в кэше, пропускаем". Да, будет кучка дисковых операций - но это боль во спасение. Ну, или писать число N и точки остановки в каждом потоке в .sls тоже, если хочется красиво.

Короче, зайду козырями: накидываю +500рэ. Фича нужна.

[zed]

Кстати, надо помнить про параметр MaxConnectToServerCount (def = 4), который ограничивает число одновременных http запросов. И мне кажется, что лучше сделать так, чтобы закачка по выделенной области всегда была многопоточной, без всякой разбивки полигонов и прочих трюков. Придётся хорошенько подумать над алгоритмом, например, завести очередь отправленных запросов и хитро её обрабатывать, но получится более юзабильно. Не нужно будет руками указывать число потоков, оно просто будет работать так же, как и для просмотра. Опять же, изменений в формат .sls вносить не надо и остановка при бане будет работать даже лучше - мы можем приостановить наполнение очереди, если вышел затык на каком-то тайле, а не продолжать ломиться на сервер со всех окошек.

[zed]

Нашлись тикеты из багтрекера:
- 0000134: Многопоточная закачка \ отдельный качальщик
- 0001647: Автоматическая разбивка выделения на несколько потоков скачки (закрыт: решению не подлежит )

[zed]

Т.е. можно предложить такой алгоритм:
- поток закачки создаёт N рабочих потоков и две очереди: запросов и ответов
- рабочие потоки наперебой берут задания из очереди запросов, обрабатывают их (качают тайлы) и результат складывают в очередь ответов
- поток закачки управляет наполняемостью очереди запросов и обрабатывает очередь ответов (проверяет код ответа, делает паузы при бане, сохраняет в кэш)

При N=1 получаем однопоточную закачку (как сейчас), при N=MaxConnectToServerCount получаем многопоточность, как в режиме просмотра. Опцию даже можно вынести в настройки, чтобы можно было выбрать как качать, при старте закачки.

[vdemidov]

Т.е. можно предложить такой алгоритм:
- поток закачки создаёт N рабочих потоков и две очереди: запросов и ответов
- рабочие потоки наперебой берут задания из очереди запросов, обрабатывают их (качают тайлы) и результат складывают в очередь ответов
- поток закачки управляет наполняемостью очереди запросов и обрабатывает очередь ответов (проверяет код ответа, делает паузы при бане, сохраняет в кэш)

Да не нужно это все. Там одного потока за глаза хватит. Как хватает сейчас одного потока на карту для закачки видимой области.

[zed]

Один поток даёт задания, а качает всё равно пул потоков. Вот если как-то дотянуться до того пула и давать ему задания напрямую, то да.

[vdemidov]

Один поток даёт задания, а качает всё равно пул потоков. Вот если как-то дотянуться до того пула и давать ему задания напрямую, то да.

Ну да. Все потоки закачки и закачка видимой области только ставят задания пулу потоков. Дотягиваться до него не нужно. Оно само и без этого сейчас работает.

[zed]

Вспомнил - тот пул сильно завязан на режим, для которого писался. Он там и бан автоматически обрабатывает и в кэш сам пишет. В общем, слишком специфичен и сюда его не воткнуть.

[Parasite]

мне кажется, что лучше сделать так, чтобы закачка по выделенной области всегда была многопоточной, без всякой разбивки полигонов и прочих трюков. Придётся хорошенько подумать над алгоритмом, например, завести очередь отправленных запросов и хитро её обрабатывать, но получится более юзабильно. Не нужно будет руками указывать число потоков, оно просто будет работать так же, как и для просмотра. Опять же, изменений в формат .sls вносить не надо и остановка при бане будет работать даже лучше

Было бы вообще идеально, но я такое даже просить боюсь.
А ведь с периодичностью этак раз в месяц разговоры про это заходят, но... Посему прошу то, что (как лично мне видится) должно выйти меньшей кровью, и при тех же бонусах в итоге.

Впрочем, если сделать групповой заказ на многопоточную качалку - то лично я не против, а очень даже за. Озвучивайте финальную цену вопроса, и пускай народ подтягивается и голосует рублем. От себя тут пока что вкладываю 1000р, как указано ранее.