» Universal Share Downloader

Tevton MegaUploadA2.plg - ОН БЫЛ раньше. То есть было 3 плагина для меги:
Megaupload.plg <- работает напрямую. Обновлен, так и остался
MegauploadA.plg <- работал через прокси 7 - там мегу просто ЗАБАНИЛИ. так что смысл в нем стал нулевой
MegauploadA2.plg <- работает, был обновлен

Но чтобы не разводить кучу плагов, так как A.plg работать никогда не будет я просто взял и ПЕРЕИМЕНОВАЛ A2.plg в A.plg. Так что скачивая с сайта простой плаг и A.plg на самом деле качаете обычный и БЫВШИЙ A2. Программа пытается получить ссылку - старый плаг тоже получает ссылку, но не ту. Так как плагины считываются в порядке их записи на диск, то первым считывается старый, уже не рабочий A2 и дает не верную ссылку.

Надо сначала УДАЛИТЬ все 3 СТАРЫХ плагина, а потом записать 2 НОВЫХ. Тогда все будет работать БЕЗ ПРОБЛЕМ

Если модем подключен как сетевая, то можно попробовать ipconfig /renew

Dimoniusis

А что с badongo.net, он разве докачки не поддерживает? Нельзя как-то сделать, чтобы
USD не начинал качать каждый раз с начала, 13 раз скачивать и каждый раз сначала, ни один траффик не выдержит, при этом из броузера все тянет нормально и за один раз.


