Техническая поддержка Кинозал.ТВ

Поиск на форуме

Ответы на частые вопросы:

• Правила проекта Кинозал.ТВ
• Не могу зайти в Кинозал.ТВ - инструкции
• Звания и статусы на трекере Кинозал.ТВ
• Количество доступных к скачиванию торрент-файлов
• Рейтинг и учет статистики
• Как скачать раздачу и как начать сидирование
• Как открыть порты
• Оформление раздач
• Раздел компьютерной безопасности
• Статус "Король трекера" и для чего он нужен?
• Штрафы за скачивание
• Как сделать пинг (ping) и трассировку (tracert) сервера
• Группа Разработчиков и Технической поддержки

Если после прочтения вышеозначенных тем у вас остались вопросы, то можете задать их в этой теме.

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

KniazidisR сказал(a):

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

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

ФАНАТ сказал(a):

У вас на скриншоте анонсер tr4. Но раздача зарегистрирована на tr0. Торрент-файл скачивается с tr0-анонсерами. А трекер tr4, логично, будет говорить "unregistered torrent". Тут никакого чуда

Спасибо, что заметили мою ошибку. Сам на этот раз свою ошибку заметил бы намного позднее. Дело в том, что сегодня я захотел почему-то проверить эту ошибку непрактичным способом, т.е. запуском загрузки файла с другого клиента. Ранее просто изменял после tr цифры до появления статуса (состояния) трекера "Работает". Теперь уже необходимости проверки нет из-за найденной Вами моей ошибки, т.е. избавили меня от лишней загрузки файла.
Такую ошибку уже совершаю не в первые, по крайней мере уже было не менее 5 раз. Сам механизм ошибки следующий (не в качестве оправдания своего промаха, так как я уже признал свою ошибку):

Cкрытый текст -

 

1. Торрент-файлы скачиваю с открытой страницы браузера. В данном случае вход на трекер был с основного аккаунта и торрент-файлы были скачаны с основного аккаунта. С основного аккаунта загружаю только раздачи, предназначенные для отдачи. Для всех остальных случаев есть аккаунты для экспериментов.
2. В данном случае как всегда замену анонсера сделал, копируя из свойств раздачи с соответствующим анонсером, т.е. в анонсере по моему разумению ошибку не совершал, т.е. при замене всё было внешне сделано правильно, но мой мозг забыл, что во всех моих компьютерах практически всегда мало свободной памяти и после выполнения действий необходима перепроверка выполненного ОС, т.е. при очень малой свободной памяти ОС не всегда копирует выделенную курсором мыши область. Если перед последним копированием уже было копирование другого фрагмента текста (в данном случае другого анонсера), то во время замены анонсера ОС заменит анонсером, который ОС запомнила в предыдущем действии. В моём случае предыдущим действием как раз было запоминание анонсера tr4, а tr0, который ОС не смогла запомнить из-за малой свободной памяти в ОС.
Эта ошибка бывает не только с анонсерами, но и с любым объектом копирования. В любом другом случае это проявляется быстро без всякой проверки (открывается не то, что требуется или сразу обнаруживаешь, что вставленное это не то, что скопировано), но с анонсерами быстро не обнаруживается, так как они от глаз спрятаны более глубже, т.е. всегда требует проверки.

От своей цитаты: "Такие случаи, когда не все одинаково видят бывают. Некоторые из них из своей практики файлообмена приведу позднее. Не все они относятся к этой конкретной проблеме, но просто они доказывают, что "чудеса" бывают.
Конечно, они чудесами останутся до тех пор пока не будут найдены конкретные причины "чуда"." не отказываюсь и приведу их позднее. Один из примеров попробую привести до окончания дня, ну может слегка опоздаю. Этот пример, видимо, и является объяснением происходящего у KniazidisR.

KniazidisR сказал(a):

Cкрытый текст -   Оригинал-1,36 ГБайт, двойник - 1,05 ГБайт, я его не имею, не скачивал, и не ставил сидировать

Многие наверно видели во время процесса копирования или переноса файлов с одного места в другое место окно, в котором ОС запрашивает о будущем ее действии, т.е. спрашивает переместить файл с заменой или оставить предыдущий из-за того, что в ОС нельзя иметь в одном месте (папке) файлы одного типа с одинаковыми наименованиями. В этом случае пользователь интернета не теряется и сообщает ОС что делать. Если хозяин компьютера сообщит ОС "С заменой", то файл в папке будет заменен переносимым файлом.
Но в файлообмене есть как говорят в народе "подводный камень" с этим свойством ОС и не каждый может обнаружить его. Суть проблемы следующая:
В интернете авторы раздач часто файлам дают короткие наименования. Поэтому в интернете достаточно много разных файлов с одним и тем же наименованием и они иногда с одним и тем же наименованием могут оказаться в одном и том же клиенте. В своей практике файлообмена встречался не менее 10 раз.
Клиент позволяет иметь файлы одного наименования в клиенте, если они разные и поэтому качающий не замечает этот "подводный камень" и последствии наличия "подводного камня" обнаруживает только через некоторое время. А это некоторое время может быть очень длительным, если качающий не сразу заинтересуется скачанным файлом. Обнаружит тогда, когда обнаружит пропажу файла без его участия.
При скачивании файлов с одним и тем же наименованием клиентом ОС не подсказывает, что в папке уже есть файл с таким же наименованием и такого же типа. Поэтому скачиваемый файл заменяет имеющийся в папке файл, который имеет такое же наименование и такой же тип, что и скачиваемый.
В результате скачиваемый файл в компьютере сохраняется, а файл, который был, на диске исчезает.
Скачанный последним файл будет раздаваться, а раздача, которая исчезла из компьютера, будет иметь в статусе (состоянии) трекера ошибку.

Выход из этой ситуации: Сохранение файлов одного и того же типа с одинаковым наименованием в разных папках.

