Open antifuchs opened 4 months ago
how you define "correct" share ratio if you didn't download anything...
Please notice that the issue description is attempting to define exactly that for the case I am reporting. The data being seeded was downloaded (torrent didn't start out seeding), only the transmission API isn't reporting the data downloaded under the field that flood expects.
I'm getting confused.
On torrents that were downloaded from elsewhere,
do you mean, other bt client? so transmission doesn't track downloading
What if I create a torrent and seeding it? You can't tell the difference from api.
But I can get your point
pull request welcome. we could change this to uploaded/totalSize, this make more sense.
Type: Bug Report
Your Environment
git --no-pager log -1
: 2b652f8148dab7134eeeb201b9d81dd6b8bda074node --version
npm --version
name and version
Summary
I'm not sure why the transmission API does this, but on occasion some seeding torrents will show 0 bytes downloaded; that causes flood to display the up/download ratio as
-1
.Expected Behavior
On torrents that were downloaded from elsewhere, it would be great if the ratio could be correctly computed, instead of punting on the computation. The transmission API reports an
uploadRatio
field (in the RPC spec fortorrent-get
), and it tends to be correct. Maybe flood can use that?If that's not usable, I would suggest using the
totalSize
field as the divisor instead ofdownloadedEver
(as total size tends to not be zero).Current Behavior
Currently, it looks like flood is dividing the amount of data uploaded (
uploadedEver
) by the amount of data downloaded (downloadedEver
). If the divisor should be zero, that results in a not-a-number result, which I assume flood translates into-1
.I imagine it is reasonable for torrents that this instance started seeding, but transmission also reports 0B total downloaded on torrents that it downloaded from somewhere else (again, not sure why).
Possible Solution
Several options:
uploadRatio
from the transmission RPC APItotalSize
(which is accurately reported by the API) instead ofdownloadedEver
(which isn't) - but only if the torrent didn't start seeded... I imagine there would be a difference in the "date added" and "date finished" fields that could be used.Steps to Reproduce
I could not find a common pattern for when the transmission API reports useless field values (it has similar issues with the "date finished" field on occasion), sorry /:
Context