Ratio quirk with mostly pre-downloaded torrents

[haasn]

If you add a torrent that you've mostly downloaded via other sources, the ratio's divisor approaches 0. For the actual 0 case, it seems transmission has a work-around and just assumes it's 1 instead, but for values approaching 0 it explodes into infinity.

For example, I have a torrent currently added where transmission thinks it's sitting on a ratio of several thousand, because I only have a few kB downloaded. It happened like this:

1. Add magnet link of a pre-existing torrent that I was migrating from another client
2. Since transmission doesn't let you add magnet links paused, I only realized once it started downloading that it was at 0% (instead of 100%), so I paused it after a few kB.
3. Notice I had accidentally misplaced the completed files
4. Move them into the right location, force a re-scan on transmission
5. Transmission starts seeding.

Now transmission uses this very small small as its reference for the “ratio”, which looks silly on the list. And while I don't, I imagine this would easily screw with a “seed until ratio X” setting in an unexpected way. Not a big deal overall, and I can easily work-around it by just removing the torrent and re-adding the same magnet link, but it does make me wonder whether the logic couldn't be improved.

For example, you could use the sum of downloaded files as the lower bound for the “downloaded” stat; or perhaps even use it outright when computing the ratio, rather than the network bandwidth. I mean I'm not really sure what value the actual “physical downloaded amount” is really providing. Obviously the assumption is that if you have the file, you've downloaded it, no?

[haasn]

Seems like the relevant logic is, at least, partly implemented here:

transmission/libtransmission/torrent.c

Line 412 in fbd8d4c

uint64_t const baseline = d ? d : tr_cpSizeWhenDone(&tor->completion);

My proposal would be to change

uint64_t const d = tor->downloadedCur + tor->downloadedPrev;
uint64_t const baseline = d ? d : tr_cpSizeWhenDone(&tor->completion);

To something roughly equivalent to

uint64_t const s = tor->completion->sizeNow;
uint64_t const baseline = s ? s : tr_cpSizeWhenDone(&tor->completion);

At least if my understanding of this field is correct and it reflects the amount of data that the torrent has present.

[MoBattah]

I'm seeing the same issue. Although, I'm not sure your proposal would fix it. This issue appears between lines 400-407 within libtransmission/torrent.c

I'll need to spend time on this later.

[robatino]

This is not a bug. A very small download is not automatically wrong. There are common use cases, such as the monthly updated MAME torrents (where the monthly download needed to update is on the order of 1% and can be a fraction of that) or where one already mostly has the torrent files but needs to fix a corrupted or missing file. Obviously, the BitTorrent client can't read the user's mind and has no way to know if the small download was intentional - as these cases show, it may very well be. If it's not, then it's user error and it can be fixed by deleting and re-adding the torrent, as the reporter said. (Or maybe give the user an option to set the download amount on an existing torrent to zero, which is more user-friendly.) The only exception is if the download is exactly zero, in which case the total torrent size has to be used.

I'm commenting here since the "fix" (always using the total torrent size) breaks these common use cases where the small download is intentional. If the response is that it's usually not, and that when it is one can manually calculate the ratio to get the desired upload amount, well in general, one can't, since Transmission only allows the ratio to be entered to 2 decimals. If the desired ratio relative to the entire torrent is very small, that's not enough precision. So please either allow more precision, or better yet, revert the "fix". The first alternative client I tried, qBittorrent, handles the ratio properly, and I'm guessing most of the others also do.