Примечание 1:
1. Если файлы в папках и наименование папок совпадают, то загружаемая папка не вытеснит папку, которая загружалась ранее, так как загружаемая папка вообще не будет иметь папку свою, а загружаемые файлы будут загружаться в имеющуюся папку.
При этом если в загружаемом файле не будет файлов с наименованиями совпадающими с какими-нибудь файлами имеющейся папки, то обе раздачи будут раздаваться нормально, находясь в одной папке.
Если попадутся файлы с одинаковыми наименованиями в двух раздачах (в двух папках), то загружаемые файлы заменят предыдущие и первая раздача в статусе трекера будет иметь ошибку, а вторая будет раздаваться, так как она будет иметь все файлы.
На этом трекере я попадался на эту проблему на игровых файлах, так как они очень многие имеют несколько одинаковых файлов типа: Setup, data, data1, data2, ... .

2. Раздачу можно вывести из строя и поспешными действия во время запуска следующей раздачи, например, тогда, когда путь сохранения файла полностью не прописан в клиенте. В этом случае файлы загружаются в общую папку загрузки файлов и если предыдущий файл был тоже игровым и загружен тоже в общую папку без своей папки, то файлы с одинаковыми наименованиями загружаемой раздачи заменят файлы предыдущей раздачи и предыдущая раздача в статусе трекера будет иметь ошибку, а вторая будет раздаваться, так как она будет иметь все файлы.
Ну, эта ошибка бывает не только у меня, но и у других пользователей интернета, например, из ЛС на трекере:

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

3. Сама проблема существует уже давно. Сам экспериментально участвовал в решении проблемы ещё 2011 году, когда сразу было 3 файла под наименованием "Kristina".
Затем даже нашел тему обсуждения этой проблемы, которая называлась "Некоторые раздачи имеют одинаковые имена файлов" (не на этом трекере и она ещё жива).

4. Написанное для OC семейства Windows.
О правилах хранения файлов в компьютерах с другими ОС не интересовался, так как другими, кроме Windows, пока не пользуюсь.
Возможно, в них что-то ещё проявится.

Примечание 2:

Cкрытый текст -

 

Читать только тем, которые знают о моих мистических числах:

Cкрытый текст -

 

Забавно, что начал отвечать на проблему и даже старые 2011 года в самые плохие мои мистические числа типа 9 и 26.

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

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

Забавляемся с хешами

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

Вот сейчас поставил на раздачу "Дело № 306" из бекапа. Файл проверку на хеш прошёл и начал сидироваться. Через некоторое время раздача покраснела и блокировалась с сообщением теперь уже "ERROR:WRITE-TO-DISK". Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию). Затем только уже подделанный файл раздавался бы без блокирования.

Примечаниие: Похоже, что насчёт опасности видоизменяемых файлов я преувеличил. По сути дела какой-то шутник меняет только 1 байт, что вирусом быть не может. Если это шутник, то шутка принята. Короче - к чёрту.

KniazidisR сказал(a):

Cкрытый текст -   Проверил всё на вирусы - ничего не нашлось - ни в компьютере, ни на внешнем диске. Клиент тоже обновил. Ничего не изменилось - проблема осталась. Интересная статья про возможность подделки файлов, сохраняя при этом правильный хеш, причём не тратя много времени. Забавляемся с хешами Теперь я точно уверен, что мои раздачи - не совсем мои изначальные файлы. По крайней мере, некотрая часть из них. На этом для себя лично закрываю вопрос. Вопрос только в том, кем подделаны раздачи, но это уже менее интересно, факт что так или иначе нет защиты от подделок. Вот сейчас поставил на раздачу "Дело № 306" из бекапа. Файл проверку на хеш прошёл и начал сидироваться. Через некоторое время раздача покраснела и блокировалась с сообщением теперь уже "ERROR:WRITE-TO-DISK". Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию). Затем только уже подделанный файл раздавался бы без блокирования. Примечаниие: Похоже, что насчёт опасности видоизменяемых файлов я преувеличил. По сути дела какой-то шутник меняет только 1 байт, что вирусом быть не может. Если это шутник, то шутка принята. Короче - к чёрту.

KniazidisR сказал(a):

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

Антивирусы на очень многое не реагируют и бывает, что реагируют на безвинные файлы.
Приведите скриншот программы, которая показывает работающие процессы в операционной системе, например, типа Диспетчера задач или другой программы, например, Process Explorer с процессами, работающими в ОС: ?
Заодно и скриншоты:

Cкрытый текст -

 

Системы типа: ?
Состояния служебной папки клиента: ?
Сдержимого общей папки загрузки файлов: ?
Содержимого папки, в которой хранится проблемный файл?
Содержимого папки проблемного файла, если файл имеет свою папку?

KniazidisR сказал(a):

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

Тема интересная, но пока и без этой темы у Вас могут быть проблемы по всяким ошибкам статуса (состояния) трекера и не только по статусу (состоянию) трекера.

KniazidisR сказал(a):

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

Легко проверить. Было бы только желание проверить.

KniazidisR сказал(a):

На этом для себя лично закрываю вопрос.

Не красиво заканчивать рассказ на самом интересном месте.

KniazidisR сказал(a):

Вопрос только в том, кем подделаны раздачи, но это уже менее интересно, факт что так или иначе нет защиты от подделок.

А факт доказательства, что нет защиты от подделок у Вас есть?
Статья "Забавляемся с хешами" не является доказательством того, что файлы можно подделывать. Возможно, автор уже отказался от своей идеи, так как доказательств у него уже нет, т.е. файлов для сравнения уже нет, так как они уже удалены.
Не уверен, что файлы идентифицируются только по хеш-сумме.
Я кажется уже сталкивался с обсуждением этой проблемы и сам тоже участвовал в обсуждении проблемы на другом трекере. Попробую найти это обсуждение.

KniazidisR сказал(a):

Вот сейчас поставил на раздачу "Дело № 306" из бекапа. Файл проверку на хеш прошёл и начал сидироваться. Через некоторое время раздача покраснела и блокировалась с сообщением теперь уже "ERROR:WRITE-TO-DISK". Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию). Затем только уже подделанный файл раздавался бы без блокирования.

Ну, на эту тему в интернете много материалов, например, те, которые попались сразу на глаза:

