You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit ID (development release) git --no-pager log -1: 2b652f8
Environment name and version:
Node.js version node --version
npm version npm --version
Web browser name and version
Operating system and version: NixOS 23.11
Torrent client and version: Transmission 3.00
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 for torrent-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 of downloadedEver (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:
use uploadRatio from the transmission RPC API
use totalSize (which is accurately reported by the API) instead of downloadedEver (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
The text was updated successfully, but these errors were encountered:
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.
Type: Bug Report
Your Environment
git --no-pager log -1
: 2b652f8node --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
The text was updated successfully, but these errors were encountered: