Обсуждение µTorrent версий 2.+

Добрый вечер, возник вопрос, если сбросить настройки клиента по умолчанию (удаление файлов settings.dat и settings.dat.old), раздачи в клиенте пропадут?

Нет. Список раздач с путями к ним - хранится в файлах resume.dat
Но не помешает сделать бекакп - µTorrent и переустановленный Windows, или что нужно было сделать заранее

Это я всегда делаю))). Спасибо.

Подскажите, пожалуйста, можно ли в utorrent настроить время обновления торрента?

DrPilman
Нет.

Заметил такую странность. С чем связано, не знаю.
Когда раздаешь одну раздачу на 2,3 трекера, на одном из них иногда появляется ошибка в uTorrente, якобы не хватает 0,1% файлов (как правило это .log, .cue, m3u, .cover и редко кусок .flac) приходится перехешировать с одного из других трекеров и докачивать эти файлы. Такое наблюдал и на старом и на новом диске. Что интересно, релизы мои, т.е. ошибок при скачивании быть не может, файлы изначально на диске. Грешу на 2.2.1

maximus_lt
Скорее всего система, антивирусник, проигрыватель, оптимизатор, дефрагментатор и прочее...

maximus_lt
Лучше ставить атрибут Только чтение.. на раздаваемые файлы.

Скорее всего система - Win ?
Антивирусник - стандартный. Не на что там ругаться, это же не исполняемый файлы.
Проигрыватель - только проигрывание, без редактирования тегов.
Оптимизатор - не использую.
Дефрагментатор - стандартный, запуск вручную раз раза 2 в год.
Если не исключать все вышеперечисленные варианты, почему только CUE LOG COVER M3U и только на некоторых, а не на всех альбомах ?
Что можете посоветовать для тестов из 2-й серии ? Хорошая идея. Узнать бы причину, т.к. я спрашивал у пользователей, кто раздает на несколько трекеров и у них такого не наблюдалось.
P.s. Возможно кто-то еще отпишется с похожими симптомами.

У меня как-то раз (тоже на собственной раздаче) пользователи пожаловались, что она не докачивается (я был один в сидах). Перехешировал — 99%. Стал проверять — оказалось, что в одном из треков (FLAC) записался лишний тег (точнее, скопировался имеющийся). Как такое произошло — без понятия. С тех пор и ставлю на всё read-only (собственно, это мой совет).
Подобные случаи, похоже, крайне редки, так что узнать что-то сложно.

С flac понятно, но как можно случайно изменить Cover ?

maximus_lt
А вы уверены, что это именно cover поменялся? Все файлы, которые входят в изменённую часть, будут считаться недокачанными, даже если в них самих ничего не менялось.
Впрочем, в картинках тоже есть изменяемые свойства.
По идее, можно узнать, что именно изменилось, сделав копию побившейся раздачи перед тем, как её докачивать. А потом сравнить с докачанной. Сразу будет видно, что и где поменялось (правда, как именно это произошло, навряд ли станет понятно).
Вообще, по-моему, все раздачи полезно время от времени перехешировать. Так, на всякий случай. Где-нибудь раз в год, к примеру, останавливать всё и перепроверять.

Л. М. Гога? судя по скринам, какая то нездоровая закономерность.

maximus_lt
Мне кажется, это CUE. Но точно узнать можно, только сравнив: Т. е. в следующий раз, обнаружив несовпадения, копируете куда-нибудь несовпадающие файлы, потом докачиваете, потом сравниваете.