Cкрытый текст -

 

http://lumpics.ru/error-write-to-disk-itorrent-client/
http://lumpics.ru/utorrent-denied-ac...write-to-disk/
https://windowsten.ru/torrent-otkaza...write-to-disk/

Свою позицию относительно этого выскажу позднее.

KniazidisR сказал(a):

Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию).

Это не свидетельство подделки и оно давно известно. Сам тоже участвовал в обсуждении этой проблемы.
Подробнее позднее, т.е. после ответа Вами на моё сегодняшнее сообщение, так как у меня сегодня мозг почему-то закапризничал и не дает рукам команду, чтобы я сразу ответил.

KniazidisR сказал(a):

Примечаниие: Похоже, что насчёт опасности видоизменяемых файлов я преувеличил. По сути дела какой-то шутник меняет только 1 байт, что вирусом быть не может. Если это шутник, то шутка принята. Короче - к чёрту.

Найду Вам этого шутника, если Вы публично пообещаете мне следующее:

Cкрытый текст -

 

Будете на некоторое время моим рабом:

Cкрытый текст -

 

Не бойтесь не потребую ничего позорного:

Cкрытый текст -

 

Просто создадите несколько экспериментальных поучительных раздач по моим условиям:

Cкрытый текст -

 

Не более 10 и в небольших объёмах.

