Closed zero77 closed 2 years ago
Why would there be so much overhead that it isn't feasible to do this no matter how many torrents are being seeded?
it's unclear what kind of overhead you're asking about. You would announce to twice as many trackers, make twice as many DHT lookups, probably not twice the number of peers. Generating the torrents would also come at a cost, computing the sha256 trees specifically
I only mentioned overhead, as you would be seeding two torrents at once a v1and v2. I didn't know if someone with a large number of torrents would start to see a performance decrease as you would be doubling the torrents your seeding.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@stale Still Outstanding
I don't think this feature is in the scope of libtorrent. a client can do this. It would most likely need some human configuration
Perhaps, but I don't think v2 torrents will become widely used otherwise.
It's hard to see a widespread adoption of V2 unless something like automatic hybrid and V2 seeding is implemented by a core component like libtorrent. As specially as torrent site providers and some developers seem to be waiting for the other to adopt it first.
This is a solution in search of a problem.
Perhaps, but I don't think v2 torrents will become widely used otherwise.
It's hard to see a widespread adoption of V2 unless something like automatic hybrid and V2 seeding is implemented by a core component like libtorrent.
v2 will see significant adoption only when the major torrent sites adopt it. Watch it become the dominant version overnight once RARBG, TL, PTP, etc adopt it. This in turn depends on the uploaders to those sites adopting it.
The ball is in the court of those who create torrents to switch to v2. However, at this moment, not even Linux distro projects are creating v2 torrents, unfortunately.
I mean, that's why this feature would be great.
v2 will see significant adoption only when the major torrent sites adopt it. Watch it become the dominant version overnight once RARBG, TL, PTP, etc adopt it. This in turn depends on the uploaders to those sites adopting it.
The ball is in the court of those who create torrents to switch to v2. However, at this moment, not even Linux distro projects are creating v2 torrents, unfortunately.
transmission currently barfs on hybrid torrents, which has made some distros not want to author them
transmission currently barfs on hybrid torrents, which has made some distros not want to author them
Yeah, client support is an issue right now. qBittorrent should get full support this year still (if you compile from source with libtorrent 2.x, you can already use V2, although there are known crashes and bugs under some circumstances). Don't know about transmission, but it could happen this year as well, still. After that, I would expect more uploaders/torrent creators to have less reservations about publishing V2 torrents. Still, there are already some FOSS clients that support V2: https://github.com/picotorrent/picotorrent.
That transmission bug is 4 years old and they've never announced plans to prioritize it (granted the effort is surprisingly high; they've never allowed empty dict keys in bencoding). I think either they either don't know or don't care that their market share makes them an adoption blocker.
At risk of being way off topic for this bug, I think the real solution to adoption is for prominent FOSS client devs to badger transmission.
@FranciscoPombal
This is a solution in search of a problem.
The problem is the lack of adoption of V2 or hybrid torrents and it benefits.
v2 will see significant adoption only when the major torrent sites adopt it. Watch it become the dominant version overnight once RARBG, TL, PTP, etc adopt it. This in turn depends on the uploaders to those sites adopting it.
The ball is in the court of those who create torrents to switch to v2. However, at this moment, not even Linux distro projects are creating v2 torrents, unfortunately.
I understand your point of view but, there has become a stalemate. At the moment website operators are waiting for wider adoption of V2 by torrent clients. But, at the same time client developers are waiting on websites to adopt them.
I am not aware of another core component that could have such an impact as libtorrent. Because, even if one website adopted V2 or hybrid that doesn't mean others would with out more client support. Also, developers may feel that one website support is not enough.
But, at the same time client developers are waiting on websites to adopt them.
This is not my impression. Although, I think virtually all development in this space is volunteer/nights and weekends, so it's not moving terribly fast.
This is not my impression. Although, I think virtually all development in this space is volunteer/nights and weekends, so it's not moving terribly fast.
Yes, i am sure not every developer feels this way but, i have seen this opinion several times. Also, I am appreciative of the developers time as i know it's voluntary and is prioritized to make the most impact with the limited time they can spare.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This request idea was taken from: https://github.com/BiglySoftware/BiglyBT/issues/1872
As V2 torrents are relatively new and often have a limited number of seeds. When seeding a v1 torrent could a v2 torrent automatically be created and seeded alongside the v1 torrent, as a default.
But, to decrease overhead for instances where a large number of torrents are being seeded perhaps 10 or more, go back to seeding v1 only.