Грешить не версию нельзя, так как она не капризная, честная и преданная хозяину своему до гроба, т.е. налево не ходит.
Грешите на диск, так как они прямо с молодости могут быть капризными, т.е. ещё с момента покупки могут иметь плохие участки, препятствующие:
а) записи файлов на диск (появляется ошибка CRC и запись файла останавливается);
б) чтению файлов с диска (записи они не мешали, так как состояние этих мест было не таким плохим, чтобы появлялась ошибка CRC).
Решением проблемы является перенос файлов на отформатированный диск с последующим форматированием диска с плохими участками для записи файлов на диск и чтения с диска.
Можно исправить и с меньшей трудоемкостью: Папку "OST - Spencer Nilsen - ... ___Не трогать!!!", т.е. копию (бывший оригинал) сохранить, чтобы впоследствии при загрузке файлов не использовать плохо читаемые участки диска.
Если столкнетесь с этой проблемой на огромной раздаче, то можно найти конкретное плохо читаемое место и сделать аналогичное исправление, оставив копию файла или подпапки на своём месте.
У меня, например, в раздаче объёмом 393 ГБ есть проблемное плохо читаемое место на диске, которое охватывает место для записи 1,97 ГБ частей одной подпапки. Исправил вышеуказанным образом. Указанная Вами проблема не зависит от клиента, так как относится к проблемам диска по чтению частей файлов с диска и записи файлов на диск.
Отвечал на эту тему много раз и одно из моих любимых утверждений на эту проблему: "На диске может быть много не читаемых или плохо читаемых участков, но об этом хозяин диска может никогда и не узнать, если при раздаче файлов качающие клиенты с этих мест не будут скачивать части файлов, т.е. качающие клиенты части файлов, находящиеся на этих местах, будут скачивать от других отдающих клиентов.". Если хозяин диска раздает раздачу в одиночестве, то, конечно, ему не избежать "Error: The system cannot find the file specified. (Ошибка: Система не может найти указанный файл.)", так как в файлообмене раздачи только он имеет все части файла и клиент его будет вынужден раздавать и части файла, находящиеся на участках с проблемами чтения с диска.
Если при раздаче файлов с диска, имеющего участки с проблемами чтения частей файлов не появляется ошибка "Error: The system cannot find the file specified. (Ошибка: Система не может найти указанный файл.)", т.е. эти участки ещё не дошли до состояния появления ошибки "Error: The system cannot find the file specified. (Ошибка: Система не может найти указанный файл.)", то клиент может пытаться раздавать части файла с участков с проблемами чтения очень долго (до тех пор пока не заметит проблему с раздачей файла качающий или отдающий (конечно, чаще всего заметит качающий (отдающие, как правило не замечают, но на практике был один случай, когда заметил отдающий (аккаунт az.....) по количеству отданного одному и тому же качающему намного больше объёма раздачи, а качающий даже не заметил))).
Способ решения проблемы такой же, что указан выше аккаунту maximus_lt, но можно попробовать исправить ситуацию повторной записью файла: После этого сообщения причиной проблемы может оказаться и написанное аккаунтом Postoronnim_23 в сообщении https://rutr.life/forum/viewtopic.php?p=78954813#78954813 : Да, и сам я про это писал с другого аккаунта, например, в сообщении от 2018-09-20_0821: https://rutr.life/forum/viewtopic.php?p=75991242#75991242 (см. пункт 2).
Конечно, версию клиента обвинять нельзя, так как из моих основных 13 экземпляров BitTorrent 7.2.1 проблема с "Ошибка: Не удаётся найти указанный файл." из-за .!bt была только в одном экземпляре клиента BitTorrent 7.2.1 и поэтому в этом экземпляре BitTorrent 7.2.1 перед строкой "Append .!bt to incomplete files" галочка отсутствует, а в остальных 12 экземплярах BitTorrent 7.2.1 галочка перед строкой "Append .!bt to incomplete files" присутствует.
Написанное аккаунтом Postoronnim_23: "Достаточно доделать работу utorrent-а, т.е. убрать дополнительное .!ut и это помогает." верно только для малого количества файлов с .!ut, а при огромном количестве их необходимо запустить раздачу и дождаться исчезновения .!ut (в uTorrent) или .!bt (в BitTorrent):

Кто нибудь может проверить во 2й версии у вас работает быстрый поиск по списку на русском (типа нажимаешь букву и выделение переходит на торрент с первой буквой которую нажали)?
У меня работает только с английскими названиями. Проблема в том что я не помню раньше с русскими работало или нет.

xRobotx
Вы уже спрашивали об этом где-то. За это время сами так и не смогли проверить, установив ещё пару (пару десятков) клиентов?
У меня с русскими буквами не работает.

У меня в 2.0.4 и с английскими не работает.

Л. М. Гога
У меня с цифрами и англ. работают 2.0.4 и 2.2.1.

Hannibal61
Всё, разобрался. У меня все первые буквы в верхнем регистре. Там регистрозависимо, нужно шифт держать.
Работает, и с русскими буквами тоже работает.

---

UPD. С такими буквами, как Б и Ю, например, не работает.

Л. М. Гога
Хм... Английским буквам всё равно, а вот русские регистрозависимые.

А теперь работает.
И английские теперь, да, без регистра работают.
Но раньше не работали же, несколько раз проверял.
Короче, оно то работает, то нет.

---

Да и нужно ли оно вообще? Если бы там был поиск нормальный, а одна буква всё равно ничего не даёт, и так всё по алфавиту отсортировано.

Л. М. Гога
У меня, например, в 2.0.4 отсортировано по дате добавления - тем более такой поиск бесполезен.