Система учета трафика файлообмена этого трекера отличается от систем учета трафика файлообмена других трекеров тем, что при раздаче одного и того же файла с двух и более клиентов (с двух и более компьютеров или с двух и более точек отдачи) с одного и того же IP-адреса отданное не учитывается.
Естественно, и скачанное не учитывается, если загрузка одного и того же файла идет одновременно со всех клиентов.
Аккаунт, несмотря на отсутствие учета трафика файлообмена, присутствует в статистике раздачи файла и сам файл в профиле аккаунта тоже присутствует, но параметры файлообмена аккаунта на этом файле с течением времени не изменяются.
В прошлом году в своих клиентах заметил сидбоксы от www.feralhosting.com в количестве 2 единицы. Сидировал с них аккаунт janka30 ( https://kinozal.guru/userdetails.php?id=51681 ). В этом году количество их резко увеличилось и на раздачах, пользующихся с большим спросом, я стал их видеть сразу до 6 единиц. Некоторые, аккаунты, например, crazymixx ( https://kinozal.guru/userdetails.php?id=4789849) имеют и до 4 единиц (возможно, будет и больше).
Когда был только с www.feralhosting.com janka30, то проблем с учетом трафика файлообмена сидбокса не было. Видимо, он просто одну и ту же раздачу не сидировал, а если сидировал, то сидбоксы были на разных IP (на разных серверах).
Когда их стало много (минимум 6 видел на одной раздаче), то столкнулись с отсутствием учета трафика файлообмена из-за того, что трекер при раздаче одного и того же файла с двух и более клиентов (с двух и более компьютеров или с двух и более точек отдачи) с одного и того же IP-адреса отданное не учитывает.
Если проанализировать серверы www.feralhosting.com, то вполне может оказаться до 32 арендующих сидбокс на одном IP. Конечно, если они будут раздавать разные файлы, то проблем нет. Но, аккаунты ANDREY1408, crazymixx, Stariy70 хорошо умеют подбирать файлы для отдачи и большая вероятность того, что они одни и те же раздачи будут раздавать с одного и того же IP и, естественно, у них отдача на этом файле не будет учитываться.
Фактически они уже столкнулись с этой проблемой (из ЛС):

Cкрытый текст -

 

У janka30 ( на раздаче https://kinozal.guru/comment.php?id=1548960&page=4, на которой он об этом достижении сообщил раньше, чем разместил скриншот в профиле своего аккаунта. Его текст сообщения: "дров подкинули... https://hkar.ru/PGqZ ".
В своих клиентах теперь во время скачивания раздач вижу до шести www.feralhosting.com. Кому какие принадлежат, естественно, не знаю, но можно узнать. У crazymixx в профиле аккаунта бывает до 4-х www.feralhosting.com. На предмет выделенного IP-адреса www.feralhosting.com не проверял. В принципе, это сам можешь проверить, так как по IP и порту клиента можно проверить интернет любого провайдера на предмет выделенного IP-адреса. Ссылку сервиса по определению принадлежности IP-адреса к выделенному IP пришлю.
Если на одном внешнем (выделенном) IP несколько пользователей, то, чтобы был учет трафика файлообмена по всем раздачам, необходимо иметь на этом IP раздачи в одном экземпляре, т.е. если двое или более будут раздавать один и тот же файл, то файл в статистике раздачи файла и в профиле аккаунта будет, но учета трафика файлообмена не будет. Если на самом деле попадаете все четверо (ANDREY1408, crazymixx, janka30, Stariy70) на одни и те же IP, то в профилях ваших аккаунтов не должно быть одинаковых раздач.
Если www.feralhosting.com не хочет выделить всем внешний (выделенный) IP, то на форуме трекера попробую узнать о возможности перехода учета трафика файлообмена вне зависимости от количества точек отдачи с одного и того же IP. В принципе, если это есть на других трекерах, то и на этом трекере вполне могут сделать. А до этого Вы сообща все четверо можете сообщить техподдержке www.feralhosting.com, чтобы Вы все четверо не попадались на один и тот же IP.

Примечание:
В принципе, на таких огромных скоростях файлообмена с подключением к внешнему интернету на скорости до 10 Гбит/с или сдвоенных до 20 Гбит/с (видел сервис и до 30 Гбит/с) IP-адрес должен быть внешним (выделенным). По крайней мере в описаниях тарифных скоростей видел только внешний (выделенный) IP-адрес.
Возможно, Вы все попали в лапы "проходимца", т.е. посредника, который арендовал один 1 или 2 настоящих www.feralhosting.com и перепродает Вам всем. Я на рутрекере читал и такой ответ: "Нанял у барыги" в ответ на вопрос: "Что за хостинг?".
Возможно, причиной является сдвоенность сидбокса (до 20 Гбит/с = 10 Гбит/с + 10 Гбит/с). Вероятно они имеют один и тот же внешний (выделенный) IP. Тогда надо не иметь соседа, т.е. арендовать полностью 20 Гбит/с и раздавать раздачи, не дублируя их в обоих сидбоксах.

Оригинал: .

Если это не трудно сделать, то прошу убрать ограничение на количество точек раздачи одной и той же раздачи с одного IP-адреса, т.е. чтобы можно было раздавать одну и ту же раздачу с одного IP с двух и более клиентов.

Аккаунты с сидбоксами могут сделать уточнения, если найдут какие-то мои неточности в сообщении.

Примечание:
Соседи это арендующие сидбокс на одном диске сервера, а так же и на одном сервере.

Да,проблема с учётом статистики у использующих сидбоксы от feralhosting.com имеет место,это происходит и у меня,и у других пользователей данных сидбоксов.Возможно дело в том,что feralhosting.com не предоставляет выделенные ip,обращались в их техподдержку с просьбой о покупке,но получили отказ.Все пользователи о которых идёт речь у anya1956ss,используют боксы настоящего feralhosting.com,не посредника.При использовании этих сидбоксов на других трекерах,проблем не возникало ни разу.Предосталяемые пользователям слоты на feralhosting.com выдаются автоматически,выбрать мы их не можем,техподдержка вручную не может выдать нужный слот,поэтому некоторые наши сидбоксы оказываются на одном ip.Надеюсь,что можно,что-то предпринять и исправить ситуацию.

crazymixx сказал(a):

Cкрытый текст -   Да, проблема с учётом статистики у использующих сидбоксы от feralhosting.com имеет место. Это происходит и у меня, и у других пользователей данных сидбоксов. Возможно, дело в том, что feralhosting.com не предоставляет выделенные ip. Обращались в их техподдержку с просьбой о покупке, но получили отказ. Все пользователи, о которых идёт речь у anya1956ss, используют боксы настоящего feralhosting.com, а не посредника. При использовании этих сидбоксов на других трекерах проблем не возникало ни разу. Предоставляемые пользователям слоты на feralhosting.com выдаются автоматически и выбрать мы их не можем. Техподдержка вручную не может выдать нужный слот и поэтому некоторые наши сидбоксы оказываются на одном ip. Надеюсь, что можно что-то предпринять и исправить ситуацию.

Ну, в ЛС я про посредников отозвался только с одной стороны, т.е. как бы с отрицательной стороны.
Фактически я к посредникам отношусь только с положительной стороны из-за того, что они позволяют всем со слабым знанием тонкостей Интернета или отсутствующим возможность иметь высокоскоростной интернет попробовать или делать файлообмен на огромных скоростях.
В принципе, само понятие посредник тоже относительное, так как, например, крупный сервис по предоставлению высокоскоростного интернета seedbox.org.ua сам является как бы посредником и на его сайте указано: что и у кого что он арендует.
Сервис feralhosting тоже может оказаться таким же сервисом, что и seedbox.org.ua, т.е. посредником в предоставлении очень высокоскоростного интернета, арендуя трафик файлообмена у других провайдеров.
Если захотеть, то можно найти и данные по объёму их деятельности. Например, seedbox.org.ua сам на своём сайте показывает объём аренды трафика файлообмена у Укртелекома (если память мне не изменяет). Можно найти и объём аренды трафика файлообмена и у Ростелекома.
И вообще мне кажется, что все русскоязычные сервисы по сидбоксам организовал один и тот же человек. Если это действительно так, то его можно характеризовать только с положительной стороны. Не уверен, что они будут вечными, так как, когда у всех будет высокоскоростной интернет и отпадет необходимость прятаться пользователям интернета или сайтосодержателям от кого-то, то пропадет необходимость искать посредников. Тем более сидбоксы в основном необходимы только для исходящей скорости.
Бывает, что вообще отдельные лица (не профессионалы в этом деле) предлагают свои услуги. Один раз сам находил такого, который предлагал два сервера и один из них домашний. Не взял в аренду только из-за того, что ОЗУ было всего 2 Гб.
Попадался на этом трекере аккаунт, у которого в профиле аккаунта было написано: "Сидбокс 10 Гбит/с. Ваши предложения?".

Да, в принципе, и сам на некоторое время мог бы оказаться посредником:

Cкрытый текст -

 

Не менее З-х раз предлагал один из своих интернетов в качестве домашнего сидбокса бесплатно релизерам (не этого трекера), но во всех случаях релизеры отказывались. Два случая в качестве примера, которые мне хорошо запомнились:
1. Появился на трекере релизер-хулиган* форума со слабым интернетом.
В ходе общения на форуме я ему предложил один из своих интернетов в качестве домашнего сидбокса бесплатно с общим трафиком скачанного (не отданного) до 100 Тб (хватило бы ему на много лет вперёд), если он раздачи будет делать по моим интересам, т.е. файлы достались бы мне в качестве коллекционного материала. В принципе, это даже получается не совсем бесплатно, т.е. я не тратил бы времени на поиск файлов для коллекции из того, что он размещал бы на трекере. А за всё остальное расходы нес бы я. Но он отказался, так как ему это не требовалось, а требовалось другое**.
* - не только хулиган, но очень большой хулиган. Все его ненавидели и все жаждали, чтобы быстрее забанили его, кроме меня. Я с ним даже общался в ЛС огромное количество раз, несмотря на то, что он очень часто пытался пакостить моим аккаунтам. В принципе, я его до сих пор уважаю. Конечно, уважаю не за его хулиганство, а за его огромную трудоспособность. В интернете не встречал других, способных соперничать с ним в огромной трудоспособности. Сначала его не банили, несмотря на его хулиганства, т.е. как бы берегли для использования в качестве пушечного мяса. Когда поняли, что от него пользы нет в интригах, стали банить ежедневно его аккаунты. А за день он успевал делать до 9 раздач с каждых новых 3 аккаунтов. Примерно с год терроризировал форум трекера и скорее всего успел создать за этот период под тысячу релизерских аккаунтов.
** - лучше у него спросить, так как он, несмотря на ежедневные баны его релизерских аккаунтов, демонстративно не прятал свой клиент, несмотря на то, что я его научил способам сокрытия клиента от чужих глаз. Да и аккаунты выбирал так, чтобы быстрее его обнаружили.

2. Одному релизеру помогал восстанавливать аккаунт, забаненный по ошибке, т.е. аккаунт получил автобан. В ходе переписки я ему обещал на пару месяцев выделить один из своих интернетов с тарифной скоростью 200 Мбит/с бесплатно. Он после этого сразу исчез из поля зрения. Случайно обнаружил, что он делает релизы с нового аккаунта.
Через пару недель получаю от него сообщение, что его исчезновение объясняется тем, что он попал в больницу. Естественно, я не стал отвечать ему из-за того, что подумал: "Врунам нет смысла отвечать.".
Не отрицаю и того, что, возможно, я был неправ.

anya1956ss сказал(a):

От своей цитаты: "Такие случаи, когда не все одинаково видят бывают. Некоторые из них из своей практики файлообмена приведу позднее. Не все они относятся к этой конкретной проблеме, но просто они доказывают, что "чудеса" бывают. Конечно, они чудесами останутся до тех пор пока не будут найдены конкретные причины "чуда"." не отказываюсь и приведу их позднее.

Пример №1.
В своём клиенте увидел, что клиент одного очень известного релизера (создавал раздачи по моим интересам (все), все их я скачивал и, естественно, я очень хорошо знал его провайдера, IP и его клиент) отдает части файлов моего клиенту на огромной скорости (до 38 Мбайт/с при официальной максимальной тарифной скорости интернета его провайдера всего 100 Мбит/с). Раздача была свежей, кроме него раздавали и другие Сиды, т.е. он не успел ещё покинуть раздачу. В принципе, он и не был быстро покидающим свою раздачу при появлении Сидов.
Тарифная скорость моего интернета была тоже всего 100 Мбит/с. Сервер провайдера на 1 Гбит/с, но в компьютере эти 1 Гбит/с не отображались, а отображались 100 Мбит/с, т.е. в квартиру входила скорость до 100 Мбит/с. Вроде бы надо считать, что такое отображение скорости его отдачи является просто глюком. Однако, когда заглянул выше, то увидел, что мой клиент загружает файл с огромной скоростью (до 60 Мбайт/сек в пике) и процесс отображения данных в клиенте с виду правдоподобный*. Когда загрузка файла закончилась, то стал изучать график работы клиента и увидел, что сетка графика имеет верхнюю границу за 55000 Кбайт/с и на графике много пиковых скоростей за 55000 Кбайт/с. Примерно прикинул среднюю скорость загрузки файла по графику, сравнил со средней скоростью загрузки файла по данным клиента и не увидел чуда, т.е. пиковых скоростей на графике за 55000 Кбайт/с много, но средняя скорость загрузки файла не превышает 100 Мбит/с.
Загрузил файл ещё раз с другого клиента, чтобы посмотреть на чудо процесса загрузки файла. Повторная загрузка файла не изменила картину загрузки файла, т.е. прошла по предыдущему сценарию, но на этот раз я очень пристально присматривался к изменению данных в клиенте во время процесса загрузки файла и заметил, что данные как бы изменяются по времени чуть медленнее, чем обычно. На следующий день ещё два раза загружал этот же файл, но "чудный" сценарий не повторился, т.е. загрузился файл по обычному сценарию в обоих случаях.
Естественно, на этой раздаче остальные качающие не видели в своих клиентах этого "чуда".

* - про не правдоподобное отображение мне прекрасно известно, знаю точно и о причине такого отображения, видел и на трекере rutracker два скриншота разных аккаунтов, на которых скорость загрузки была более 1 Гбайта/сек в обычном клиенте обычного интернета.
В принципе об этом, видимо, знает и некоторое малое количество файлообменщиков. Так как видел короткий ответ: "Это "выстрел" из кеша". Хоть он и не давал своё разъяснение на сам механизм возникновения "выстрела", но я предположил, что он это уже видел и ответ близок к истине, но в утрированной форме. Правда, он возможно и не задумывался о механизме возникновения "выстрела".
На трекере rutracker есть опубликованный скриншот этого явления, но в меньших масштабах разброса скорости загрузки файла, чем в моём клиенте. Автор скриншота и увидевшие его скриншот не знают, что график работы клиента является как бы фальшивым.

Чтобы не утомлять читающих, остальные примеры будут позднее или при удобном для них случае.
Один удобных случаев будет при дальнейшем ответе на "диверсию" файлов в компьютере KniazidisR.

anya1956ss сказал(a):

Система учета трафика файлообмена этого трекера отличается от систем учета трафика файлообмена других трекеров тем, что при раздаче одного и того же файла с двух и более клиентов (с двух и более компьютеров или с двух и более точек отдачи) с одного и того же IP-адреса отданное не учитывается.

Добрый вечер.
Два разных пользователя, сидирующие одну и ту же раздачу с одного и того же IP-адреса, не влияют друг на друга.
А вот два одинаковых пользователя, сидирующие одну и ту же раздачу с одного и того же IP-адреса, влияют друг на друга, даже если они используют разные компьютеры и разные торрент-клиенты.
Проблема может быть в другом.
Раньше, если в интервал между анонс-запросами (1 час) пользователь успевал залить по раздаче более 100 000 000 000 байт (93 ГБ), то залитое по раздаче за этот интервал отбрасывалось и не шло в статистику. В прошлом году эту проверку, вроде как, убирали, но я точно не уверен. Попробую уточнить этот момент.

ФАНАТ сказал(a):

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

Ну, это исполнение сделано только на этом трекере.
Фактически нет никакой разницы между пользователями (аккаунтами) А и Б, так как А и Б могут принадлежать одному и тому же лицу, т.е.
объем отдачи с А + Б = объёму отдачи с А + А или Б + Б.
Оба аккаунта принадлежат одному и тому же лицу, но им (лицам с сидбоксами) нет смысла отдачу делать на оба аккаунта.
Искажения отдачи нет, так как в любом случае объём отдачи будет А + А = А + Б или если на другой аккаунт, то Б + Б = А + Б

ФАНАТ сказал(a):

Проблема может быть в другом. Раньше, если в интервал между анонс-запросами (1 час) пользователь успевал залить по раздаче более 100 000 000 000 байт (93 ГБ), то залитое по раздаче за этот интервал отбрасывалось и не шло в статистику. В прошлом году эту проверку, вроде как, убирали, но я точно не уверен. Попробую уточнить этот момент.

Эта проблема точно устранена и я много раз видел в статистике раздачи файлов, что она устранена.
Сами пользователи трекера с сидбоксами могут подтвердить это, если они заглядывают в статистику раздачи файла, чтобы посмотреть отдачу за анонс (1 час). Этот предел остался только на двух трекерах, я имею в виду из популярных трекеров, но не на этом трекере.
Да, и сама проблема касалась не к данной проблеме, а к "Ошибка: Access denied, banned client", т.е. при отдаче клиентом за анонс (1 час) более 100 000 000 000 байт (93 ГБ) на любом одном файле клиент банился (конечно, не аккаунт) по следующей схеме:
а) после первого анонса вся отдача учитывалась полностью, видимо, из-за того, что система учета не имела ещё основание банить аккаунт, т.е. в клиенте ещё не было "Ошибка: Access denied, banned client" и вся отдача за анонс учитывалась;
в) отдача за второй анонс не учитывалась, видимо, из-за того, что у системы учета трафика файлообмена по данным первого анонса уже было основание банить клиент;
г) отдача за третий анонс учитывалась, если отдача не превышала 100 000 000 000 байт (93 ГБ), а если превышала, то не учитывалась, т.е. не было отсекания лишней отдачи, чтобы учесть отданное в пределах до 100 000 000 000 байт (93 ГБ), а был бан клиента и отданное полностью не учитывалось, если оно было больше 100 000 000 000 байт (93 ГБ). В статусе трекера в это время была "Ошибка: Access denied, banned client" и это ошибка исчезала в клиенте автоматически, если после отсчета текущего анонса до 0 отдача не превышала 100 000 000 000 байт (93 ГБ).

