Insanely High Ratios......

[sledgehammer_999]

Yes, I think the correct thing to do is this. Let's assume that your torrent is 1GB. The download/upload data are lost. You do a recheck a rebuilt the resume files. After the recheck the download data counter should be equal to the total data found on disk. This is what qbt actually does if all_time_download and torrent is seeding. But as soon as all_time_download becomes a positive number (eg 1KB) it isn't treated as total_data+positive number (in my example 1GB+1KB). And I have no idea how to keep track of this...

[Starshine]

OK I get it,  :)Maybe there is no elegant way to solve this, that can be done in a reasonable amount of time. (But it's a matter of good error handling, right... ? I mean; it shouldn't start displaying crazy numbers just because it's crashed.)

So how about just adding a quick "reality check" to the ratios?

A ratio of "0" or "1" is not a big problem, even if it was 3.2 last time I looked.
But 9999.99% is silly and confusing.

So how about
"if ratio >x, then set reset ratio to y"
Say, x=20 and y=0  or perhaps 1.
(or whatever figures seems reasonable)
Can that be done?

If so, it gets rid of silly ratios in an easy way, and I hardly think anyone seeds anything to more than perhaps 15 or so..... Even if they have a seedbox. Agree?

I didn't *think* it was reporting the figure to the tracker,    but I hadn't completely ruled out the possibility... Admit. I know nothing of how torrent clients work or how trackers pick up their info the client.... But if nothing else I figured I'd have been banned from a lot of trackers already if that had been the case since this has happened on and off for as long as I used QBT.

The number is wildly off, and could potentially really confuse a torrent n00b, so I suggest using a quick and somewhat dirty fix to get rid of it.
I.e. fix being; If the number is unrealistic, then reset the number to zero or one.

[ciaobaby]

The number is wildly off, and could potentially really confuse a torrent n00b, so I suggest using a quick and somewhat dirty fix to get rid of it.

Probably not, because a "noob" probably won't have any jobs that are being (re)started from completion.

BUT  if you are the initial seeder of a 'popular' payload job, you ARE used to seeing jobs with a much, much higher upload than  downloaded data.
There is absolutely nothing unusual about what you seeing in your client, you obviously are never the initial seeder of a job.

In another post about "default columns" I stated that the "ratio" column means nothing at all for the jobs I run, NOW you now one reason WHY I consider it a useless 'metric'. For a private tracker YOUR ratio as displayed in your client is meaningless, so you can turn it off.

If you are not on a private tracker, NOBODY is forcing a ratio on you. ... So you can turn it off!

[Starshine]

Ciaobaby, c'mon what's up with you? Did I do something to you?

I report what's clearly a bug, you try to put me off, and even after it's established that it's a bug and the bug is being discussed, you practically "blame" me for wanting to track the ratio in the client, and for "complaining" that the ratio displayed is grossly incorrect.

If you were a coder who took this kind of approach in a commercial environment, well, that wouldn't go down too well, let  me tell you (I work in IT).

So final summary from me and after this, I will not trouble you any further!

I wouldn't say this is a an urgent bug, but it IS a bug, it's rather silly and it should go on the list for some kind of action in the future, as and when time allows.

I understand that it  may be tricky to do a proper fix, which is why I suggested a "dirty" fix that would get rid of the worst manifestations of this bug.

I also understand that there are probably more urgent bugs and that there'll be quite a while until this is looked into.

But come On!!  Brushing it under the carpet, refusing to log it because it seems petty, or because you don't care for people who use private trackers or whatever it is; that's really bad practice and not very professional.

Really, you may want to think about the tone just a tiny bit. I am somewhat put off this forum now. Please make an effort to be "neutral" or friendly towards people who like the software enough to come here and report bugs to the best of their ability.
I was trying to HELP the project by reporting a bug, providing info and suggesting a possible alternative approach to a fix, not annoy anybody or waste anybody's time.

[ciaobaby]

But there is no 'bug' and therefore no fix. Anything done  to 'fix' it would actually be "fudging the displayed numbers" and WILL cause more problems in the long run. If you are in IT you should already know that.

What you are seeing is simply an effect of of a very low download value coupled with a large upload value, and if you were creating torrents for this indexing site, you would see this "bug" on almost every job you had running.

And if you really need a "quick and dirty fix" turn the ratio column off, ther won't be anything quicker.

Also what you describe as a 'tone' is a combination of two rare things ... Common sense and logic, to have a 'tone' there has to be some 'emotional response'.

[Starshine]

Software should not display incorrect numbers, such as a ratio of 9999,99% when upload was 1 GB and download was 1 GB, and the ratio  therfore, is 1.

I don't see any justification for saying that this is acceptable, or intended behaviour.
Whether there was a crash and the software is doing re-indexing or whatever else caused the behaviour, is not relevant.

It is a matter of good error handling, which is clearly not present when a piece of software ends up displaying incorrect figures after a crash! The job of a developer (even if it's boring) is to handle crashes and errors properly, not just creating new functionality or dealing with faults caused by standard actions in the program.

Where exactly did you get your IT  or coding skills from? This is standard stuff!
You certainly can't do a commercial IT job at least, unless you take error handling seriously and also learn to take a user perspective when reviewing bug reports.

Would you say the same thing if financial software was showing incorrect is acceptable?

Displaying incorrect figures is never acceptable. Pretty much a golden rule. If you can't get it to display proper figures, then at least turn them off, or reset them!

But don't come out and say that the fix is to hide the column or ignore the incorrect figures. Depending on the type of software, bugs involving incorrect numbers almost always flare up to a huge issue in the end.  Sweeping it under the carpet or ignoring it usually just makes it all the worse eventually.

If this is the quality standards qbittorrent sets for itself, then I wouldn't bet much on its future.

This is obviously a bug/known issue and should be logged as such, and looked into in the future.

I am not saying it's a serious bug that needs urgent attention, but at some point it should be dealt with because it's ugly, misleading, looks unprofessional and is not a good reflection on the developers.

Have some pride in your craft and skills for goodness, sake.... 9999.99 ratios on several torrents, just because there was a crash?

[sledgehammer_999]

I think I found a pretty much bulletproof way to fix this. Pseudocode follows:

Code: Select all

if (downloaded_data < total_done)
{
   downloaded_data = total_done;
}

ratio = uploaded_data/downloaded_data;

[ciaobaby]

My point is that it is NOT an error or a 'bug', sure, what may be considered "odd" values could be truncated or limited for display purposes.

BUT

Are we going to say that EVERY single calculator in the ENTIRE WORLD that displays that same value for the same mathematics, performed on the same seed values has a 'bug' in it???

A 'bug' is when something erroneous happens for specified conditions, this value being displayed is NOT incorrect or erroneous it is 100% accurate . Computers only put out what the input values equate to. It is purely a matter of PRECISION in the display, no 'bug' no error, simply  end user perception that is in error. For people who understand what it is and why it is displaying that way it is NOT an issue, Never has been, never will be.

Let's say the column display IS truncated or limited for are you going to make it configurable? So users like myself who have MANY, MANY jobs that have very low downloaded data counts ( usually just overhead) and VERY, VERY high uploaded data counts can see the ratios that we are USED TO SEEING If we wish to??

Also when I write code that needed to display a ratio, I make sure that it is ACCURATE in what it shows, not 'dumbed down' for a few users, currently qBT is being absolutely 100% accurate in the ratio display.

[sledgehammer_999]

Fixed for next release: https://github.com/qbittorrent/qBittorr ... 87623479c1

[Nemo]

And sledge does it again, thanks mate.

[Starshine]

[quote="sledgehammer_999"]
I think I found a pretty much bulletproof way to fix this. Pseudocode follows:

Code: Select all

if (downloaded_data < total_done)
{
   downloaded_data = total_done;
}

ratio = uploaded_data/downloaded_data;

[/quote]


Fantastic, Sledgehammer!    Sorry about my little rant earlier. You are great! These things happen, def. And QBT has come along leaps and bounds for the year that I've been using it. So much more stable now.

I didn't follow all of your logic earlier, i.e. why this happened in the first place. But never mind - just nice to hear that it's moving in the right direction. It wasn't a showstopper, just "silly" and I was hoping that the fix was something obvious or fast..... The pseudo code looks spot on for keeping this at bay.

Should have included steps to reproduce, which would have been:

1) Have LOTS of torrents
2) Crash the machine or kill qbittorrent's process.
3 [optional] mess around a bit with drives to confuse QBT a bit (not sure what exactly triggers the bug, but perhaps something related to not finding torrents where it thought they should be )

Repeat until you get an "insanely high ratio" for some of the torrents.

Good riddance to this bug