qBittorrent official forums

I think I found a bug. Just check the following picture:



As you can see, 4 files have high ratio, I usually have ratios of my files around 10-15, but 600, goddamn.

To reproduce it, you just have to download a file, then umount the filesystem where the file is stored. Next run qbitorrent and the file will corrupt, I think it will be paused. Then close qbittorrent, mount the file system and start the app again. The qbittorrent should start downloading the file. If you press "pause" and force recheck the file, it should rehash and be completed, and the ratio also should change to 500, 1000 or whatever. This only occurs when a file starts to download, otherwise the ratio won't change.

Not an actual bug just the maths.

The jobs have restarted, possibly after a crash judging by the "Paused for checking" status, lost the data transfer history and have required a small download to recover to 100%.

There is a thread about the same issue somewhere on the forum.

[EDIT]
Here you are.
http://qbforums.shiki.hu/index.php/topic,2563.0.html

Actually it's not the recovery. When I start qbittorrent without mounting the filesystem, all torrents become automatically paused and the % of downloading of the each file is 0, not 99. If I start qbittorrent after mounting the filesystem, it thinks all files weren't downloaded yet and have 0% completed, then qbittorrent starts to download them as if they were just added. I immediately stopped the action and forced recheck, but not fast enough.

In the topic it's something like this:

System crashes and torrent rechecks almost always means that qbt has lost all previous download/upload history. Hence the odd ratios.

But it only looses download history, why not both? Or, why does it loose download history? If it's able to save upload history, shouldn't it be also able to save download history?

The issue is fixed for 3.1.10

If it's able to save upload history,

It doesn't, it is the upload SINCE the recovery that it is showing and being used  for the "ratio" calculation.

Look at the following picture:



As you can see, you have saved uploaded data and the time. The only one thing that was reset was the downloaded data, and here's the problem of the high ratio.

Nope, UNLESS the torrent payload IS only 766.4KiB you ONLY have data downloaded SINCE the restart. (or overhead download only).

Do the maths, what DOES 518.9 MiB / 766.4 KiB * 100 come to??

(518.9 * 1024 * 1024)/(766.4 * 1024) * 100

This bug is fixed already. Enough explanation on why the code shows that absurd ratio is given in the linked thread. Read it.
Hint: the code assumes that all data on disk are already uploaded once, even thought the upload history doesn't exist.
I am locking this.