Incorrect share ratio in torrent status

[ph33onix]

In /deluge/core/torrent.py, the get_ratio method always uses the total_done variable even though it has an all_time_download variable available.

Wouldn't it be best to use whichever is greater between total_done and all_time_download to get the lowest (and safest) ratio?

So:

• If the download is new then total_done and all_time_download will be about the same.
• If the download is new but some files have already been downloaded then total_done will be used as it will be bigger than all_time_download.
• If the download is old and we deselect some files(set to not download) and also delete them then all_time_download will be used as it will be (much) bigger than total_done. This is the main improvement.

The only problem case is if someone manually adds files to an old torrent. If the added files bump total_done over all_time_download which means behaviour is the same as before. If the added files don't bump total_done over all_time_download then all_time_download is used which is a bigger number and results in a lower ratio which is closer to the truth. So while this change doesn't fix this case it still improves it.

Is there anything I'm missing ?

[Cas]

We can look at it for 2.0

[Cas]

So it used to be all_time_download until:

[8e7d4f2cd47532]

Change share ratio calculation to use the total done instead of the all time downloaded value. This change will make the share ratio calculation not use data downloaded in failed hash checks.

I am thinking that total_wanted_done is going to be better for torrents with unwanted files.

---

Reference tickets: #646, #2072 and lt docs:

total_done
    the total number of bytes of the file(s) that we have. All this does not necessarily has to be downloaded during this session (that's total_payload_download).

total_wanted_done
    the number of bytes we have downloaded, only counting the pieces that we actually want to download. i.e. excluding any pieces that we have but have priority 0 (i.e. not wanted).

total_wanted
    The total number of bytes we want to download. This may be smaller than the total torrent size in case any pieces are prioritized to 0, i.e. not wanted

all_time_upload all_time_download
    are accumulated upload and download payload byte counters. They are saved in and restored from resume data to keep totals across sessions.

[Cas]

Changed in develop: [7b87a93862]

[ph33onix]

The reason I wanted the greater between all_time_download and total_done was because it would be bigger than total_done and thus a safer ratio estimation for private trackers. After reading your comments I see that all_time_download is not what I thought it was so it shouldn't be used.

However, using total_wanted_done seems even worse with regards to share ratio on private trackers. You can start a torrent, download some data, then deselect it and your client will no longer count it as necessary for the ratio, but the tracker will.

In the case of public trackers, total_wanted_done will more accurately represent what the user cares about, allowing him to share proportionally to what he wanted to download.

These are fringe cases so either one can be used without much problem but, for share ratio safety, total_done seems safer.

[Cas]

If you really feel that it would be worse for private torrents then we can check for private flag and use a different ratio calculation. What would you suggest?

[ph33onix]

I wrongly assumed that private trackers will count how many bytes you download but they don't, they track how many parts(or chunks?) you have, when you announce it. So using total_done is fine, no change needed.

Checking for private flag and using total_wanted_done for public enables users to be a bit more selfish. They can start a torrent, let it run for a bit then deselect the files they don't want and only upload enough to make up for what they wanted to download. This means they may upload less than they downloaded, hurting the swarm. So I personally don't think this would be a good change.

Overall my suggestion is to close this as not a bug.

[Cas]

Reverted in develop: [0ba87b424c6]

[Cas]

Milestone renamed