Примечание:
Эта проблема характерна всем пользователям интернета и не только сидирующим с сидбоксов. Я просто не хотел акцентировать внимание на остальных.
Например, в 2014 году с этой проблемой столкнулся российский студент, который учился в Турции. Он, не зная об этой особенности трекера, файл на отдачу запустил сразу с двух клиентов с одного корпоративного интернета университета Турции. В результате клиенты раздавали, в статистике раздачи файла аккаунт его был, но параметры файлообмена его аккаунта в статистике раздачи файла не изменялись и ему пришлось остановить один из этих двух клиентов.

anya1956ss сказал(a):

Фактически нет никакой разницы между пользователями (аккаунтами) А и Б, так как А и Б могут принадлежать одному и тому же лицу

Указывая "пользователей", я имел в виду, естественно, аккаунты на трекере, а не лица. У разных пользователей отличаются id и пасскей, и друг на друга они не влияют.

ФАНАТ сказал(a):

Указывая "пользователей", я имел в виду, естественно, аккаунты на трекере, а не лица. У разных пользователей отличаются id и пасскей, и друг на друга они не влияют.

В принципе, обсуждаемая проблема может оказаться довольно распространенным случаем и для сидирующих с домашних интернетов и, возможно, они уже сталкивались с отсутствием учета трафика файлообмена, сидируя с одного клиента одного компьютера и с одного интернета, но без внешнего IP-адреса. Просто мы не знаем о мастшабах отсутствия учета по обсуждаемой проблеме.
Пользователей интернета без внешнего IP-адреса огромное количество. В своё время (когда у меня самый быстрый интернет имел скорость файлообмена всего 30 Мбит/с и не было внешнего IP) я интересовался количеством абонентов провайдера на одном сервере с внешним IP-адресом. Такую информацию раньше можно было посмотреть и в speedtest.net (была опция по просмотру этих данных).
Расклад был следующим:
а) загруженность сервера тарифными скоростями на 750 Мбит/с (75 %);
б) тарифные скорости от 1 Мбит/с до 30 Мбит/с;
в) количество абонентов ровно 100.

