[Feature request] Support two torrents with the same info_hash from different trackers.

[vanchaxy]

I have a lot of torrents skipped because of the same hash. I use 3 trackers that often copy torrents from each other with changing announce URL. Can we add a URL to the torrent table and use hash+URL to filter duplicates?

[zakkarry]

I assume that the trackers you are referring to are public trackers.

This would open up an entire can of worms I don't even want to think about.

We wouldn't want to be modifying torrents in the client or otherwise, and this would require an entirely new method of injection, not to mention API calls to see if the tracker is already in the client and the inability to store multiple torrents with the same infohash in the cache.

I, personally, don't think this is something we would do.

[mmgoodnow]

This would amount to

• be able to add an announce url to an existing torrent, x4 for each client. (Check for private flag as well)
• be able to tell the torrents apart by announce url
• Write code to ignore them as duplicates

[mmgoodnow]

Somewhat surprisingly achievable actually. If a lot of people have this use case, it'd be worth thinking about.

[zakkarry]

Potentially this opens the problem of misreporting stats, although on the trackers this would be applicable on I'm not sure they care.

[AN1MATEK]

Duplicated hashes are also a problem in private trackers. I have had the issue between IPT and PHD. You cannot even cross-seed them by manually adding the torrents, qBittorrent rejects it as duplicate. I think this is a limitation of qBittorrent more than cross-seed.

[zakkarry]

It is not exclusive to qBittorrent, this is generally the way clients work, usually because the key/reference to the torrents is done with the infohash in some capacity.

There might be one that would support this natively, however I'm not familiar with this. The result is generally people think they should just "Add Tracker" to the existing, and stats will thus be misreported and risk your account being banned for "cheating" - despite not having that intent.

This is mainly the reason I don't particularly support this use case (as stated above)