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

[Parasite]

...и тишинааа..........и только HTTP-запросы в очереди на закачку стоят...

[vdemidov]

Увы, времени нет совсем. Так что если этим займется кто-то другой - возражать не буду. Только пусть предупредит, что бы я не ковырялся, если таки время вдруг появится.

[zed]

В таком случае, могу заняться данной хотелкой.

Я могу сделать многопоточную загрузку, которая будет ограничена числом MaxConnectToServerCount из zmp, без возможности задания этого числа в гуе, при старте закачки. Т.е. закачка выделенной области будет работать так же, как и закачка видимой области при сёрфинге. Сам параметр MaxConnectToServerCount я могу вынести в настройки карты, чтобы всё-таки не лазить руками в zmp. Ну а при старте закачки, могу только добавить галочку для игнорирования этого параметра, чтобы можно было качать в однопоточном режиме.

И придётся что-то сделать с логом, чтобы там не было неразберихи. Предлагаю не спамить туда отчитываясь о каждом тайле, а выводить только какую-то общую информацию, вроде ошибок, приостановки/возобновления закачки юзером и проч. О том, какой тайл скачался, теперь видно и из статусной строки. Правда, не будет видно, какие именно тайлы (и сколько) качаются в текущий момент времени, но думаю, без этой информации можно обойтись. Хотя, спам можно и оставить, но тогда всюду придётся добавлять строку вида "[z%d/x%d/y%d]" для того, чтобы было понятно, к какому тайлу относится сообщение.

[Parasite]

В таком случае, могу заняться данной хотелкой.
придётся что-то сделать с логом, чтобы там не было неразберихи.

И все же - как насчет того, чтобы просто автоматом разбивать выделеный полигон на условно равные (по кол-ву тайлов к закачке) N частей, и открывать на каждую часть свое под-окошко со скачкой (в том его виде и функционале, в котором оно сейчас есть)?
Как по мне - так очень элегантно вписывается, и не надо отдельно разбираться ни с логом скачки, ни с очередями, ни с сохранением процесса в SLS...

[zed]

Мне такой вариант не нравится, потому что невозможно "просто" разбить выделение. Даже с прямоугольным выделением возникают вопросы.
Плюс, мне не ясно твое желание манипулировать сотнями окошек вместо того, чтобы иметь дело с одним.
Ты же понимаешь, что запустив даже сотню окошек, одновременно качать реально будет только N потоков. И это N забито в zmp.

[Parasite]

Мне такой вариант не нравится, потому что невозможно "просто" разбить выделение. Даже с прямоугольным выделением возникают вопросы.

В рамках данной хотелки их и предлагается решить, выразив результат в строчках кода.
Я всё еще не понимаю, в чем сермяжная разница между "Открыть окошки автоматически как просится в хотелке" и "Открыть ручками 100500 одинаковых SLSов, отличающихся лишь параметрами "StartX + StartY" и, опционально, "StopX + StopY" (которые надо будет ввести - и качать, разумеется, лишь то, что попадает в оные рамки)? Вот второе я могу сделать прямо сейчас, поменяв цифирки в Блокноте ручками - а вот почему нельзя их менять автоматом? Если большая нагрузка на камень при попытке одновременного открытия - значит, открывать по очереди. Это ничего - я не тороплюсь, я подожду.

Плюс, мне не ясно твое желание манипулировать сотнями окошек вместо того, чтобы иметь дело с одним.

Я понимаю вынесенную в заголовок темы фразу "Разбивка выделения при закачке на части" именно как РАЗБИВКУ выделения. На части. Кои я и хочу наблюдать и контролировать частями, по отдельности.
Многопоточная закачка хотя и сделает то же самое в результате - но вот в процессе своей работы по удобству итд она несколько не то, что просится. Так как я качаю много, круглосуточно и сердито - то именно удобство работы в процессе частенько выходит на первое место - а результат может прийти и через месяц, и через три...

Ты же понимаешь, что запустив даже сотню окошек, одновременно качать реально будет только N потоков. И это N забито в zmp.

Вот и отлично. Когда мне приспичит иметь больше - то я просто открою zmp и поменяю N на N+n, да и всё. Вот как раз тут никаких проблем нет - оно и должно качать так, как указано в zmp. Если юзер открыл число окошек больше указанного в zmp лимита - то, значит, они будут драться за каждый свободный слот, и это юзер дурак а вовсе не САС. Сугубо опционально можно вывесить юзеру какой-нибудь тематический поп-ап.

[zed]

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

[vdemidov]

Проблема в том, что сначала нужно радикально ускорить подсчет количества тайлов в полигоне. Так как сейчас оно подсчитывается в потоке стартовавшей закачки, когда создавать новые окна закачки уже нельзя.

[Parasite]

Ок, вот теперь я понял что ты хочешь.

Я желаю:
1. Выделить полигон.
2. Где-нибудь в гуе проставить галку "Разбить закачку на [N] частей"
3. При старте этого ЕДИНОГО выделения мне откроется N отдельных окошек скачки, каждая их которых будет качать свою часть от того единого общего выделения.
В каждом отдельном окне - свои рамки ко скачке в данном потоке, свой отдельный лог, свои SLSы, и вообще - каждая под-часть есть отдельная закачка (просто стартанутая из-под начального выделения - как будто я ручками выделил и стартанул более меньший полигон в пределах начального большого. Просто все стартанутые закачки в сумме, по завершению должны дать тот самый начальный полигон, вот и всё. А качают пускай они ровно так же, как и сейчас - ограничение касается только числа тайлов в пределах данного конкретного потока, а не самого алго скачки в потоке).
4. Разбивать предлагаю по количеству тайлов ко скачке, на условно-равные доли. Но принимаются и другие идеи.
5. Общее число потоков не может превышать глобала max_connect_to_server_count (или как там его) в zmp. Если превышает - то лишние стартовать в паузе и выводить попап, либо как-нибудь еще на свое усмотрение.

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

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

Проблема в том, что сначала нужно радикально ускорить подсчет количества тайлов в полигоне. Так как сейчас оно подсчитывается в потоке стартовавшей закачки, когда создавать новые окна закачки уже нельзя.

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

[vdemidov]

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

Нельзя ускорить потом. Иначе ГУЙ будет зависать до полого подсчета. Я такое откачу в любом случае. А полный просчет нужен уже для старта первой закачки, чтобы посчитать до какого тайла ей нужно качать.