Конечно, в текущее время у моего провайдера ситуация другая, т.е. он не может иметь на одном сервере более 10 абонентов с внутренним IP, так как несколько лет назад перешел на единую тарифную скорость 100 Мбит/с гарантированную для всех абонентов. Правда, в этом году слегка расширил линейку тарифных скоростей.

Рассмотрим первый вариант сервера со 100 абонентами с внутренними IP. При таком количестве абонентов вероятность того, что с одного внешнего IP будут раздавать одну и ту же раздачу достаточно большая, так как среди 100 абонентов могут оказаться желающие раздавать раздачу с двух клиентов и более. В нынешнее время уже много пользователей интернета имеют 2,3,4,5 и более интернета. Если они от одного провайдера, то они легко могут оказаться на одном сервере с внешним IP. Но в этом случае от массовых жалоб на отсутствие отдачи на конкретных файлах спасает:
а) отсутствие знания закономерностей файлообмена пользователями интернета;
б) отсутствие тщательного контроля пользователями интернета за своим файлообменом;
г) отсутствие грамотности при подборе файлов для отдачи.
Но указанные в моих сообщениях аккаунты, сидирующие раздачи с сидбоксов, лишены этих недостатков и вероятность того, что они окажутся на одном IP-адресе с одной и той же раздачей в нескольких экземплярах (видел до 4 в профиле аккаунта crazymixx) огромная и, естественно, они сразу заметили потерю отдачи на некоторых раздачах, т.е. на раздачах, на которых их аккаунты есть в не одном экземпляре. А это у них происходит ежедневно, так как они не упускают ни одну раздачу, которая пользуется большим спросом у качающих, т.е. в любой день можно видеть их аккаунты на раздачах вместе и каждый из них может раздавать с двух и более сидбоксов с одним внешним IP, только из-за того, что для них недостаточно соответствующих файлов.
Разные раздачи они не могут, так как:
а) у них SSD имеют очень ограниченный объём для файлов;
б) нет на трекере достаточного количества раздач, чтобы полностью загрузить каналы отдачи, присутствующих на трекере сидбоксов. В этом вопросе им очень сильно мешают обновления или замены раздач, т.е. раздача раздавалась на огромной скорости много месяцев подряд, а обновленная раздача по отдаче сдохла в первый же день, но успела удалить очень хорошо раздаваемую раздачу с трекера.

