[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transmission: -1 ratio on seeding torrents with 0B downloaded #720

Open
1 task done
antifuchs opened this issue Feb 20, 2024 · 5 comments
Open
1 task done

transmission: -1 ratio on seeding torrents with 0B downloaded #720

antifuchs opened this issue Feb 20, 2024 · 5 comments

Comments

@antifuchs
Copy link

Type: Bug Report

  • Try to follow the update procedure described in the README and try again before opening this issue.

Your Environment

  • Version used: (via nixos)
    • Version (stable release) 4.7.0
    • 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

@trim21
Copy link
Collaborator
trim21 commented Apr 25, 2024

how you define "correct" share ratio if you didn't download anything...

@antifuchs
Copy link
Author

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.

@trim21
Copy link
Collaborator
trim21 commented Apr 25, 2024

I'm getting confused.

On torrents that were downloaded from elsewhere,

do you mean, other bt client? so transmission doesn't track downloading

@trim21
Copy link
Collaborator
trim21 commented Apr 25, 2024

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.

@RA341
Copy link
Contributor
RA341 commented Aug 20, 2024

@trim21 let me know if I missed something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants