Cannot handle two torrents with the same infohash

[cheater]

qBittorrent & operating system versions

qBt 4.6.3 (and any other version currently)

OS: any

Qt: any

libtorrent: any

What is the problem?

Often private trackers will re-upload each others torrents with the same infohash. Or, sometimes a private tracker will have the same torrent as a public torrent. This is not going to change in the future and there is a huge amount of existing torrents that this will never change for. If you want to download both at once, or seed both at once, you can't, because peers cannot be shared, or you'd get banned on the tracker. Therefore, qBt needs to support multiple torrents with the same infohash.

To preclude this - there is no conversation to be had about what trackers should be doing - randomizing infohash, different counting method of upload, etc. None of this will ever happen.

This limitation is especially bad for torrents with low health because if you have multiple sources for a torrent you want to start all of them at once, so that maybe one of them will finish in a year or so.

Steps to reproduce

No response

Additional context

No response

Log(s) & preferences file(s)

No response

[cheater]

Yes, I know this is currently "by design" - the design needs to change for this. Yes, it'll be a bunch of work. Yes, it still is a problem and needs to change.

[stalkerok]

Cannot handle two torrents with the same infohash

It's one torrent.

qBt 4.6.7

There is no such version.

Often private trackers will re-upload each others torrents with the same infohash.

You can manually edit the tracker list and add any tracker to it (if the torrent is private), if not qBittorrent will automatically merge the tracker list.

Yes, I know this is currently "by design" - the design needs to change for this. Yes, it'll be a bunch of work. Yes, it still is a problem and needs to change.

No one's going to do it.

[cheater]

It's one torrent.

First sentence and you already show you haven't read the bug report and have put zero thought into actually understanding what's being discussed here.

No one's going to do it.

No one asked you. You made exactly one commit, ages ago, changing an integer in default settings from 500 to 200. Your opinion means nothing. Go troll somewhere else, and get lost.

[cheater]

This is not an invitation to reply to me. I don't want to have a conversation with you. Go annoy someone else.

[stalkerok]

I'm not a software developer, but that doesn't mean I'm stupid. In all likelihood, the developers will tell you the same thing. If you want, you can split these torrents into two clients.

[glassez]

Often private trackers will re-upload each others torrents with the same infohash.

If you have managed to meet (really) different torrents (i.e., different so as to be considered different according to BitTorrent protocol) having the same info hash at least once, then you are lucky. The probability of this event, even in BitTorrent with its SHA-1 hashes, is very low. I would be extremely interested to take a look at such torrents. Could you provide at least one such pair?

[cheater]

different so as to be considered different according to BitTorrent protocol

that's not it. a torrent file from a tracker isn't just a "torrent according to the BT protocol". it also has a set of trackers associated with it, and you can have the exact same contents, with the exact same infohash, but different set of trackers and rules associated with it. one of those torrent files will report upload quotas to one tracker. the other torrent file will report upload quotas to another tracker. if you get a peer, call him Bob, from torrent file 1, you should report to tracker 1. if you get another peer, Charlie, from torrent file 2, you should report to the tracker from that file. if you report uploading to Bob to tracker 2, you will get banned on tracker 2. that's why those need to be kept separate, even though just according to the bittorrent protocol they are "the same". but that sort of approach doesn't work because the bittorrent protocol doesn't take this situation into consideration and therefore has an incomplete model of what happens in the real world. this situation actually happens a lot, and not supporting it is bad. it's not some esoteric one in a billion happenstance like you described.

[cheater]

I'm not a software developer, but that doesn't mean I'm stupid.

your replies indicate the opposite. get lost already. i don't want to talk to you, you will gain nothing by trolling this bug report.

[cheater]

@glassez would you mind removing @stalkerok from this conversation? he's not adding anything, and just came to "no true scotsman" in here, which i have no interest in.

[cheater]

anyways, to get back to having two torrents that have the same infohash, being able to do this would mean that health of a lot of torrents could be upgraded. often torrents start out on public trackers and get mirrored on private trackers. but a year or two later, the public version of the torrent is often stuck incomplete, whereas the private version has full health. so, being able to download the private tracker, and reseed the public one, would increase torrent health of the public one, and let it continue working.

currently if they have the same infohash what you have to do is you have to download the private torrent, delete it, add the public one, and then move files from the private one to the public one's save location. instead, you could just make both have the same save location. this way you could continue seeding on both the private and public tracker, but currently you have to choose either or. if you don't choose one or the other and use trackers from both, then you will report public tracker upload quota to the private tracker, and get banned.

if the torrents have a different infohash then this scheme works, but sometimes they have the same one.

[glassez]

different so as to be considered different according to BitTorrent protocol

that's not it. a torrent file from a tracker isn't just a "torrent according to the BT protocol". it also has a set of trackers associated with it, and you can have the exact same contents, with the exact same infohash, but different set of trackers

If I'm not mistaken, this has already been discussed in another Issue. In any case, if this problem is solvable at all (which I strongly doubt), it belongs to the backend area (i.e. libtorrent).

[cheater]

it has, ages ago, and people came up with stupid comments and it didn't lead to anything and was closed without resolution.

libtorrent

for them to implement something there needs to be a need in client applications, so a good first step is to hash out how this could work here. Do you have a design in mind?

[userdocs]

I read the issue and I understand, this is a tracker problem. They created the issue by uploading a torrent to their site and removing other trackers from the torrent, then force an arbitrary limitation on the user to not share it as the protocol and clients intend it to be shared.

The fix is to add all trackers back to the unique torrent and then you realise this is not an issue at all, especially not a qbittorrent issue. It's a private tracker issue.

As you already stated this:

To preclude this - there is no conversation to be had about what trackers should be doing - randomizing infohash, different counting method of upload, etc. None of this will ever happen.

You want qbittorrent/libtorrent to work around an artificial problem, not in the protocol or client, but one created by private trackers.

If you did not already understand this before you opened an issue expecting qBittorent to fix a problem you know is not a real issue with the client and is an outcome of an arbitrary limitation enforced by the private tracker, I question your intelligence.

You are are certainly not a dev, that's for sure.

[cheater]

arbitrary limitation enforced by the private tracker

private trackers want to meter upload and will ban people who fake their upload quotas. that's not an "arbitrary limitation", that's how exactly all private trackers always worked, since the very beginning. what sort of bs are you trying to sell here?

this is a tracker problem

it's not a tracker problem. it's a problem of libtorrent and qBt being unable to handle a real-life situation that happens everywhere. You can plug your ears and scream "lalala" as much as you want, but the real life is still out there, outside your basement, and it's different than what this code imagines it to be.

You are are certainly not a dev, that's for sure.

I'm a programmer since 30+ years. you're weird. don't talk to me.

[glassez]

@cheater Here's how the protocol obliges clients to behave with private torrents:

each peer MUST use only one tracker at a time and only switch between trackers when the current tracker fails. When switching between trackers, the peer MUST disconnect from all current peers and connect only to those provided from the new tracker.

You (or someone else involved in this issue) could develop improved "Private torrents" proposals and send them to the appropriate people for consideration.

the real life is still out there, outside your basement, and it's different than what this code imagines it to be.

qBittorrent code doesn't implement backend. It just provides interface for libtorrent and adds some auxiliaries. And libtorrent (I suppose) just follows the BitTorrent specs on this matter.

[cheater]

each peer MUST use only one tracker at a time

sure! but no one said that an application (or libtorrent) must run only one copy of the protocol at the same time.

could develop improved "Private torrents" proposals

not necessary, given the above

qBittorrent code doesn't implement backend

of course. but given the above, there are a few options here to think about what qBt could be doing. for example, qBt could instantiate libtorrent multiple times in such a situation. Or, it could ask libtorrent for a new data structure which results in libtorrent running the protocol multiple times.

Ultimately the spec you posted has many different interpretations, and we can hash out in here what would be the best way to go forward for a client like qBt.

[cheater]

Specifically, it's not like the specification you mention, or any one precluding it, actually requires that only one torrent is present in a client per info hash. While code handling LSD and PEX and DHT might need to get refactored a tiny bit, it's not even a huge architectural change. BEP 3 is written as if there is only ever one torrent at all, which gives free interpretation as to whether there can be multiple torrents with the same info_hash or not. Think about it this way: if you read BEP 15, and it mentions "transaction", you can have multiple transactions that have the same info_hash but different tracker lists and peer lists.

[cheater]

The part you mention is actually part of a paragraph that goes like this:

When multiple trackers appear in the announce-list in the metainfo file of a private torrent (see multitracker extension in [4]), each peer MUST use only one tracker at a time and only switch between trackers when the current tracker fails. When switching between trackers, the peer MUST disconnect from all current peers and connect only to those provided from the new tracker.

this doesn't say that you can only have one torrent per info_hash. all it says is that if you have a torrent, it should use the load balancing protocol described in bep12: go through the list of lists front to back, pick up a list, shuffle it, then try announce urls in order, and if you find one that works, put it in the front of that nested list.

mentioning it is almost fully redundant, because bep12 already tells clients to handle announce-list field in the same way. however, the peer purge is a new part, that doesn't exist in bep12. this is done exactly so that the client doesn't report uploads to peers from tracker1 to tracker2, which is what i've been mentioning above. but if the client is smart enough to tell those apart (simply by keeping track of them), there's no reason not to have two separate swarms running that have the same info_hash.