Может я изложил не в той форме, как следует.
Если очень коротко, то каждый из сидбоксеров мешает только сам себе, раздавая один и тот же файл с нескольких сидбоксов с одного IP, т.е. они сами друг другу мешать не могут.

anya1956ss сказал(a):

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

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

Назовем процесс сидирования одной раздачи одним пользователем (аккаунтом) с одного клиента - сессией.
Сессии на трекере уникальны по связке <id раздачи, id пользователя, IP-адрес>.
Т.е.:
- один пользователь с одного адреса может сидировать несколько раздач, и все будет нормально учитываться
- один пользователь может сидировать одну раздачу с разных ip-адресов, и все будет нормально учитываться
- разные пользователи могут сидировать одну раздачу с одного ip-адреса, и все будет нормально учитываться.
Но если один пользователь сидирует одну раздачу с одного ip-адреса в двух и более клиентах, то все сессии пользователя (по одной на каждый клиент) будут отображаться в одну сессию на трекере. Поэтому рейтинг будет учитываться, наверное, по клиенту, отправившему свою статистику последним. Но не по сумме отданного всеми клиентами.

ФАНАТ сказал(a):

Cкрытый текст -   Теперь я точно понял суть жалобы. Собственно, выше я написал, что именно так и происходит учет рейтинга. Назовем процесс сидирования одной раздачи одним пользователем (аккаунтом) с одного клиента - сессией. Сессии на трекере уникальны по связке <id раздачи, id пользователя, IP-адрес>. Т.е.: - один пользователь с одного адреса может сидировать несколько раздач, и все будет нормально учитываться - один пользователь может сидировать одну раздачу с разных ip-адресов, и все будет нормально учитываться - разные пользователи могут сидировать одну раздачу с одного ip-адреса, и все будет нормально учитываться. Но если один пользователь сидирует одну раздачу с одного ip-адреса в двух и более клиентах, то все сессии пользователя (по одной на каждый клиент) будут отображаться в одну сессию на трекере. Поэтому рейтинг будет учитываться, наверное, по клиенту, отправившему свою статистику последним. Но не по сумме отданного всеми клиентами.

Всё верно, но концовка ответа не всем ясна, так как я в ЛС получил: "Администратор ФАНАТ считает, что у ферала всё учитывается?".
Поэтому необходимо дальнейшее обсуждение, в том числе и по отображению аккаунта в статистике раздачи файла и по отображению файлов в профиле аккаунта.
Коротко по отображению данных в профиле аккаунта, на примере своего аккаунта:

Cкрытый текст -

 

У меня одна и та же раздача может раздаваться с 12 интернетов от трех провайдеров, т.е., если по одному клиенту, то будет 12 точек раздачи одной и той же раздачи одним аккаунтом. Естественно, и учет трафика файлообмена клиента будет полным. В профиле аккаунта будет раздача в одной строке, а в статистике раздачи аккаунт в одной строке. В статистике раздачи файла и в профиле аккаунта на этой раздаче в течение 1 часа изменения произойдут в 12 раз.
Конечно, такое отображение не соответствует реальной картине раздачи файла аккаунтом с 12 точек раздачи частей файла. Реальное отображение должно быть таким, что в профиле аккаунта раздаваемый файл должен быть в 12 строках и в статистике раздачи файла аккаунт должен быть в 12 строках. Тогда раздающий раздачу сразу видит статистику трафика файлообмена каждого клиента. На многих трекерах так и сделано. На ещё других трекерах реальная картина отображения статистики раздачи аккаунта только в статистике раздачи файла, т.е. количество строк одного и того же аккаунта соответствует количеству точек раздачи, а в профиле аккаунта раздача отображается только в одной строке.

Если я буду раздавать одну и ту же раздачу с двух клиентов каждого из 12 интернетов (2*12=24 точки раздачи одной и той же раздачи), то отображение раздачи в профиле клиента и отображение аккаунта в статистике раздачи файла не изменится, но несмотря на то, что хозяин аккаунта (в данном примере хозяином являюсь я) видит, что у него как бы всё нормально, учета отданного не будет и хозяин аккаунта это может обнаружить только по изменяемым данным статистики раздачи файла или по данным профиля аккаунта, так как в профиле аккаунта изменение отданного на раздаче тоже отображается.

Если я буду раздавать одну и ту же раздачу с двух клиентов в 11 интернетах (из 12 моих интернетов), а с последнего интернета только с одного клиента, то трафик файлообмена клиентов будет учитываться только с одного интернета, т.е. с интернета, в котором раздается раздача с одного клиента.

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