Вот отрывок из протокола (полностью выложен в гостевой книге на родном сайте Universal Download

28.03.2006 13:45:31 Получение ссылки на файл из "http://www.badongo.net/file/356776"
28.03.2006 13:45:34 Ссылка: http://www.badongo.net/df/0913313761194335/356776
28.03.2006 13:45:34 Ожидание на включение Download Ticket
28.03.2006 13:46:05 Скачиваю
28.03.2006 13:49:55 Размер запрошенных данных отличается (должено быть 6989853 скачано 690237)
28.03.2006 13:49:55 Файл сохранен в "G:\Universal Download\356776.pusd" (690237 байт)
28.03.2006 13:49:56 Получение ссылки на файл из "http://www.badongo.net/file/356776"
28.03.2006 13:49:59 Ссылка: http://www.badongo.net/df/0900706269153492/356776
28.03.2006 13:49:59 Ожидание на включение Download Ticket
28.03.2006 13:50:30 Скачиваю
28.03.2006 13:57:21 Размер запрошенных данных отличается (должено быть 6989853 скачано 999036)
28.03.2006 13:57:21 Файл сохранен в "G:\Universal Download\356776.pusd" (999036 байт)
28.03.2006 13:57:23 Получение ссылки на файл из "http://www.badongo.net/file/356776"
28.03.2006 13:57:25 Ссылка: http://www.badongo.net/df/0702461970578046/356776
28.03.2006 13:57:25 Ожидание на включение Download Ticket
28.03.2006 13:57:56 Скачиваю
28.03.2006 14:02:33 Размер запрошенных данных отличается (должено быть 6989853 скачано 1204277)
28.03.2006 14:02:33 Файл сохранен в "G:\Universal Download\356776.pusd" (1204277 байт)
28.03.2006 14:02:35 Получение ссылки на файл из "http://www.badongo.net/file/356776"
28.03.2006 14:02:57 Ссылка: http://www.badongo.net/df/0920196974490867/356776
28.03.2006 14:02:57 Ожидание на включение Download Ticket
28.03.2006 14:03:28 Скачиваю
28.03.2006 14:07:13 Размер запрошенных данных отличается (должено быть 6989853 скачано 842277)
28.03.2006 14:07:13 Файл сохранен в "G:\Universal Download\356776.pusd" (842277 байт)

Все равно все будет хорошо, и Universal Download будет лучше и стабильнее.

RapidShare.plg при получении сообщения от сервера о неправильном коде останавливает закачку.
"Access-code B1S wrong. Only Free-users have to enter an access-code to prevent abuse.
Premium-users don't have to! Get your own Premium-account now. Instant download-access!"
IMHO, нужно просто увеличить счетчик попыток на 1

USDownloader.exe - 1.3.3.4
RapidShare.plg - Last Modif. Date: 18/03/2006 22:50:50, No file version information available

Вот бы еще добавить некий лог по поводу качества используемых прокси...
Типа, есть у меня список прокси, программа их перебирает, перебирает,
при этом некоторые возвращают вполне разумные ответы "ваш IP уже качает"
или "обождите столько то минут", а остальные - ничего не возвращают,
потому что нерабочие.
Такой лог посмотреть бы, да и убрать плохие, чтобы на них зря время не тратилось.
Это не совсем то, что делает анализатор прокси, поскольку анализатор вернет время
отклика, да и доволен, в то время, как прокси может оказаться непригодной для
наших практических целей. Тестирование по реальному результату куда как лучше.
А можно еще и среднюю скорость закачки сохранять для сработавших...

Нечто типа третьей закладочки в просмотрщике лог-файлов.

И еще, лог файлы хорошо бы сегментировать, а то для просмотра лога применен
явно родной микрософтовский вьювер, который безбожно тормозит на загрузке
длинных списков строк. Если уж нас интересуют последние 100 строк, зачем хранить
в одном и том же файле десятки тысяч этих строк?
-------------------------------------------------------------
И, для будущих версий, особенно с мультизакачкой:
хорошо бы, чтобы прокси-политики, ограничения скорости, возможно что-то еще
по вкусу автора, было сайт-ориентировано. Для рапиды нужно качать с того же IP,
с которого получена ссылка, для мегааплоада это просто вредно, с другой стороны
мегааплоада нужно натравливать только через прокси, а рапиду в первую очередь
на свой родной IP, и так далее.



Добавлено:
И присоединяюсь к автору прошлого письма.
Хорошо бы неверный код рапиды не банить красным цветом.
Если уж невозможно четко определиться - просто сдвигать в конец очереди,
но не отключать насовсем.
Пусть лучше у файла будет храниться и выводиться на экран рядом с именем закачки
счетчик подобных неудачных попыток.



Добавлено:
А запрошенную мной статистику прокси можно пока по минимуму сделать очень быстро -
к каждому закачанному файлу припасовывать в инфо *.txt файл адрес использованного прокси, среднюю скорость закачки, количество попыток, и т.п.

Народ, я в свободное время пишу 1.3.4 но опять же этого свободного времени я у меня мало.


По поводу проверки прокси - может что-то сделаю. По крайней мере адрес прокси и среднюю скорость через него.

По поводу рапиды - она в заголовке отвечает 404 File Not Found программа в первую очередь по этой инфе ориентирется.

Кстати, я там сборочку обновил - у рапиды 404 игнорируется. То есть по идее будет сливать и за 2-3 попытки, если код не верно определился, но если файла реально нет - может зациклиться (если не стоит ротация).

Для просмотра логов используется стандартный компонент ListView кторый раз в секунду/две перегружается (хотя надо бы сделать детект изменения лога - чтобы лишний раз не дергать)

Dimoniusis

Цитата:

Для просмотра логов используется стандартный компонент ListView

Если прога написана на Дельфи 5..7 (а может, и выше), то у нее для стандартных
виндовых ListView и TreeView нехорошая ошибка в реализации - при добавлении
каждого элемента вызывается сортировка (упорядочение) всего листа, да еще и
два раза (во вложенной процедуре второй раз). Эффект с возрастанием длины
листа просто жуткий! Тормоза возрастают экспоненциально.

Выхода два. Либо лезть в реализацию этих самых контролов, вырубать лишние
сортировки и подкидывать измененный исходник при компиляции проекта (я это
делал, и все ускорялось со страшной силой, но муторно это все), либо вариант
попроще - найти реализацию быстрого листа от производителей сторонних компонентов.
К сожалению, я уже года два как не под Дельфи, имена, пароли, явки забывать
стал, трудно сказать, у кого такое есть. Можно в Дельфийском форуме поинтересоваться.

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

Ау, дельфинисты, кто здесь бывает, подскажите автору вариант, пожалуйста!

Alex_Lost

Цитата:

Ау, дельфинисты, кто здесь бывает, подскажите автору вариант, пожалуйста!

Зачем добавлять компонентов, только размер увеличивать. Dimoniusis правильно сказал что
Цитата:

надо бы сделать детект изменения лога - чтобы лишний раз не дергать

Имхо должно очень просто делаться, при добавлении записи в лог делать в памяти пометку об изменении, в таймере перед обновлением проверять эту метку. Ну или там запоминать размер файла лога и при его изменении обновлять вывод.

Alex_Lost ListView используется только для отображения - а это 100-200 последних строк. Добавляется это туда толкьо 1 раз и сортировка НЕ вызывается. Так что смысла ноль. Основное дергание - перерисовка. Грузится все во внутренний и очень быстрый класс TStringList (10 мегов он грузит почти мгновенно. Такие большие логи народ удаляет) Еще дотсаточно долгий процесс - фильтрация (если открыта закладка файлы - там же идет фильтрация основного лога, причем с условием текущего языка)

Dimoniusis
Сегодняшняя версия перестала создавать .txt файлики после закачки Поправишь?

А у меня вот какой баг с расписанием. Настроены два временных интервала. Один с 7 до 9-30, второй с 17 до 19. Так вот, даже если не стоит галка Работать по расписанию, то в 9-30 все равно закачка останавливается. И в 19 тоже самое.
Кроме того, работает только один интервал и один раз, даже если выставить по рабочим дням. Т. е. в 17 запустился, в 19 отрубился, а на завтра в 7 не запустился. Абидно. Я на работу к 8, так с 7 бы уже один файл то бы и закачался.

WildCat а что пишет ?

Dimoniusis
Ничего не пишет -- просто скачивает файлы, отмечает в списке их зеленым, и все. Файлика с именем <название>.txt с описанием не создается, хотя в списке в USD описание имеется. Поменял exe'шник на вчерашний -- все стало нормально, txt начали создаваться.

WildCat обновил сборку. Заодно и еще пару мелких убрал проблем

А еще заметил, что USD неправильно считает магабайты.
Размер файла в 100 000 000 байт он выводит как 100 MB. Хотя, на самом деле, это 95.4Mb
Я не стану утверждать, что с 1024-кратными числами проще оперировать, чем с 1000-кратными, скорее наоборот но, мне все же кажется, общепринятых стандартов следует придерживаться. Кстати, то же самое касается способа обозначения единицы измерения - Kb/Mb, а не KB/MB

согласен с sabio - размер определяется когда правильно, когда нет...

второй момент - без всяких претензий, постараюсь сначала разобраться у себя: проблемы при скачивании файлов с megaupload.
руками (скопировал ссылку с сайта - вставил в качалку) все работает нормально.

лог:

30.03.2006 13:54:49 Получение ссылки на файл из "http://www.megaupload.com/?d=TCRIWW8F"
30.03.2006 13:55:09 Ссылка: http://www21.megaupload.com/files/7e77e93ef7158b03552e34d74de9b63f/Put.Drakona.(rus).part4.rar
30.03.2006 13:55:09 Ожидание на включение Download Ticket
30.03.2006 13:56:11 Скачиваю
30.03.2006 13:56:13 GET ERROR: Connection refused (Error #10061)
30.03.2006 13:56:14 Получение ссылки на файл из "http://www.megaupload.com/?d=TCRIWW8F"
30.03.2006 13:56:25 Ссылка: http://www21.megaupload.com/files/314750b982695ae97ec0272f685a5820/Put.Drakona.(rus).part4.rar
30.03.2006 13:56:25 Ожидание на включение Download Ticket
30.03.2006 13:57:26 Скачиваю
30.03.2006 13:57:28 GET ERROR: Connection refused (Error #10061)
30.03.2006 13:57:29 Получение ссылки на файл из "http://www.megaupload.com/?d=TCRIWW8F"

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

Dimoniusis Объясни пожалуйста, почему браузером или качалкой с Файлфэктори тянет с нормальной скоростью, а USDownloaderom - скорость раза в 2-3 меньше. Сто раз проверял! И насчёт Мегаплода - обновил все плагины, всё равно отказывается с ним работать. В чём может быть причина?

добавлю сразу чтобы не предлагали:
плагины и экзешник обновил только вчера

Dimoniusis
Аналогично Glebytsch-у, проблемы с мегааплоадом. Ожидание на включение Download Ticket-а, и так бесконечно

интересный момент:
если ссылку от usd закинуть в качалку (все равно как - ручками или через "слежение за буфером обмена") ничего не качается.
получаешь тот же Error #10061...

Karlsberg, Glebytsch вы обновили 2 новых плага, а работает у вас СТАРЫЙ плагин. Я уже писал выше (первое сообщение на этой странице) - A2 пеерименован в A.plg... в итоге когда вы поверх записываете обычный и A плагины - то остается в папке старый A2 котрый и работает. Так как ссылку он отдает, программа пытается ее получить и обламывается - потому, что ссылка не верная. Есил удалить плагин A2 то все будет работать без проблем. Ссылка на www21 - специальная ОШИБОЧНАЯ.

По поводу размера - прога считает в тысячах байт. то есть 1 Килобайт =1000 байт. В сплывающем хинте на размерах (на инфо панели) и в логе файл показывается в байтах. Скачивается так же в байтах, так что тут никаких проблем. Тысячи байт были выбраны для более красивого отображения (кстати это достаточно частое решение, в других местах я тоже видел такое, особых проблем ИМХО не имеет). По поводу Mb - это, как было замечено одним из пользователей - МегаБИТ а не мегаБАЙТ. MB - МегаБАЙТ Mb - мегаБИТ. Чтобы не было путаницы все пишется по стандарту

Dimoniusis
спасибо! пошел исправлять!;)

Dimoniusis
Объясни пожалуйста, почему браузером или качалкой с Файлфэктори тянет с нормальной скоростью, а USDownloaderom - скорость раза в 2-3 меньше.

Цитата:

Тысячи байт были выбраны для более красивого отображения

Что значит для более красивого отображения? Типа там цифры другие что ли, более красивые?
А равняться на "другие места" - неправильно! Зачем вносить путаницу? Все ведь знают, что в мегабайте 1024 килобайта или 1048576 байт (цитата из википедии: "Мегаба&#769;йт (Мбайт, М) м., скл. — единица измерения количества информации, равная 1048576 стандартным (8-битным) байтам или 1024 килобайтам"; правда, английская версия этой страницы уравнивает в правах обе трактовки: 1048576 и 1000000).

В общем, я за то, чтобы эти значения использовались адекватно! Никаких "других мест"! А то один поделит на 1024, другой на 1000.. Завтра я в своей проге решу сделать "еще красивее" и стану делить на 1027 - что тогда получится?..
Уже сейчас из-за всех этих "других мест" сплошная путаница Зачем еще больше плодить беспорядок?

Хотя, если верить все той же википедии (английской), то Dimoniusis абсолютно прав!
А те, кто "делит на 1024", должны обозначать свои величины KiB и MiB соответственно.
Так что выходит, этот пост - просто крик души. Хотя, мало ли какой проходящий мимо програмер обратит на него внимание и примет к сведению.

Matrosking попробуй поставить ограничение скорости в 9999



Цитата:

Что значит для более красивого отображения?

то, что будет писаться не "1020 KB" а "1.0 Mb" Мы считаем в десятичной системе, и как правильно написано в Вики, допускаются обе трактовки. В некотрых прогах это настраивается, винда показывает и так и так в свойствах папки. Что тебе не дает этот параметр? Или ты планируешь место на винчестере с точностью до байта? Если так - то есть такое понятие как не до конца заполненые кластеры и прочее. Это тоже считать?

По поводу "поделит" - делить ничего не надо, программа сама все поделила и вывела в 2х вариантах - точно в байтах и в чысячах/миллионах байтов.

Dimoniusis

Цитата:

попробуй поставить ограничение скорости в 9999

Не помогло... Скорость ровно в 3 раза меньше.

Matrosking тады хз. У меня качается в зависимости от загруженности сервера так же, иногда быстрее браузера

Dimoniusis
Ну тогда потерпим, может с 1-го апреля что-нибудь изменится в лучшую сторону? Вообще хотел тебя поблагодарить за отличную программу, постоянно ей пользуюсь, честно говоря стал уже забывать о всяких Флэшгетах, Регетах и прочей чепухе, и мелкие недостатки вроде этого не могут изменить общего прекрасного впечатления. СПАСИБО!!!!!! (Кстати отдельное спасибо за постоянную работу по улучшению программы, дописывание плагинов, это - большой труд!)

Обновил плагинчик для депосит файлес

ПО повод упроги - постараюсь в выходные таки дописать 1.3.4. А то надоело уже править одно и тоже в 1.3.3 и в 1.3.4.... а 1.3.4 выложить низя, ибо там часть еще не дописана :/

Dimoniusis
Предложение по планировщику(расписанию) - добавить опцию при выборе которой бы:
если докачка на текущей шаре не поддерживается и
если рассчетное время до окончания скачки текущего файла (+ задаваемое пользователем время для коррекции скачков скорости) больше времени до наступлеения события <Остановить закачку> то отменить(отложить) текущую закачку

alt76 сложное условие я сам воткнул раза с 3 как прочитал.... Пока надо вообще его сделать, и переделать lng файл... и вообще там внутрях достаточно много переделывается... Совсем много не хочу, но придется видимо... 1.4 не будет поддерживать плагины 1.3