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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

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


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

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

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

Проблема с учетом трафика файлообмена при раздаче раздач с сдбоксов с соседями
 

Система учета трафика файлообмена этого трекера отличается от систем учета трафика файлообмена других трекеров тем, что при раздаче одного и того же файла с двух и более клиентов (с двух и более компьютеров или с двух и более точек отдачи) с одного и того же 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крытый текст -

Оригинал: .

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

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

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

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

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

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

Добрый вечер.
Два разных пользователя, сидирующие одну и ту же раздачу с одного и того же IP-адреса, не влияют друг на друга.
А вот два одинаковых пользователя, сидирующие одну и ту же раздачу с одного и того же IP-адреса, влияют друг на друга, даже если они используют разные компьютеры и разные торрент-клиенты.
Проблема может быть в другом.
Раньше, если в интервал между анонс-запросами (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 году с этой проблемой столкнулся российский студент, который учился в Турции. Он, не зная об этой особенности трекера, файл на отдачу запустил сразу с двух клиентов с одного корпоративного интернета университета Турции. В результате клиенты раздавали, в статистике раздачи файла аккаунт его был, но параметры файлообмена его аккаунта в статистике раздачи файла не изменялись и ему пришлось остановить один из этих двух клиентов.

Указывая "пользователей", я имел в виду, естественно, аккаунты на трекере, а не лица. У разных пользователей отличаются 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, т.е. они сами друг другу мешать не могут.

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

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

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

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

Если я буду раздавать одну и ту же раздачу с двух клиентов каждого из 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.

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

Сортировка по оценке?
 

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

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

Продолжение по проблеме KniazidisR.
 

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

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

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

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

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

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

Cкрытый текст -
Примечание 2:

Cкрытый текст -
Примечание 3:

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

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

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

Я в описываемых мной случаях ничего никуда не переносил, как стоял на раздаче, так и продолжал стоять. Остался единственным сидом, раздавал нормально. А спустя некоторое, довольно продолжительное, время (в одном из случаев) получил ЛС от модератора, что люди не могут докачать раздачу. Перепроверил - упс!
В паре других случаев - случайно заметил в клиенте несколько пиров, застывших на 99.99%.
А при переносе файлов раздачи в другое место я предпочитаю перепроверять хеш. Тоже несколько раз напарывался на потери.

Этот случай полностью соответствует вашему случаю. Были два Сида (один постоянно) и от них мой клиент и ещё несколько клиентов не смогли получить все части файлов. Вернулся автор раздачи и все скачали раздачу, а эти два Сида остались со своим файлом, у которого они не все части раздачи смогут раздать.

Этот случай тоже аналогичный вашему варианту, скорее всего, тоже копия вашего случая. Неспроста же он переносил раздачи. Возможно, тоже кто-то жаловался, что раздача не скачивается до 100 %. Если хотите, то могу дать ссылку на его аккаунт и сами спросите о том, с какой целью он переносил их на другое место.
Судя по тексту на скриншоте, он тоже перехешировал.
Разницы нет в том, что хешировать или нет. Если раздача без хеширования даже запустится как "Раздается", то быстро перейдет на "Загружается". Скачаются отсутствующие части и раздача вернется в состояние "Раздается".

Сама? "Это вряд ли." (с) Во всяком случае, в uTorrent такого не наблюдал. Как "раздавалась", так и продолжала "раздаваться", пока не перехешируешь.

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

No comment.

P.S. Если не ошибаюсь, при установленной галочке "Не хешировать" uTorrent только проверяет наличие файлов (совпадение имён файлов и, кажется, их размеров и их расположение), если с этой точки зрения всё в порядке - торрент запускается именно на раздачу и уже никоим образом не перейдёт к скачиванию. В случае, если в процессе раздачи попадётся нечитаемая часть, торрент остановится с выдачей соответствующего сообщения об ошибке.

Не изучал клиенты на предмет того, что он проверяет при установленной галочке "Не хешировать", так как нет привычки изучать вопросы, которые не создают проблемы мне.
Я Вам уже писал: "Если Вы этого не наблюдали, то это вовсе не означает, что описанное не может быть.". Из старых опубликованных сообщений: .
На скриншоте указаны:
1. Стрелками зеленого цвета раздачи, перенесенные из клиента µTorrent 1.7.7.
2. Стрелками желтого цвета раздачи, перенесенные из клиента µTorrent 1.7.7, которые имели частичное скачивание во время переноса раздач с одного клиента в другой клиент.
3. Стрелкой фиолетового цвета дата снятия скриншота.

Раздачи переносились из µTorrent 1.7.7 в BitTorrent 7.2.1 для того, чтобы не мешать клиенту µTorrent 1.7.7 спокойно загружать файлы.

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

На странице раздачи написано «Скачивают 0. Нет подключений»:

µTorrent показывает отдачу:

В каких случаях такое возможно?

Это возможно, если раздача сетевая, т. е. раздаётся не только на KZ, но и на других трекерах и позаимствована она именно оттуда или наоборот (отданное должно учитываться).

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

Вы, как мне кажется, говорили об обратном явлении? А про то, что клиент может "раздавать" торрент и числиться сидом, в реальности не имея его на 100%, как раз говорил я.

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

вагонный, этот фильм я разместил и раздаю только на Кинозале.

1. Один из вариантов ответа, например, может быть из-за того, что все качающие по DHT, т.е. качают все пользователи интернета с других трекеров.

2. Если Вы, например, увидите, что в статистике раздачи файла нет никого из раздающих тогда, когда очень много Сидов в клиенте, то тоже не удивляйтесь, так как все раздающие с других трекеров по DHT.
3. Если Вы, например, увидите, что в статистике раздачи файла нет Сидов, кроме автора раздачи тогда, когда очень многие вышли в Сиды в клиенте, то тоже не удивляйтесь, так как они не обязаны мгновенно отображаться в Сидах и многие могут появиться среди раздающих только через определенное время и даже с большим опозданием (максимум 1 час), т.е. аккаунт в Сиды выходит только тогда, когда произойдет полное обновление интервала времени между двумя соседними анонсами клиента или после полного завершения очередного анонса клиента, т.е. в начале обратного отсчета нового интервала времени между анонсами.
4. Если Вы, например, увидите, что в статистике раздачи новой раздачи автор раздачи есть, когда его в клиенте нет с 100 % частей файлов, то тоже не удивляйтесь, так как автор раздачи спокойно может находиться среди качающих. При включении опции СуперСид автора раздачи в клиенте невозможно увидеть с 100 % объема файла.

Над другими вариантами ответа ещё не задумывался.

Смотрите пункт 2 и увидите, что эти два файла имеют коэффициент отдачи по формуле Отдача / Скачанное во время переноса файла в другой клиент вместо Отдача / Скачанное исходное, т.е.:
1) 3,8 Тб / 32 Мб, вместо 3,8 Тб / 340 Гб, если написать в правильной форме, то: 3,8*1024*1024 Мб / 32 Мб, вместо 3,8*1024* / 340 Гб
2) 667 Гб / 2 Мб, вместо 667 Гб / 1,36 Гб, если написать в правильной форме, то: 667*1024* Мб / 2 Мб, вместо 667 Гб / 1,36 Гб.
Если не было бы скачивания, то вместо 32 Мб было бы 0 и вместо 2 Мб тоже было бы 0 в столбце "Загружены".


