Комментарии 55
НЛО прилетело и опубликовало эту надпись здесь
Зачем, если есть Transmission.
А есть ли какой-нибудь автоматизированный способ соскочить с мюторрента на другой клиент с сохранением раздач?
Как вы уже вначале догадались, название самой опции «Copy Stream URL» и все скопированные ссылки с IP 127.0.0.1 сделаны только для воспроизведения загружаемого контента на этом же компьютере. Однако зачем разработчикам пришлось делать так сложно (со встроенным http сервером) не совсем понятно…
Предположу, что так они могут, как раз легко и кроссплатформенно, отслеживать запрашиваемое плеером место файла и запрашивать нужную часть принудительно если она ещё не загрузилась к этому моменту. Альтернативой такому решению была бы лишь виртуальная файловая система, что гораздо более муторно и менее удобно (с вебсервера можно на одном девайсе качать, а на другом девайсе смотреть). Кроме того веб морда в мюторренте уже с доисторических времён есть. Помимо этого таймоут на операцию получения данных по сети обычно во всех приложениях гораздо выше чем при работе с диском, а так же используется более большой буфер. В общем по мне так это самое разумное и простое решение для воспроизведения в процессе закачки.
Предположу, что так они могут, как раз легко и кроссплатформенно, отслеживать запрашиваемое плеером место файла и запрашивать нужную часть принудительно если она ещё не загрузилась к этому моменту.Но они же довольно долго мучались и без http сервера и даже что-то получалось.
(с вебсервера можно на одном девайсе качать, а на другом девайсе смотреть)вот кстати да, об этом я даже как-то и не подумал.
Кроме того веб морда в мюторренте уже с доисторических времён есть.и встроенный http ретрекер bt.enable_tracker
В общем по мне так это самое разумное и простое решение для воспроизведения в процессе закачки.но с другой стороны программа стала сверх забагованной. В одном месте чинится, а в другом ломается.
но с другой стороны программа стала сверх забагованной. В одном месте чинится, а в другом ломается.
Да я сам против всего этого именно в клиенте. Даже патчу его методами грубого хакинга ибо достало. На самом деле забагованность у них, в основном, из-за того, что они бесконечно переделывают GUI, а потом по полгода чинят мелкие и противные баги.
Кстати, по поводу революции в 3.4, забыли о, пожалуй, главном — переделанном механизме выборе пиров
Кстати, по поводу революции в 3.4, забыли о, пожалуй, главном — переделанном механизме выборе пиров
Это достаточно противоречивая тема. Сейчас объясню почему.
Называется ваша фича «Canonical Peer Priority» www.bittorrent.org/beps/bep_0040.html. Появилась она в
— 2012-11-15: Version 3.4 alpha (build 28556)
— Feature: canonical peer priority
В этой реализации есть плюсы и большие минусы. Главная проблема тут в том, что разработчики решили, что они лучше знают как и куда должен бегать p2p трафик. Если в случае локального диапазона 10… 192… это работает, то в интернет диапазонах во многих случаях оно работает не так.
К примеру IP адреса моего провайдера нахдятся в диапазоне 46.10.0.0 — 46.10.255.255. Другой провайдер моего города с которым есть пиринг имет диапазон 220.15.0.0 — 220.15.255.255. Так вот, если utorrent не находит IP из 46.10.0.0 — 46.10.255.255 он начинает подключаться к 46.11… и т.д. А эти пиры могут быть из другого далёкого государства. Если бы провайдер мог добавлять свой файлик приоритетных IP автоматически в utorrent по примеру isp.bep22, тогда провайдеров и в большей части многих пользователей это устроило бы намного больше чем «canonical peer priority». Хотя есть тут отдельные моменты когда почти вся страна сидит за NAT (Беларусь) и подключиться к 90% пирам своей страны невозможно.
По приведённой вами ссылке описана лишь половина того, что приведено в статье на которую я ссылку дал.
Там, всё таки, помимо IP ещё и трейс, т.е. количество хопов, учитывается, что собственно и является главным полезным моментом с точки зрения разгрузки сетей и приоритезацией на скачивание именно с ближайших пиров и косвенно увеличивает скорость скачивания.
Доп: или вы хотите сказать, что они измерение дистанции не реализовали? Ибо у себя по списку пиров при закачке на популярных раздачах вижу, что реализовали.
Там, всё таки, помимо IP ещё и трейс, т.е. количество хопов, учитывается, что собственно и является главным полезным моментом с точки зрения разгрузки сетей и приоритезацией на скачивание именно с ближайших пиров и косвенно увеличивает скорость скачивания.
Подробнее
В итоге получается ситуация как раз обратной той, что Вы описали:
До внедрения фичи:
После внедрения фичи:
А подбор близлежащих IP нужен в первую очередь для устранения проблемы неравномерного формирования роя и паразитной блокировки новых участников, а так же для усиления защиты от DDoS и мусора:
до внедрения:
после внедрения:
До внедрения фичи:
После внедрения фичи:
А подбор близлежащих IP нужен в первую очередь для устранения проблемы неравномерного формирования роя и паразитной блокировки новых участников, а так же для усиления защиты от DDoS и мусора:
до внедрения:
после внедрения:
Доп: или вы хотите сказать, что они измерение дистанции не реализовали? Ибо у себя по списку пиров при закачке на популярных раздачах вижу, что реализовали.
Я понимаю о чём вы пишите. Но профит от этой функции должен быть в виде увеличения скорости загрузки у пользователей, уменьшения нагрузки на внешние каналы у провайдеров и только потом локализация частей роя по количеству хопов.
К примеру, у меня тарифный план 2 мбит в инет и 100 мбит в локалку и пиринг с другими беларускими провайдерами. Если не делать файл isp.peer_policy_url, скорость как правило стабильно держится на 2 мбит, а с файликом нужные пиры цепляются очень даже не плохо. Даже если с первого раза utorrent не может к ним подключиться, то через некоторое время повторно делает попытки подключения. В итоге, на раздачах где более сотни пиров, с isp.peer_policy_url скорость всегда более 2 мбит, а без — почти всегда до 2 мбит. Utorrent не может знать с какими пирами у меня есть ограничения в скорости, а с какими нет. Количество хопов и всё что угодно, для меня как обычного юзера не имеет значения, для меня имеет значение скорость загрузки и отдачи.
Провайдерам в первую очередь нужно, что бы p2p трафик крутился в их сети, затем в их пиринговом пространстве и если на раздаче нет ни тех ни других пиров, только тогда трафик уходил во внешку. Я понимаю, что как правило, путь к пиринговому пиру и получается самым коротким, но не всегда так. Если utorrent не видит заметной разницы между пирами, он начинает сравнивать их IP — что не есть хорошо.
И я не спорю, что новый механизм выбора пиров в различной степени работает положительно для всех. Но лично моё мнение: разработчики в первую очередь должны были сделать механизм для провайдеров по аналогии isp.bep22 с глобальной выдачей списка своих IP. И только потом, если этого файлика utorrent не получал, включался механизм выбора пиров по количеству хопов.
К примеру, у меня тарифный план 2 мбит в инет и 100 мбит в локалку и пиринг с другими беларускими провайдерами. Если не делать файл isp.peer_policy_url, скорость как правило стабильно держится на 2 мбит, а с файликом нужные пиры цепляются очень даже не плохо. Даже если с первого раза utorrent не может к ним подключиться, то через некоторое время повторно делает попытки подключения. В итоге, на раздачах где более сотни пиров, с isp.peer_policy_url скорость всегда более 2 мбит, а без — почти всегда до 2 мбит. Utorrent не может знать с какими пирами у меня есть ограничения в скорости, а с какими нет. Количество хопов и всё что угодно, для меня как обычного юзера не имеет значения, для меня имеет значение скорость загрузки и отдачи.
Провайдерам в первую очередь нужно, что бы p2p трафик крутился в их сети, затем в их пиринговом пространстве и если на раздаче нет ни тех ни других пиров, только тогда трафик уходил во внешку. Я понимаю, что как правило, путь к пиринговому пиру и получается самым коротким, но не всегда так. Если utorrent не видит заметной разницы между пирами, он начинает сравнивать их IP — что не есть хорошо.
И я не спорю, что новый механизм выбора пиров в различной степени работает положительно для всех. Но лично моё мнение: разработчики в первую очередь должны были сделать механизм для провайдеров по аналогии isp.bep22 с глобальной выдачей списка своих IP. И только потом, если этого файлика utorrent не получал, включался механизм выбора пиров по количеству хопов.
Механизм автополучения isp.peer_policy_url аналогичный isp.bep22 это, конечно, хорошо, но не совсем понятно зачем ведь isp.bep22 уже возвращает адрес ретрекера, где есть только пиры из провайдерского пиринга.
Кстати, мне вот в голову мысль пришла, а если вам DHT попробовать отключить и при этом использовать только ретрекер без isp.peer_policy_url, тоже медленно работать будет?
У меня создаётся впечатление, что то ли в вашей сетке ретрекер работает неправильно или по какой-то причине не анонсируется нормально на абонентов или имеет имя отличное от «retracker.local» (в таком виде его многие трекеры по умолчанию в торрент-файлы добавляют) и в связи с этим локальных пиров на нём мало. В общем, странно всё это ибо при рабочем ретрекере у вас должна быть скорость близкая к 100 Мб/с почти всегда.
Ещё смущает факт, что локальные пиры не подключаются сразу, это очень похоже на какой-то баг в настройке пиринга у провайдеров или где-то рядом:
Кстати, мне вот в голову мысль пришла, а если вам DHT попробовать отключить и при этом использовать только ретрекер без isp.peer_policy_url, тоже медленно работать будет?
У меня создаётся впечатление, что то ли в вашей сетке ретрекер работает неправильно или по какой-то причине не анонсируется нормально на абонентов или имеет имя отличное от «retracker.local» (в таком виде его многие трекеры по умолчанию в торрент-файлы добавляют) и в связи с этим локальных пиров на нём мало. В общем, странно всё это ибо при рабочем ретрекере у вас должна быть скорость близкая к 100 Мб/с почти всегда.
Ещё смущает факт, что локальные пиры не подключаются сразу, это очень похоже на какой-то баг в настройке пиринга у провайдеров или где-то рядом:
Даже если с первого раза utorrent не может к ним подключиться, то через некоторое время повторно делает попытки подключения.
Локальные пиры могут иметь интернет IP адреса. У одного провайдера, может быть несколько диапазонов IP. В моём случае, мой utorrent работает с двумя ретрекерами: добавляемый по isp.bep22 и retracker.local. Один ретрекер собирает локальных пиров провайдера (в том числе с интернет IP ADSL модемов) и второй республиканский, для всех провайдеров Беларуси.
Для utorrent нет разницы с какого анонсера получены пиры. Какой трекер отдаст первым IP — с тех пиров и начинается выборка.
А я так делал, но только оставлял пиринговый республиканский ретрекер. Я ещё раз вам напомню, что у нас почти вся страна сидит за NAT (Беларусь) и подключиться к 90% пирам своей страны невозможно. Мне не надо, что бы utorrent даже пытался подключаться к этим пирам. Мне нужно, что бы он качал только с тех IP, с которых качается хорошо и быстро.
Это баг в политике государства и монополии Белтелекома. По нашим законам провайдеры не могут на прямую подключаться в пиринг друг к другу. Они могут подключиться только к так называемым «точкам обмена трафиком» со своим NAT. В итоге пиринга в стране по факту нет вообще. Из-за этого возникают проблемы
а к концу года будет порядка 1Тбит providers.by/2014/11/provajdery-minska/beltelecom/beltelekom-planiruet-rasshirit-vneshnij-kanal-do-650-gbits-do-yanvarya-k-koncu-2015-go-do-910-gbits/
Решение финансовой части этой проблемы уже найдено, в виде налога/тарификации на скайп, «танки» и торренты.
providers.by/2015/02/news/minsvyazi-skype-viber-i-drugie-messendzhery-dolzhny-otchislyat-belorusskoj-storone-chast-pribyli/
Ситуации могут быть разные и не только как в моём примере.
Для utorrent нет разницы с какого анонсера получены пиры. Какой трекер отдаст первым IP — с тех пиров и начинается выборка.
очень похоже на какой-то баг в настройке пиринга у провайдеров или где-то рядом:а как utorrent может определить какой пир локальный или пиринговый, а какой нет? Если к примеру мой IP начинается на 46...., а IP пирингового пира из другого города и другого провайдера 212… При этом, трафик идёт не на прямую друг к другу, а ещё и через третьего магистрального провайдера.
Ещё смущает факт, что локальные пиры не подключаются сразуа почему они должны подключаться сразу, если отдающий пир не может (флаги d или S) на тот момент отдать файл? Utorrent через некоторое время начинает пытаться подключаться к другим пирам, а про этого забывает. А мне нужно, что бы он периодически возвращался к тому пиру. Некоторые провайдеры в своих мануалах даже рекомендуют включать isp.peer_policy_override, тогда пиры на загрузке принудительно меняются.
Кстати, мне вот в голову мысль пришла, а если вам DHT попробовать отключить и при этом использовать только ретрекер без isp.peer_policy_url, тоже медленно работать будет?
А я так делал, но только оставлял пиринговый республиканский ретрекер. Я ещё раз вам напомню, что у нас почти вся страна сидит за NAT (Беларусь) и подключиться к 90% пирам своей страны невозможно. Мне не надо, что бы utorrent даже пытался подключаться к этим пирам. Мне нужно, что бы он качал только с тех IP, с которых качается хорошо и быстро.
это очень похоже на какой-то баг в настройке пиринга у провайдеров или где-то рядом:
Это баг в политике государства и монополии Белтелекома. По нашим законам провайдеры не могут на прямую подключаться в пиринг друг к другу. Они могут подключиться только к так называемым «точкам обмена трафиком» со своим NAT. В итоге пиринга в стране по факту нет вообще. Из-за этого возникают проблемы
Внешний интернет-шлюз страны на данный момент составляет 770 Гбит/с.
а к концу года будет порядка 1Тбит providers.by/2014/11/provajdery-minska/beltelecom/beltelekom-planiruet-rasshirit-vneshnij-kanal-do-650-gbits-do-yanvarya-k-koncu-2015-go-do-910-gbits/
Решение финансовой части этой проблемы уже найдено, в виде налога/тарификации на скайп, «танки» и торренты.
providers.by/2015/02/news/minsvyazi-skype-viber-i-drugie-messendzhery-dolzhny-otchislyat-belorusskoj-storone-chast-pribyli/
Ситуации могут быть разные и не только как в моём примере.
Прошу прощения, я балбес и не посмотрел в ваш профиль чтобы узнать откуда вы. В РБ действительно серьёзные проблемы с интернетом, тут могу только посочувствовать.
Эту проблему действительно, кроме как принудительным использованьем адресов из списка не решить ибо прямой связи, впрочем, как и реального пиринга, при котором сети, до выхода в интернет или до магистрали, объединяются воедино нет. К сожалению, тут проблема в первую очередь нетехнического характера и решать её надо другими путями, т. е. пинать законодателей дабы разрешили в стране нормальный пиринг.
Поясню почему проблему не решают и вряд ли станут решать разработчики клиента. Отдавать список адресов для пиринга специальным методом непосредственно клиенту это оверхед и просто велосипед ибо уже есть стандартные протоколы обмена правилами маршрутизации между пограничными роутерами. В то же время клиент вообще не должен этим заморачиваться ибо у него уже есть механизм сравнения скорости сидов и прекращения закачки с низкоскоростных. В то же время механизм canonical peer priority был реально необходим ибо без него новые пиры не могли присоединяться к уже существующему рою или присоединялись только друг к другу, что в итоге приводило к ситуации когда есть куча пиров в нескольких роях у которых раздача по нулям, а сиды и пиры, уже начавшие пировать ранее, не пускают их в свои рои где идёт обмен. В итоге получается что новые пиры не могут присоединиться к обмену.
P.S. а вы пробовали увеличивать количество пиров на закачку с 50 по умолчанию до, к примеру, нескольких сотен или это тоже не помогает?
P.P.S. обновил свою патченную сборку и настройки toster.ru/q/167191#comment_673607
Они могут подключиться только к так называемым «точкам обмена трафиком» со своим NAT. В итоге пиринга в стране по факту нет вообще.
Эту проблему действительно, кроме как принудительным использованьем адресов из списка не решить ибо прямой связи, впрочем, как и реального пиринга, при котором сети, до выхода в интернет или до магистрали, объединяются воедино нет. К сожалению, тут проблема в первую очередь нетехнического характера и решать её надо другими путями, т. е. пинать законодателей дабы разрешили в стране нормальный пиринг.
Поясню почему проблему не решают и вряд ли станут решать разработчики клиента. Отдавать список адресов для пиринга специальным методом непосредственно клиенту это оверхед и просто велосипед ибо уже есть стандартные протоколы обмена правилами маршрутизации между пограничными роутерами. В то же время клиент вообще не должен этим заморачиваться ибо у него уже есть механизм сравнения скорости сидов и прекращения закачки с низкоскоростных. В то же время механизм canonical peer priority был реально необходим ибо без него новые пиры не могли присоединяться к уже существующему рою или присоединялись только друг к другу, что в итоге приводило к ситуации когда есть куча пиров в нескольких роях у которых раздача по нулям, а сиды и пиры, уже начавшие пировать ранее, не пускают их в свои рои где идёт обмен. В итоге получается что новые пиры не могут присоединиться к обмену.
P.S. а вы пробовали увеличивать количество пиров на закачку с 50 по умолчанию до, к примеру, нескольких сотен или это тоже не помогает?
P.P.S. обновил свою патченную сборку и настройки toster.ru/q/167191#comment_673607
P.S. а вы пробовали увеличивать количество пиров на закачку с 50 по умолчанию до, к примеру, нескольких сотен или это тоже не помогает?частично помогает, но тут другой момент возникает, чем больше пиров тем ниже скорость в браузере. По этому лучше пару штук быстрых пиров, чем 100 медленных. Вечный поиск золотой середины.
У нас когда-то планировали по другому сделать. Эзернетчики негласно поделили между собой IP диапазон 10… Самый крупный государственный провайдер Белтелеком (более 2млн пользователей) тем своим юзерам что за NAT даёт IP из нового локального диапазона 100… (кстати Белтелекомовский ретрекер раньше собирал IP из этого диапазона, сейчас уже почему-то нет, хотя обмен между этими IP возможен). Не знаю как в техническом плане это всё дело может соеденить, но сами диапазоны IP в сетях провайдеров не пересекаются.
Вот так и находимся в многолетнем ожидании того что будет… и ждём 1 терабит на внешку к концу года :)
Проблема нагрузки на систему косвенно (если не лазить по тонким настройкам самого клиента) решается снижением торренту приоритета ввода-вывода:
Дурацский харбра парсер code не работает нормально и сжирает переносы строк, а кавычки автоматом заменяютсяна гуманитарные :(
Если IP не пересекаются, то всё вообще хорошо и должно из коробки работать, главное общий ретрекер для всех сетей в пиринге иметь.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utorrent.exe]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utorrent.exe\PerfOptions]
"IoPriority"=dword:00000000
"CpuPriorityClass"=dword:00000005
Дурацский харбра парсер code не работает нормально и сжирает переносы строк, а кавычки автоматом заменяются
Не знаю как в техническом плане это всё дело может соеденить, но сами диапазоны IP в сетях провайдеров не пересекаются.
Если IP не пересекаются, то всё вообще хорошо и должно из коробки работать, главное общий ретрекер для всех сетей в пиринге иметь.
На что переезжать? Vuze?
На qBittorrent, например. По интерфейсу похож, ищет узлы быстро (камень в огород Transmission), умеет последовательную загрузку частей файла.
Если висит свыше 1000 раздач, это нужно каждую вручную добавить, или можно из uTorrent как-то быстро конвертнуть текущие раздачи?
Конечно, можно. Есть автоматическое добавление .torrent-файлов из папки как в uTorrent.
А автоматическое понимание, где лежат уже скачанные файлы там тоже есть?
Просто торрент файлы открыть не так сложно. Лень настраивать в какие папки оно у меня было скачано.
Просто торрент файлы открыть не так сложно. Лень настраивать в какие папки оно у меня было скачано.
Есть указание, куда качать раздачи. Указываете папку, где они у вас лежат, qBittorrent проверит их и продолжит раздавать, тоже как в uTorrent.
Но если раздачи по разным папкам раскиданы, то придётся добавлять как-то порциями. И если какие-то раздачи были закачаны частично, то это надо тоже руками указывать. Но безболезненного и полностью автоматического перехода нет ни на одном клиенте, насколько мне известно.
Но если раздачи по разным папкам раскиданы, то придётся добавлять как-то порциями. И если какие-то раздачи были закачаны частично, то это надо тоже руками указывать. Но безболезненного и полностью автоматического перехода нет ни на одном клиенте, насколько мне известно.
Если не секрет, такое количество раздач не превращает работу в интернете в ад?
У меня была как-то ситуация, в которой я не мог разобраться. Постоянно вылетали IM (аська, QIP-акаунт, иногда джаббер), при сёрфинге порой страница по клику не грузилась, при звонках через QIP/SIP порой искажался голос (металлизация, задержки и прочее), запущенный бесконечный пинг какого-нибудь сайта был с огромным временем отклика (200-400 мс) и процентов 10 потерь. А потом я поставил все торренты на паузу и понял, что это было из-за них: около сотни раздач на моём рабочем компьютере и ещё столько же на другом в моей сети. Исходящий канал у меня всего 1 Мбит/с (ADSL), и эта пара сотен торрентов аццки перегружала то ли ADSL-роутер, то ли 100-мбитный свитч, то ли ещё что-то.
У меня была как-то ситуация, в которой я не мог разобраться. Постоянно вылетали IM (аська, QIP-акаунт, иногда джаббер), при сёрфинге порой страница по клику не грузилась, при звонках через QIP/SIP порой искажался голос (металлизация, задержки и прочее), запущенный бесконечный пинг какого-нибудь сайта был с огромным временем отклика (200-400 мс) и процентов 10 потерь. А потом я поставил все торренты на паузу и понял, что это было из-за них: около сотни раздач на моём рабочем компьютере и ещё столько же на другом в моей сети. Исходящий канал у меня всего 1 Мбит/с (ADSL), и эта пара сотен торрентов аццки перегружала то ли ADSL-роутер, то ли 100-мбитный свитч, то ли ещё что-то.
НЛО прилетело и опубликовало эту надпись здесь
Вообще не напрягает.
По расписанию поставил лимит на отдачу 1 мбайт/сек с 20 до часу ночи по будням, в остальное время комп без меня крутится, пусть раздает.Кроме того, не все же раздачи все время активны — некоторые раритеты месяцами могут быть невостребованы.
Пока что роздано примерно 120-130 тб.
По расписанию поставил лимит на отдачу 1 мбайт/сек с 20 до часу ночи по будням, в остальное время комп без меня крутится, пусть раздает.Кроме того, не все же раздачи все время активны — некоторые раритеты месяцами могут быть невостребованы.
Пока что роздано примерно 120-130 тб.
Присоединяюсь. Несколько лет мучился с «перегрузка диска 100%». qBittorrent решил проблему. Выглядит очень похоже на uTorrent. Умеет почти все те же фишки.
а есть ли на qBittorrent dht-патч как на uTorrent, чтоб игнорировать приватный статус? Оно то в общем случае не надо, но бывает ищешь что-то редкое… сами понимаете
Пару лет назад перешел на qBittorrent, всем доволен, рекомендую.
Соглашусь, с первых же минут qBittorent порадовал несколькими не встреченными мною в uTorrent фишками, вроде автоподгрузки списка файлов при закачке через magnet-ссылку и возможности легко исключать ненужные для скачки файлы галочками.
Он, к сожалению, тоже не без багов. Например, иногда не любит видеть свои же недокачанные файлы, приходится удалять торрент и заново добавлять. Очень не любит, когда какой-то из UDP-трекеров не отвечает, тогда приходится перезапускать, иначе про все трекеры забудет. Еще хуже, что эти баги проявляются относительно редко, и неясно, как их получить.
вроде автоподгрузки списка файлов при закачке через magnet-ссылку и возможности легко исключать ненужные для скачки файлы галочками.
так это всё в мюторренте тоже есть, обе эти фичи включаются одной галкой:
Настройка->Интерфейс->При добавлении торрента->Настройки изменения имени и места данных торрента.
P.S. всё это хорошо описано, например, тут rutracker.org/forum/viewtopic.php?t=219818#19 этим мюторрент и удобен — много форумов, много пользователей, мало проблем.
Рекомендую deluge.
tixati
Мне нравится, не буду переезжать ни на что (=
Какова мораль сей басни?
Почему-то вспомнился отрывок из этого мультфильма www.youtube.com/watch?feature=player_detailpage&v=tEnQ9cIyEVc#t=548
Печаль в том, что все новые фичи погребены за тоннами добавляемой в каждой версии рекламы, и после каждого обновления приходится искать все «продвинутые» и «скрытые продвинутые» опции, чтобы её скрыть. Это свинство, и желания обновляться это не добавляет.
Самый лучший мотор рент который был — это версии 1.5.
Это единственная версия, которая не выдавала тупое сообщение " диск перегружен 100%" на стомегабитных каналах и больших торрентах и начинала качать сразу.
А так да, я до сих пор сижу на 2.2.1 потому что в ней нет рекламы и всяких ненужных мне функций и переезжать не собираюсь.
Это единственная версия, которая не выдавала тупое сообщение " диск перегружен 100%" на стомегабитных каналах и больших торрентах и начинала качать сразу.
А так да, я до сих пор сижу на 2.2.1 потому что в ней нет рекламы и всяких ненужных мне функций и переезжать не собираюсь.
Но ведь в этот момент действительно диск перегружен на 100% — создается большой файл, который в данный момент скачивается. Во всяком случае, судя по Диспетчеру задач, диск все это время действительно занят на 100%.
Или другие клиенты позволяют не резервировать заранее место под файл? Поставил сейчас как выше советовали qBittorrent, попробую…
Или другие клиенты позволяют не резервировать заранее место под файл? Поставил сейчас как выше советовали qBittorrent, попробую…
Действительно позволяет не резервировать место. Есть даже такой пункт в настройках программы, включающий/отключающий эту возможность.
Там файл создаётся не в прямом смысле, а просто резервируется место. Не заполняется же оно нулями.
Ведь как-то fsutil file createnew может создавать файлы хоть в терабайт за секунду
Ведь как-то fsutil file createnew может создавать файлы хоть в терабайт за секунду
Нет, там была опция diskio.no_zero. Она позволяла не заполнять нулями файл, хотя и создавала большой файл сразу. Действительно, неужели для того, чтобы создать огромный файл, нужно непременно его чем-то заполнить? Но потом эту опцию выпилили, не знаю, почему. Сейчас есть опция diskio.sparse_files, не знаю, эквивалент ли это, хотя она была и тогда.
На сколько я помню, uTorrent тоже умеет не резервировать место под файл. Это есть в дополнительных настройках.
Что-то не понятно как настроить URL автообновления — на трекерах скачать можно только после авторизации.
Или есть в других торрент клиентах такая фича?
А может есть торрент клиент с web браузером внутри?
Или есть в других торрент клиентах такая фича?
А может есть торрент клиент с web браузером внутри?
По ссылке обновления должен загружаться не сам торрент, а информация в которой в том числе будет указана ссылка или хеш нового торрента. Новый торрент автоматом, по идее, должен подменить старый и после этого utorrent перехеширует задание. Вполне вероятно, что новый торрент-файл может скачаться и по магнет-ссылке.
Другими словами, первый торрент-файл скачивается юзером с сайта с регистрацией обычным способом, ссылка обновления в торрент-файле должна работать без авторизации, новый торрент-файл utorrent должен скачивать по ссылке без авторизации (либо, если есть такая встроенная возможность — по магнет-ссылке).
Если интересно, можете скачать и покрутить этот экспериментальный торрент-файл со ссылкой обновления который выложили разработчики у себя на форуме, что бы юзеры посмотрели/потестили как оно работает dl.dropboxusercontent.com/u/43001898/rutracker/BitTorrent-Public-Enemy-Get-Up-Stand-Up-Base.torrent
К сожалению, об этом тесте я узнал уже через несколько недель после его завершения, ссылку страницы на то событие мне подкинули сами пользователи форума utorrent.
Другими словами, первый торрент-файл скачивается юзером с сайта с регистрацией обычным способом, ссылка обновления в торрент-файле должна работать без авторизации, новый торрент-файл utorrent должен скачивать по ссылке без авторизации (либо, если есть такая встроенная возможность — по магнет-ссылке).
Если интересно, можете скачать и покрутить этот экспериментальный торрент-файл со ссылкой обновления который выложили разработчики у себя на форуме, что бы юзеры посмотрели/потестили как оно работает dl.dropboxusercontent.com/u/43001898/rutracker/BitTorrent-Public-Enemy-Get-Up-Stand-Up-Base.torrent
К сожалению, об этом тесте я узнал уже через несколько недель после его завершения, ссылку страницы на то событие мне подкинули сами пользователи форума utorrent.
Кстати, а почему некоторые предпочитают уйти на другой клиент, если вроде как можно просто остаться на какой-то старой версии uTorrent?
Я сижу под windows, пробую qBittorrent, но интерфейс реально менее удобный и каких-то простых удобных моментов не хватает.
То есть какие минусы могут быть если я поставлю и останусь на uTorrent 1.8 (или 2.3) вместо того, чтобы перейти на qBittorrent?
p.s. Сейчас сижу на uTorrent 3.4.2, из проблем — пару раз в месяц он может вылететь при добавлении нового торрент-клиента.
Из замеченных проблем — заметил один раз, когда раздавало со скоростью 2 мбайт/сек, несмотря на то, что по расписанию было включено ограничение в 1 мбайт/сек. Но обычно ограничение скорости раздачи работает нормально.
Я сижу под windows, пробую qBittorrent, но интерфейс реально менее удобный и каких-то простых удобных моментов не хватает.
То есть какие минусы могут быть если я поставлю и останусь на uTorrent 1.8 (или 2.3) вместо того, чтобы перейти на qBittorrent?
p.s. Сейчас сижу на uTorrent 3.4.2, из проблем — пару раз в месяц он может вылететь при добавлении нового торрент-клиента.
Из замеченных проблем — заметил один раз, когда раздавало со скоростью 2 мбайт/сек, несмотря на то, что по расписанию было включено ограничение в 1 мбайт/сек. Но обычно ограничение скорости раздачи работает нормально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые баги utorrent или что для нас готовят программисты Bittorrent