|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 12:33
(10 лет назад)
Рapant писал(а):
66099811Дак посмотрите на закладке Информация
А что там?
Ничего про битые блоки не вижу.
Ну да ладно...
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
07-Дек-14 12:42
(спустя 9 мин.)
жук555 писал(а):
66100539А что там?
Ничего про битые блоки не вижу.
Строка Потеряно...
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 12:46
(спустя 3 мин.)
Рapant
Нет у меня строки Потеряно...
Есть
Излишки 5,97 МБ (ошибок хэша: 10)
Оно?
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
07-Дек-14 13:21
(спустя 35 мин.)
жук555 писал(а):
66100686Оно?
Оно.. Тонкости перевода.
Вот ваши 5 Мб разницы.
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 13:26
(спустя 4 мин.)
Рapant
Это нормально, что такое случается?
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
07-Дек-14 13:32
(спустя 6 мин.)
жук555 писал(а):
66101185Это нормально, что такое случается?
Ничего страшного, если это не происходит часто и в больших объёмах.
|
|
|
|
AssassinsssRTOsss
Стаж: 10 лет 1 месяц Сообщений: 9
|
AssassinsssRTOsss ·
07-Дек-14 14:19
(спустя 47 мин.)
жук555 писал(а):
66098283lososnooley
Ожидаемое время, за которое должна скачаться раздача, показывается, когда на ней есть сиды. Знак бесконечности означает, что скачивание ведётся с тех пользователей, у которых нет 100% того материала, который Вы качаете, т. е. с личеров.
С какого источника ответ?
Если не знать, то может лучше объяснить правилами арифметики, т.е. оставшийся объём для скачивания/скорость скачивания? По такой формуле клиенту разницы нет - Сид или Личер.
Лучше, конечно, заглянуть вовнутрь клиента. Тогда можно будет объяснить и такие показания:
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 14:35
(спустя 15 мин.)
AssassinsssRTOsss
Ответ был дан точно, появившиеся здесь спецы и оракулы уже давно бы поправили, не сомневайтесь 
Объём (в МБ) поделить на скорость скачивания (в МБ/с) – получим время в секундах, всё правильно, логика есть. Но она отсутствукет в Ваших словах
AssassinsssRTOsss писал(а):
66101774По такой формуле клиенту разницы нет - Сид или Личер
Ну скачает качающий всё что есть у раздающих личеров, а дальше что?
Только в довольно редком, наверное, частном случае может получиться так, что в сумме у всех личеров (у каждого по части) будет весь материал (100%), тогда, видимо, клиент будет писАть время.
А скрин у Вас странный, для чего он? Где же там это "Оставшееся время", мы ведь о нём тут говорили немного (потому как быстро (сразу) разобрались).
А Вы тут возни навели. 
|
|
|
|
AssassinsssRTOsss
Стаж: 10 лет 1 месяц Сообщений: 9
|
AssassinsssRTOsss ·
07-Дек-14 16:48
(спустя 2 часа 12 мин.)
жук555 писал(а):
66101948
скрытый текст
AssassinsssRTOsss
Ответ был дан точно, появившиеся здесь спецы и оракулы уже давно бы поправили, не сомневайтесь
Объём (в МБ) поделить на скорость скачивания (в МБ/с) – получим время в секундах, всё правильно, логика есть. Но она отсутствукет в Ваших словах
AssassinsssRTOsss писал(а):
66101774По такой формуле клиенту разницы нет - Сид или Личер
Ну скачает качающий всё что есть у раздающих личеров, а дальше что?
Только в довольно редком, наверное, частном случае может получиться так, что в сумме у всех личеров (у каждого по части) будет весь материал (100%), тогда, видимо, клиент будет писАть время.
А скрин у Вас странный, для чего он? Где же там это "Оставшееся время", мы ведь о нём тут говорили немного (потому как быстро (сразу) разобрались).
А Вы тут возни навели.
Я не думаю, что ответ был верен. Точно ответить может только тот, который знает устройство (не настройки) клиента. Спецы и оракулы тут ни причем. Косвенно, многочисленными наблюдениями, конечно, можно установить закономерность появления знака бесконечности.
Механизм учета параметров файлообмена клиента обязан показывать по оставшемуся времени: оставшийся объём для скачивания/скорость скачивания, независимо от типа пира (Сид, Личер).
Фактическое отражение оставшегося времени в клиенте зависит от алгоритма показа оставшегося времени при отсутствии скорости скачивания, т.е. сразу знак бесконечности не может выскочить.
Скриншот мой действительно оказался странным. Да, без столбца "Оставшееся время" - по ошибке выложил другой.
Со столбцом "Оставшееся время":
На скриншотах смотреть за загрузкой файла 811 Мб.
В клиенте строго действительное значение не увидите - и при знаке бесконечности можно увидеть скорость загрузки, так как в клиенте параметры файлообмена мгновенно не изменяются.
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
07-Дек-14 17:00
(спустя 12 мин.)
жук555
AssassinsssRTOsss
Мдя.. Теория не всегда совпадает с практикой. Проверил на раздаче, где нет сидов и доступность меньше 1 -
Тем не менее время отображается. Правда непонятно - что оно означает. Возможно время до скачивания доступного контента с текущей скоростью. Короче - объём сферического коня в вакууме.
|
|
|
|
Rus1am89
Стаж: 16 лет 1 месяц Сообщений: 7
|
Rus1am89 ·
07-Дек-14 17:31
(спустя 31 мин., ред. 07-Дек-14 17:31)
hardhouse писал(а):
66062988Rus1am89
в уторренте есть webUI, он же "удаленный доступ"
сдается мне там все это есть
Спасибо  , но как оказалось для моей задачи больше подойдет rtorrent (консольный клиент) все это будет работать на сервере, торренты будут добавляться через бд sql с заранее собранными ссылками, оттуда же будет выставляться приоритет в зависимости от количества пиров/сидов, например раздача для которой долгое время не было раздающих выставлять высший приоритет в противовес тем у которых много раздающих.
|
|
|
|
anya1956
Стаж: 15 лет 1 месяц Сообщений: 889
|
anya1956 ·
07-Дек-14 17:37
(спустя 5 мин.)
Рapant писал(а):
66103781
скрытый текст
жук555
AssassinsssRTOsss
Мдя.. Теория не всегда совпадает с практикой. Проверил на раздаче, где нет сидов и доступность меньше 1 -
Тем не менее время отображается. Правда непонятно - что оно означает. Возможно время до скачивания доступного контента с текущей скоростью. Короче - объём сферического коня в вакууме.
Клиент будет показывать данные в клиенте согласно своему алгоритму. Помешать этому могут, например, кратковременные зависания клиента.
Показания в uTorrent в байтах отсутствуют (в qBitTorrent есть) и поэтому отсутствие скорости загрузки в клиенте в столбце скорость вовсе не означает, что загрузки в клиенте нет. Чем меньше скорость приема, тем больше оставшееся время и клиент, естественно, выдает оставшееся время в минутах, часах, днях, неделях, месяцах, годах. Но не думаю, что разработчики заложили показ столетиями, т.е. при достижении какой-то величины клиент просто будет выдавать знак бесконечности.
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
07-Дек-14 17:46
(спустя 9 мин.)
anya1956 писал(а):
66104241клиент, естественно, выдает оставшееся время
Вопрос - оставшееся до чего, если на раздаче нет полного источника?
Скорее всего - виртуальную цифру исходя из полного размера раздачи и текущей скорости. Реально - ерунду.
|
|
|
|
anya1956
Стаж: 15 лет 1 месяц Сообщений: 889
|
anya1956 ·
07-Дек-14 18:23
(спустя 36 мин.)
Рapant писал(а):
66104373
anya1956 писал(а):
66104241клиент, естественно, выдает оставшееся время
Вопрос - оставшееся до чего, если на раздаче нет полного источника?
Скорее всего - виртуальную цифру исходя из полного размера раздачи и текущей скорости. Реально - ерунду.
Не исходя из полного размера раздачи и текущей скорости, а исходя из этой формулы:
(Объём файла - Объём скачанного)/Текущая скорость
Клиенту наплевать на наличие полного источника файла и он будет считать до тех пор пока не скачает последний отсутствующий у него байт из числа имеющихся в сети, а далее будет бесконечность пока не появятся в сети не имеющиеся байты файла.
Чтобы не видеть ерунду, надо видеть скорость в Байт/с.
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 19:25
(спустя 1 час 2 мин., ред. 07-Дек-14 19:25)
anya1956 писал(а):
66104241Клиент будет показывать данные в клиенте согласно своему алгоритму. Помешать этому могут, например, кратковременные зависания клиента.
Показания в uTorrent в байтах отсутствуют (в qBitTorrent есть) и поэтому отсутствие скорости загрузки в клиенте в столбце скорость вовсе не означает, что загрузки в клиенте нет. Чем меньше скорость приема, тем больше оставшееся время и клиент, естественно, выдает оставшееся время в минутах, часах, днях, неделях, месяцах, годах. Но не думаю, что разработчики заложили показ столетиями, т.е. при достижении какой-то величины клиент просто будет выдавать знак бесконечности.
Не думаю , что дело в настолько малой скорости загрузки, что отображающий её как минимум к килобайтах в секунду uTorrent пренебрегает маленькими значениями. Ведь тот же служебный трафик измеряется в килобайтах в секунду, и тогда чётко ясно (и видно), что ничего не загружается при этом. На уже скачанных-то раздачах.
Вероятно, всё же полный источник (100% материала) суммарно у личеров есть. На скриншотах видно, что личеры имеют примерно по 5% материала. Их от 11 до 17 человек в разные периоды времени, при том что качающий ТС имеет также около 5% скачанного. Сумма файлов у этих 17-ти личеров составляет меньше 100% и меньше 95% с учётом имеющейся части у ТС. Но меньше ненамного. Личеры приходят и уходят, и довольно трудно отследить: одни и те же эти 17 человек торгуют файлами-частями или разные. Скорее всего, среди них могут попадаться и затёсываются таки со своим материалом (своей частью – другой) и другие, вероятно тоже имеющие около 5% материала каждый (но может быть и меньше, и может быть и больше). Но они приходят и уходят (ключевое слово, точнее – ключевые слова, здесь "приходят и уходят"), а торрент-клиент, видимо, успевает их зафиксировать (с их частями, которых нет у ТС, и которых нет, может ещё у кого из личеров, у многих из них). При этом соединение нестабильно, постоянно соскальзывает в виду как малой части раздаваемого, так и малых скоростей. Это хорошо видно, когда вместе со, скажем, тремя-четырьмя "хорошими" загрузками (с достаточным количеством сидов, и, соответственно, высокой скоростью) одновременно закачивается и проблемная, та самая, где соединение не стабильно. Пусть на ней вообще не будет личей, а будет только один сид. Какой у него пропускной канал, и почему он отдаёт с маленькой скоростью (может, чем ограничивает?) – вопрос, по сути, малосущественный, т. к. в такой ситуации он обречён отдавать мало, проигрывать конкурентам с "хороших" раздач. Для нас же важно, что он то появляется в пирах, то исчезает – соединение с ним не стабильно, причём на постоянной основе не стабильно, если можно так выразиться. Сегодня (сейчас) у меня как раз такой случай.
А что до данной обсуждаемой, уже в том числе, и другими подключившимися "выносителями мозга" ситуации, то надо заметить, что даже баг должен быть как-то объяснён. Понятно, что – ерунда. Понятно, что мы имеем на выходе "купание сферического коня в вакууме". Но это ведь не просто глюк из-за какого-то сбоя или зависания системы, в данном случае – программы, поэтому можно говорить о том, что наша задача найти или уловить закономерность поведения клиента. Моё объяснение, изложенное выше может быть и на тоненького, но только тАк я – пока – вижу объяснение данной сложившейся и приводящей нас всех в изумление картины. Думаю, что торрент-клиент видит всЕ части в какой-то момент у то появляющихся, то уходящих личеров (важно подчеркнуть – разных и действительно трудноотслеживаемых в реальном времени), и из-за опоздания реагирования, возможно, он их видит (но не фиксирует для нас, не успевает из-за реакции, как у шахматиста) в какой-то момент (для него – больший, чем просто мгновение) всех. Хотя часть из них (с недостающим материалом) – кто их знает – может уже ушла, но, скорее всего, ненадолго, и вероятнее всего – ещё вернётся, причём не раз.
anya1956 писал(а):
66104790
Рapant писал(а):
66104373
anya1956 писал(а):
66104241клиент, естественно, выдает оставшееся время
Вопрос - оставшееся до чего, если на раздаче нет полного источника?
Скорее всего - виртуальную цифру исходя из полного размера раздачи и текущей скорости. Реально - ерунду.
Не исходя из полного размера раздачи и текущей скорости, а исходя из этой формулы:
(Объём файла - Объём скачанного)/Текущая скорость
Клиенту наплевать на наличие полного источника файла и он будет считать до тех пор пока не скачает последний отсутствующий у него байт из числа имеющихся в сети, а далее будет бесконечность пока не появятся в сети не имеющиеся байты файла.
Чтобы не видеть ерунду, надо видеть скорость в Байт/с.
В таком случае бесконечности бы не было, а появлялась бы она, если я правильно понял, только когда все файлы личерами были бы отданы и закачка останавливалась бы. Но на практике-то мы имеем и закачку и бесконечность, причём в том числе в тех случаях, когда загружаться файлы должны ещё достаточно долго (разница в объёме материала у ТС и личера (личеров) существенна).
|
|
|
|
lososnooley
Стаж: 10 лет 5 месяцев Сообщений: 113
|
lososnooley ·
07-Дек-14 20:59
(спустя 1 час 33 мин., ред. 07-Дек-14 20:59)
жук555 писал(а):
66098283Как такое может быть?
1) На вкладке Информация посмотри Потеряно:
2) Бывает, если скачать, удалить, скачать еще раз.
lososnooley писал(а):
66098109Почему у меня во время загрузки Время отображается или бесконечность, или, предположительно, ожидаемое время раздачи?
Ап.
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
07-Дек-14 21:02
(спустя 3 мин.)
lososnooley
А Вы выше читаете сообщения?
Там по обоим пунктам написано достаточно...) Вроде как)
|
|
|
|
Avatar-Lion
Стаж: 16 лет 1 месяц Сообщений: 7651
|
Avatar-Lion ·
07-Дек-14 22:19
(спустя 1 час 16 мин., ред. 07-Дек-14 22:19)
Такой вопрос: можно ли запретить uTorrent отдавать файлы после достижения указанного порога входящей скорости? Например, до тех пор, пока качается со скоростью меньше 8Мбайт\с - все раздачи раздаются. Как только скорость скачивания перевалила за 8Мбайт\с - любая отдача тормозится. Я знаю, что он и так приоритет на скачивание отдаёт, но дело в том, что у меня с харда родители смотрят (по сети) что-то своё. Как следствие, диск просто не справляется с такой нагрузкой (запись скачанного + отдача кучи мелких запросов + отдача по сети родителям).
P.S. И ещё один вопрос вдогонку: можно сделать так, чтобы в случае перегрузки диска скачивание шло напрямую в RAM с последующим сбросом на хард, когда перегрузка пропадёт?
|
|
|
|
anya1956
Стаж: 15 лет 1 месяц Сообщений: 889
|
anya1956 ·
07-Дек-14 23:19
(спустя 59 мин.)
жук555 писал(а):
66105609
скрытый текст
anya1956 писал(а):
66104241Клиент будет показывать данные в клиенте согласно своему алгоритму. Помешать этому могут, например, кратковременные зависания клиента.
Показания в uTorrent в байтах отсутствуют (в qBitTorrent есть) и поэтому отсутствие скорости загрузки в клиенте в столбце скорость вовсе не означает, что загрузки в клиенте нет. Чем меньше скорость приема, тем больше оставшееся время и клиент, естественно, выдает оставшееся время в минутах, часах, днях, неделях, месяцах, годах. Но не думаю, что разработчики заложили показ столетиями, т.е. при достижении какой-то величины клиент просто будет выдавать знак бесконечности.
Не думаю , что дело в настолько малой скорости загрузки, что отображающий её как минимум к килобайтах в секунду uTorrent пренебрегает маленькими значениями. Ведь тот же служебный трафик измеряется в килобайтах в секунду, и тогда чётко ясно (и видно), что ничего не загружается при этом. На уже скачанных-то раздачах.
Вероятно, всё же полный источник (100% материала) суммарно у личеров есть. На скриншотах видно, что личеры имеют примерно по 5% материала. Их от 11 до 17 человек в разные периоды времени, при том что качающий ТС имеет также около 5% скачанного. Сумма файлов у этих 17-ти личеров составляет меньше 100% и меньше 95% с учётом имеющейся части у ТС. Но меньше ненамного. Личеры приходят и уходят, и довольно трудно отследить: одни и те же эти 17 человек торгуют файлами-частями или разные. Скорее всего, среди них могут попадаться и затёсываются таки со своим материалом (своей частью – другой) и другие, вероятно тоже имеющие около 5% материала каждый (но может быть и меньше, и может быть и больше). Но они приходят и уходят (ключевое слово, точнее – ключевые слова, здесь "приходят и уходят"), а торрент-клиент, видимо, успевает их зафиксировать (с их частями, которых нет у ТС, и которых нет, может ещё у кого из личеров, у многих из них). При этом соединение нестабильно, постоянно соскальзывает в виду как малой части раздаваемого, так и малых скоростей. Это хорошо видно, когда вместе со, скажем, тремя-четырьмя "хорошими" загрузками (с достаточным количеством сидов, и, соответственно, высокой скоростью) одновременно закачивается и проблемная, та самая, где соединение не стабильно. Пусть на ней вообще не будет личей, а будет только один сид. Какой у него пропускной канал, и почему он отдаёт с маленькой скоростью (может, чем ограничивает?) – вопрос, по сути, малосущественный, т. к. в такой ситуации он обречён отдавать мало, проигрывать конкурентам с "хороших" раздач. Для нас же важно, что он то появляется в пирах, то исчезает – соединение с ним не стабильно, причём на постоянной основе не стабильно, если можно так выразиться. Сегодня (сейчас) у меня как раз такой случай.
А что до данной обсуждаемой, уже в том числе, и другими подключившимися "выносителями мозга" ситуации, то надо заметить, что даже баг должен быть как-то объяснён. Понятно, что – ерунда. Понятно, что мы имеем на выходе "купание сферического коня в вакууме". Но это ведь не просто глюк из-за какого-то сбоя или зависания системы, в данном случае – программы, поэтому можно говорить о том, что наша задача найти или уловить закономерность поведения клиента. Моё объяснение, изложенное выше может быть и на тоненького, но только тАк я – пока – вижу объяснение данной сложившейся и приводящей нас всех в изумление картины. Думаю, что торрент-клиент видит всЕ части в какой-то момент у то появляющихся, то уходящих личеров (важно подчеркнуть – разных и действительно трудноотслеживаемых в реальном времени), и из-за опоздания реагирования, возможно, он их видит (но не фиксирует для нас, не успевает из-за реакции, как у шахматиста) в какой-то момент (для него – больший, чем просто мгновение) всех. Хотя часть из них (с недостающим материалом) – кто их знает – может уже ушла, но, скорее всего, ненадолго, и вероятнее всего – ещё вернётся, причём не раз.
anya1956 писал(а):
66104790
Рapant писал(а):
66104373
anya1956 писал(а):
66104241клиент, естественно, выдает оставшееся время
Вопрос - оставшееся до чего, если на раздаче нет полного источника?
Скорее всего - виртуальную цифру исходя из полного размера раздачи и текущей скорости. Реально - ерунду.
Не исходя из полного размера раздачи и текущей скорости, а исходя из этой формулы:
(Объём файла - Объём скачанного)/Текущая скорость
Клиенту наплевать на наличие полного источника файла и он будет считать до тех пор пока не скачает последний отсутствующий у него байт из числа имеющихся в сети, а далее будет бесконечность пока не появятся в сети не имеющиеся байты файла.
Чтобы не видеть ерунду, надо видеть скорость в Байт/с.
В таком случае бесконечности бы не было, а появлялась бы она, если я правильно понял, только когда все файлы личерами были бы отданы и закачка останавливалась бы. Но на практике-то мы имеем и закачку и бесконечность, причём в том числе в тех случаях, когда загружаться файлы должны ещё достаточно долго (разница в объёме материала у ТС и личера (личеров) существенна).
1. Клиент qBitTorrent показывает скорость файлообмена до 1 Байт/с. Не думаю, что uTorrent не умеет считать скорость файлообмена в Байт/с.
2. Отсутствие показа скорости файлообмена в Байт/с не означает, что uTorrent игнорирует маленькие значения скорости файлообмена - просто разработчики не сочли, что есть необходимость показа скорости файлообмена в Байт/с.
3. Скорость служебного трафика в клиенте не учитывается при показе оставшегося времени загрузки файла.
скрытый текст
Во время отдачи поставьте галочку "Применить ограничение к служебному трафику" и увидите другие скорости приема, но от того, что там совсем другие величины не увидите изменений в скорости отдачи.
скрытый текст
Просто к сведению: Служебный трафик не влияет и на учет параметров файлообмена в профиле аккаунта.
4. Если файл раздается первый раз, то у пиров нет больше частей, чем раздал автор раздачи.
скрытый текст
Больше может быть только тогда, когда раздача уже размещена ранее кем-то где-то и в сети интернета уже есть больше частей, чем у автора раздачи.
5. Если Вы про скриншоты AssassinsssRTOsss ( https://rutr.life/forum/viewtopic.php?p=66103638#66103638 ), то они не противоречат формуле:
(Объём файла - Объём скачанного)/Текущая скорость=Оставшееся время загрузки файла
скрытый текст
Скорее всего файл свежий, так как такую картину данных по пирам увидеть на старом файле вероятность практически нулевая и поэтому пиры не имеют больше частей, чем указано на скриншотах.
скрытый текст
Не удивлюсь, если сам автор вообще не раздает, т.е. все части поступают по DHT.
6. Личеры могут приходить и уходить, но из-за этого клиент искажать оставшееся время загрузки файла не будет.
7. Нестабильное соединение не повод искажения оставшееся время загрузки файла.
скрытый текст
Нестабильное соединение это повод для удлинения общего времени загрузки файла - в таких случаях клиент имеет Загружено, как правило, больше размера файла.
8. Наличие Сидов не повод не увидеть бесконечность в столбце Оставшееся время, например, сами Сиды заняты отдачами других файлов или заняты сильно загрузками и скорость отдачи в клиентах подавлена проблемами, возникающими при загрузках файлов.
9. Поведение клиента закономерно и помешать этому могут только проблемы по согласованной работе программ в ОС, проблемы по исправности самого клиента, кратковременные зависания клиента.
10. Наличие времени при отсутствии данных в столбце скорость не является ерундой - просто в клиенте не предусмотрен показ скорости приема в Байт/с.
11. Глюк от зависаний кратковременный и он объясняется особенностями показа параметров файлообмена - в компьютере нет механических узлов, как, например, в спидометре транспорта.
12. На показ оставшегося времени загрузки файла не влияет способность клиента видеть пиров в сети - влияют только клиенты, отдающие части файла.
13. Это: Разница в объёме материала у ТС и личера (личеров) существенна клиенту без разницы, так как клиент умеет выполнять только это:
(Объём файла - Объём скачанного)/Текущая скорость=Оставшееся время загрузки файла
Примечание:
скрытый текст
Задача Вам, которая напоминает ход обсуждения про оставшееся время.
Между городами минимальное расстояние по автомобильной дороге 1000 км. Автомобиль строго преодолел расстояние по минимальному маршруту. По показанию спидометра пройденное расстояние 1500 км. Возможно ли это?
Неисправность спидометра не предлагать.
|
|
|
|
тыщ
Стаж: 16 лет 7 месяцев Сообщений: 1427
|
тыщ ·
08-Дек-14 02:36
(спустя 3 часа, ред. 08-Дек-14 04:08)
lososnooley писал(а):
66106825
lososnooley писал(а):
66098109Почему у меня во время загрузки Время отображается или бесконечность, или, предположительно, ожидаемое время раздачи?
Ап.
µT User Manual писал(а):
If the torrent job is transferring too slowly, or has reached its seeding goal, this field will display the ∞ symbol.
ETA - ожидаемое время завершения (сначала - закачки, затем, по окончании закачки, - достижения порога раздачи).
скрытый текст
ETA в списке торрентов
ETA displays the estimated amount of time needed for µTorrent to finish downloading the torrent job. If the torrent job is in seeding mode, then this column displays the estimated time it will take for µTorrent to reach the seeding goal. If the torrent job is stopped or has reached its seeding goal, this column will be blank. If the torrent job is transferring too slowly, this column will display the ∞ symbol. Note that this column takes selective file downloading into account, so only the data you select to be downloaded will be counted in the time calculation.
---
Идентично Remaining на вкладке Info.
Remaining displays the estimated amount of time needed for µTorrent to finish downloading the torrent job. If the torrent job is in seeding mode, then the ETA displays the estimated time it will take for µTorrent to reach the seeding goal. If the torrent job is stopped, this field will be blank. If the torrent job is transferring too slowly, or has reached its seeding goal, this field will display the ∞ symbol. Note that this field takes selective file downloading into account, so only the data you select to be downloaded will be counted.
Rus1am89 писал(а):
66104146оттуда же будет выставляться приоритет в зависимости от количества пиров/сидов, например раздача для которой долгое время не было раздающих выставлять высший приоритет в противовес тем у которых много раздающих.
Этот велосипед уже есть в доп.настройках:
queue.use_seed_peer_ratio,
queue.prio_no_seeds.
Впрочем, хозяин — барин.
Avatar-Lion писал(а):
66108134можно сделать так, чтобы в случае перегрузки диска скачивание шло напрямую в RAM с последующим сбросом на хард, когда перегрузка пропадёт?
А сейчас, по-вашему, как? Где находятся кэши ОС и клиента?
Avatar-Lion писал(а):
66108134у меня с харда родители смотрят (по сети) что-то своё. Как следствие, диск просто не справляется с такой нагрузкой (запись скачанного + отдача кучи мелких запросов + отдача по сети родителям)
А как в этом случае работает Stop transfers on user interaction (галка в секции "Скорость" настроек)? Или там только мышь и клава отслеживаются?
Попробуйте на uTP переключиться.
|
|
|
|
lososnooley
Стаж: 10 лет 5 месяцев Сообщений: 113
|
lososnooley ·
08-Дек-14 02:42
(спустя 5 мин.)
тыщ писал(а):
66110574If the torrent job is in seeding mode, then this column displays the estimated time it will take for µTorrent to reach the seeding goal.
А если нет - то время до скачивания? А у меня - наоборот. ∞, скорее всего, значит время раздачи, потому что качалось оно приемлемо.
|
|
|
|
тыщ
Стаж: 16 лет 7 месяцев Сообщений: 1427
|
тыщ ·
08-Дек-14 03:19
(спустя 37 мин., ред. 08-Дек-14 03:19)
lososnooley
ETA - ожидаемое время завершения (сначала - закачки, затем, по окончании закачки, - достижения порога раздачи).
|
|
|
|
lososnooley
Стаж: 10 лет 5 месяцев Сообщений: 113
|
lososnooley ·
08-Дек-14 04:27
(спустя 1 час 7 мин.)
Так у меня во время закачки показывало, судя по всему, ETA до достижения порога раздачи, потому что на ETA раздачи оно не тянуло ну никак. Вообще впечатление о 3.x как о какой-то *** бете.
Выбирайте выражения!
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
08-Дек-14 12:11
(спустя 7 часов)
Имеются два диска D:\ и F:\ на винчестере (диск С:\ – системный).
Можно ли многофайловую раздачу загружать и на диск D:\ и на диск F:\ одновременно: часть файлов – на диск D:/, а часть файлов – на диск F:\ ?
|
|
|
|
Л. М. Гога
Стаж: 16 лет 1 месяц Сообщений: 19080
|
Л. М. Гога ·
08-Дек-14 12:21
(спустя 10 мин.)
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
08-Дек-14 13:04
(спустя 43 мин.)
Л. М. Гога
Там про Перемещение скачанных файлов в µTorrent
До закачки можно определить разные места загрузки файлов (папок) в одной многофайловой раздаче?
|
|
|
|
Dyavlik
Стаж: 15 лет 5 месяцев Сообщений: 852
|
Dyavlik ·
08-Дек-14 13:14
(спустя 10 мин.)
жук555
Не думаю. Я вижу только 1 вариант, запуск двух клиентов и двух раздач в них, один будет качать одну часть файлов на один диск, другой другую на второй.
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
08-Дек-14 14:08
(спустя 53 мин.)
жук555 писал(а):
66113501До закачки можно определить разные места загрузки файлов (папок) в одной многофайловой раздаче?
Можно.
|
|
|
|
жук555
Стаж: 12 лет 1 месяц Сообщений: 1698
|
жук555 ·
08-Дек-14 14:36
(спустя 27 мин.)
Рapant
А как будет происходить скачивание пограничных блоков?
|
|
|
|
Papant
Стаж: 17 лет 3 месяца Сообщений: 56409
|
Papant ·
08-Дек-14 15:40
(спустя 1 час 4 мин.)
жук555
Надо попробовать..
|
|
|
|