Всем спасибо за тесты.
Проверил с шифтом -- русские названия находит (2.2.1).

Вам не кажется это подозрительно ? Диск капризничает исключительно на некоторые релизы, на конкретные файлы .log .cue. m3u .jpg ?

maximus_lt
Не читайте ту пургу, что несёт этот персонаж.

Нет ничего подозрительного, так как ваши: "Что интересно, релизы мои, т.е. ошибок при скачивании быть не может, файлы изначально на диске.", означают, что релизы на вашем диске, имеющем плохо читаемые или даже не читаемые участки.
Прочитайте из сообщения https://rutr.life/forum/viewtopic.php?p=79064987#79064987 часть эту: "Отвечал на эту тему много раз и одно из моих любимых утверждений на эту проблему: "На диске может быть много не читаемых или плохо читаемых участков, но об этом хозяин диска может никогда и не узнать, если при раздаче файлов качающие клиенты с этих мест не будут скачивать части файлов, т.е. качающие клиенты части файлов, находящиеся на этих местах, будут скачивать от других отдающих клиентов.". Если хозяин диска раздает раздачу в одиночестве, то, конечно, ему не избежать ...". Вместо точек можно продолжить: "вашей проблемы.". Согласно вашему скриншоту: затронут и .flac, т.е. могут быть затронутыми любые типы файлов. Если даже ваше сообщение будет выглядеть следующим образом: "... релизы мои, т.е. ошибок при скачивании и при отдаче быть не может, так как файлы изначально на диске.", то утверждение не имеет никакую силу, так как проблемный участок легко может дать записать части файла, но при чтении с этого места могут быть проблемы.
Плохо читаемый участок не означает, что с этого места невозможно достать части файла, так как при переносе файла копированием на другое место файл может даже полностью перенестись и даже можно этим же перенесенным на другое место файлом исправить файл, находящийся на исходном месте, конечно, не во всех случаях, т.е. зависит от степени читаемости с плохо читаемого участка: Примечание:

ANINFORTOMTSRTCSSS, уже писал, что диск поменян на другой, другого объема и фирмы. Когда то раздачи были разбиты на 2 hdd. Т.е. ситуация повторилась на 3-х дисках. Кабели тоже заменены. Память протестирована из DOS с помощью Memtest - ошибок нет. С тегами в проигрывателях не работаю, тем более не редактирую логи и индексные карты. Не могу не кивать в сторону uT.

Простая замена диска ничего не даёт: Плохо читаемый участок не свидетельствует о том, что участок дошёл до состояния выдачи ошибки CRC, т.е. легко может дать записать части файлов, но может не дать читать с диска или дать читать мелкими порциями "бесконечно" долго, когда у качающего в клиенте завершенная часть всегда меньше объёма раздачи, а загруженное количество может исчисляться многими сотнями ГБ и более.
Я сам находил таких раздающих и в качестве эксперимента количество загруженного доводил до 100 ГБ. При этом были даже случаи, когда завершенная часть составляла даже менее 1 МБ. Бывали и случаи, когда по ходу загрузки раздачи завершенная часть даже уменьшалась, например, уже было 500 КБ завершенной части, а через некоторое время стало менее 100 КБ.
Чтение с плохо читаемых мест может даже сопровождаться с шумом работы диска и даже этот шум может быть очень громким. Один из пользователей трекера из вашей страны на этом трекере приводил даже видео работы диска с достаточно большим шумом.
Плохо читаемые участки диска, например, могут воспрепятствовать одновременному большому объёму переноса файлов, но позволить перенос файлов мелкими порциями.
Плохо читаемые участки диска можно увидеть даже визуально, например, при переносе или копировании файлов на графике скорости переноса образуются участки с явным провалом скорости переноса файлов.
Вы пробуйте из того, что вам написано. Можете пробовать для своего случая и вариант замены клиента, но плохо читаемые участки диска не обращают внимания на версию или тип клиента.
Если не будете пробовать, то взаимные ответы могут продолжаться и не приведут к решению проблемы.

ANINFORTOMTSRTCSSS, никогда диск не шумел - ни старый, ни новый. Информацию со старого диска копировал всю целиком - 2тб. Далее, после запуска uT перехешировал все раздачи - 100%. Проблема повторилась позже, спустя пару месяцев, и только на релизах которые раздаются на несколько трекеров. Другие этим не страдали.
Вот что предположил один из релизеров - при сидировании одного релиза на несколько трекеров, надо включать Source-Option, но не везде есть такие настройки: