I have my default maximum share ratio set at 4.00, and when a torrent finishes downloading it starts to share as expected. The time left counts down as if the ratio was 2.00, and then once the share ratio is more than 2.00 the "Time Left" column is completely bogus. For example, one share is at 3.24 now, happily uploading, and the "Time Left" is flipping between 27,048 days, 12,515 days, 30,493 days, 16,187 days, and so on. This estimate changes every refresh. It looks like some sort of overflow is going on, although the fact that it counts down to 2.00 makes me wonder if there is some leftover hard-coded value somewhere. Note that this appears to be purely cosmetic, as sharing works fine and stops properly at 4.00 as desired. Reproducible: Always Steps to Reproduce: 1. Set maximum share ratio to 4.00 2. Download a Torrent and start to share it 3. Wait until the ratio is 2.00, and enjoy the show Actual Results: "Time Left" shows basically crazy random results. Expected Results: "Time Left" is based on a nice moving average created from upload speed, which is then applied to the amount of upload left.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Time left is still calculated incorrectly as described in current KTorrent version 20.12.0 on KDE Neon. Max share ratio is set to 5.00 (still over 2.00, just not exactly 4.00 as stated in bug title).