[cheater]

ultimately on the same computer i can run qBt with one torrent, and another client with another torrent, and those torrents have the same info_hash but different tracker and peer lists, so there's no reason for qBt to not be able to do this all at once. it's not like eg. qBt + transmission somehow break the protocol. conversely trackers and peers have no insight into what's going on inside my computer, they just see packets coming out of ports and don't care if i have qBt (with torrent 1), qBt (with torrent 1) + transmission (with torrent 2), or qBt with torrent 1 and torrent 2.

[cheater]

also, @maoruishan can you kindly go slither back under your rock? you don't need to put a thumbs down on every message i send. if you want to be obsessed with someone, go watch some egirls on twitch. you neither contribute to this conversation nor to the project, or any project at all. scram.

[community-notes]

This is an off topic community note to provide context to the reader.

[!NOTE]
The user @cheater is blocking anyone who disagrees with them which means they can no longer comment on this issue while it is owned by the them.

This is an usually aggressive and manipulative tactic which undermines any potentially constructive outcome to pursue a specific agenda. It's also not transparent to the community involved that users are not longer able to participate due to how GitHub chose to implement the blocking feature.

This can be perceived by the reader as the user's having accepted that their position has been successfully countered and they that rescind their argument when in reality, they cannot reply in that issue after being blocked by the OP.

[!WARNING]
A reminder, if you chose to comment here in any way that undermines the OP's position you will probably be blocked.

Potentially helpful context:

Narcissistic behaviour

[cheater]

so much effort and reading of markdown syntax just to get blocked by a rando, impressive.

[Chocobo1]

To preclude this - there is no conversation to be had about what trackers should be doing - randomizing infohash, different counting method of upload, etc. None of this will ever happen.

AFAIK, some trackers (should) support utilizing a different infohash: What is the "source" field used for?

ultimately on the same computer i can run qBt with one torrent, and another client with another torrent

FYI, you can actually run many qbt instances on the same computer: either for each qbtorrent.exe paired with its own profile folder. Or use the --profile commandline argument to point to different profile folder for each qbt instance.

Maybe not what you really wanted but those are some valid workarounds.

[cheater]

some trackers (should) support utilizing a different infohash

hmm, i don't really understand what you're saying. the source field has nothing to do with the infohash. we're talking about the situation when there are two torrents with the same info_hash but different peers and announce urls. that doesn't change even if you change the source field.

some valid workarounds

yes, indeed, good workarounds in a pinch. but that also goes further to show that this isn't something that can't or shouldn't be supported.

[DrunkenSeafarer]

some trackers (should) support utilizing a different infohash

hmm, i don't really understand what you're saying. the source field has nothing to do with the infohash. we're talking about the situation when there are two torrents with the same info_hash but different peers and announce urls. that doesn't change even if you change the source field.

The source field is part of the info dictionary, hence it affects the infohash. Modern private trackers customize the source field when you upload to them, to ensure unique infohashes and help cross-seeding (by precluding the problem you are trying to solve here).

For example, when you upload to PTP, they set the source field to "PTP", and you have to redownload the .torrent file before you can start seeding. The same goes for e.g. HDB, which sets the source field to "HDBits". Because they use different values for "source", you can seed the "same" torrent for both trackers (same files, same piece size) in the same client simultaneously.

When you upload files yourself, the old solution used to be to set different piece sizes for different trackers, but luckily these days most trackers simply set the source field for you.

When you download sufficiently old torrents, even from the mentioned sites, they will not have the source field set, and you cannot easily cross-seed due to infohash collisions. The solution widely known in the community is to run multiple clients, as mentioned above. You will need to run multiple clients anyway, to split the number of torrents you seed, when you get into the tens of thousands.

[glassez]

The solution widely known in the community is to run multiple clients

It is even possible to run multiple instances of qBittorrent using different profiles.

[xavier2k6]

Could you provide at least one such pair?

@cheater - Still waiting for you to provide this info

[AN1MATEK]

I've had this issue too. I cannot provide the torrent files because they are private trackers. However you may want to see this thread in Discord: https://discord.com/channels/492590071455940612/1205408251852619826

My log entry read

(N) 2024-02-09T08:47:11 - Detected an attempt to add a duplicate torrent. Merging of trackers is disabled. Torrent: The.West.Wing.S01-07.1080p.WEB-DL.AAC2.0.H.264-NTb

This torrent is both in PHD und IPT, where the hashes match.

[thalieht]

@cheater fix the title. This is about cross seeding/leeching. The current title has only one answer: https://github.com/qbittorrent/qBittorrent/issues/20323#issuecomment-1907675187

Cannot handle two torrents with the same infohash

It's one torrent.