Но на практике бывают всякие случаи вариаций этого одного IP и для простого пользователя интернета. Например, допустим я раздаю одну и ту же раздачу со всех 4-х интернетов от провайдера МТС. В каждом интернете раздача раздается только с одного клиента. Зная, что они все с внешними IP (согласно условиям предоставления услуг провайдера для моей тарифной скорости они должны иметь внешний IP), я не опасаюсь за правильный учет трафика файлообмена. Вдруг обнаруживаю, что суммарное количество отданного на раздаче в 4 раза меньше суммарного количества трафика файлообмена клиентов. В ходе выяснения причины узнаю, что IP одного интернета закреплен за одним сервером (1 Гбит/с) и IP является внешним, а остальные 3 интернета закреплены за вторым сервером (1 Гбит/с) и не имеют внешнего IP, т.е. имеют только "серые" IP. В результате этого на одной раздаче с одного внешнего IP оказалось три клиента с одной и той же раздачей. Естественно, с этих трех клиентов учета трафика файлообмена клиентов не было. В моём случае вопрос быстро разрешился прикреплением IP к разным серверам с внешними IP, но они не стали** интернетами с внешним IP, т.е. имели внутренний IP, но на разных серверах и исключалась возможность раздачи одного и того же файла с более одного IP-адреса.
** - для того, чтобы они имели внешний IP требовался мой приезд в офис провайдера с паспортом и требовалось моё заявление на иметь внешний IP. Паспортные данные мои у провайдера есть (при подписании договора их в договор вносят монтажники, подключающие интернет), но дальше договор, видимо, идет в архив без внесения паспортных данных (серии и номера) в компьютер. Грубо говоря, обыкновенная хитрость провайдера в конкурентной борьбе между провайдерами за пользователей интернета в качестве своего абонента, т.е. пользователь интернета думает, что у него внешний IP есть, так как исправно ежемесячно вносит оплату за интернет и не догадывается даже, что у него внешнего IP нет. В принципе, такая тактика провайдера правильная, так как подавляющему большинству абонентов провайдера по их интересам внешний IP и не требуется.
До сих пор эти три интернета у меня с "серыми" IP. Терплю только из-за того, что для моей отдачи пока хватает качающих и при "сером" IP интернетов.

Этот случай как раз подходит для описания проблемы с учетом трафика клиентов аккаунта при раздаче одного и того же файла с двух сидбоксов и более, т.е. когда на одной и той же раздаче у аккаунта оба или более сидбокса оказывается на одном сервере. Если из четырех сидбоксов 1 на одном сервере, а остальные 3 сидбокса на одном другом сервере, то учета трафика файлообмена не будет с трех сидбоксов, так как они на одном IP.

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

Добрый день! Подскажите каким образом можно сделать сортировку в топе по оценке раздачи? Было бы так удобно, но к сожалению, не могу найти как это сделать. Есть сортировка по сидам/комментариям и т.д., а сортировку по оценке не вижу.

uralec888 сказал(a):

Добрый день! Подскажите каким образом можно сделать сортировку в топе по оценке раздачи? Было бы так удобно, но к сожалению, не могу найти как это сделать. Есть сортировка по сидам/комментариям и т.д., а сортировку по оценке не вижу.

Добрый вечер. Увы, такой возможности нет.

KniazidisR сказал(a):

Вопрос только в том, кем подделаны раздачи, но это уже менее интересно, факт что так или иначе нет защиты от подделок.

KniazidisR сказал(a):

Вот сейчас поставил на раздачу "Дело № 306" из бекапа. Файл проверку на хеш прошёл и начал сидироваться. Через некоторое время раздача покраснела и блокировалась с сообщением теперь уже "ERROR:WRITE-TO-DISK". Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию). Затем только уже подделанный файл раздавался бы без блокирования.

KniazidisR сказал(a):

Причём 100% уже пройденной проверки поменялось на 99%. Что пытается записать клиент в файл-оригинал, который защищён от записи мне уже понятно (коллизию).

KniazidisR сказал(a):

Примечаниие: Похоже, что насчёт опасности видоизменяемых файлов я преувеличил. По сути дела какой-то шутник меняет только 1 байт, что вирусом быть не может. Если это шутник, то шутка принята. Короче - к чёрту.

KniazidisR сказал(a):

Вот KniazidisR нехороший, непослушный и мы его раздачи блокируем 23 часа в сутки.

Нет никакого шутника, так как шутником над Вами оказалось ваше компьютерное хозяйство (диски компьютера + правильная деятельность ОС). Здесь тоже компьютерное хозяйство (диски компьютера + правильная деятельность ОС) пошутило над своим хозяином, но хозяин компьютерного хозяйства в данном случае сильно раздувать проблему не стал, т.е. шутника не искал.
Сама проблема давно известна и на эту проблему чаще всего попадаются раздающие, которые раздают раздачи в группе из небольшого количества раздающих. Если раздачу раздает один раздающий, то, естественно, он на эту проблему попадает сразу.

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

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

Рекомендация по этой проблеме:

Cкрытый текст -

 

Файл необходимо перенести на другое место диска или даже на другой диск.
Перехешировать файл и запустить на раздачу. Клиент скачает отсутствующие части и начнет раздачу.
Если Сидов на раздаче не будет, то аккаунт хозяина в статистике раздачи файла будет в Личерах до тех пор пока не появятся Сиды. После появления Сидов он скачает отсутствующие части файла и станет Сидом.

Примечание 1:

Cкрытый текст -

 

Естественно, в вашей проблеме и описанное в http://forum.kinozal.guru/showpost.p...postcount=1315 сыграло злую шутку, т.е. нельзя хранить в одной папке файлы одного типа с одинаковым наименованием.

Примечание 2:

Cкрытый текст -

 

Возвращайтесь в тему.
Если что-то обидело Вас в моих сообщениях, то считайте, что здесь я Вам приношу свои извинения публично.
Когда всё написанное осилите, то, возможно, у Вас появится желание вернуть мне мои извинения.

Примечание 3:

Cкрытый текст -

 

Файл "Каторга (1929.SATRip-AVC).mkv" скачал 7 раз и в последние 2 раз ничего лишнего не увидел.
Возможно скачаю ещё несколько раз. Сегодня пока не смогу, так как сегодня в доме свет отключили на 7 часов и клиент занят перехешированием файлов: .
На скриншоте видно, что файл скачан 7 раз.

anya1956ss сказал(a):

Если он раздает раздачу один, то, естественно, он один вынужден будет раздать всю раздачу и, естественно, столкнется с нечитаемыми частями раздачи и клиент прекратит раздачу, выдав сообщение: "Ошибка: ..."

На самом деле несколько раз сталкивался с тем, что мой клиент (и моя файловая система) не обнаруживал ошибку. Тревогу поднимали качающие, которые не могли докачать раздачу (останавливались на 99.хх%, дальше, как правило, шли временные отбраковки моего клиента по ошибкам хеша). У себя ошибку обнаруживал только тогда, когда перепроверял хеш раздачи.