Какая иллюстрация требуется? Я Вам в этом сообщении выше текстом дал пример определения присутствия цепочки переходов "Раздаётся" - "Загружается" - "Раздаётся". Если вам требуется видео-доказательство, то я его не делал, так как в то время не думал о том, что кому-нибудь в будущем потребуется такое доказательство. Я этот скриншот в своё время приводил только в своем ответе на сообщение: , которое выделено красной рамкой на скриншоте.


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


Я Вам этот пример привел только в качестве того, что в клиенте можно увидеть всякие "чудеса", которые в последствии из разряда "чудес" переходят в вполне объяснимое явление.


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

Продемонстрируйте свое утверждение, чтобы увидеть и определить к чему отнести ваше утверждение. Желательно в форме видео. Если это трудно, то можно обойтись и без видео, т.е. достаточно скриншотов.

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

Для чего Вам хеширование раздач, когда их можно запускать без хеширования?

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

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

Можно узнать на каком трекере находится такая раздача?

Я, разумеется, видел то, о чём Вы говорите. Против второй части цепочки ("Загружается" - "Раздаётся") возражений нет и быть не может. А вот первый переход ("Раздаётся" - "Загружается") и вызвал у меня сомнения. Его Вы никак не продемонстрировали.
Хотя вполне допускаю, что "для простоты" на время проведения необходимых проверок (имена файлов, их размеры, расположение) клиент может писать в статусе торрента "Раздаётся".

Например, здесь. А также здесь:

Попробую, когда будет такая возможность.

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

Разве что поискать в Гугле?

Спасибо, bag2006.

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

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