Force recheck performs twice #8758

New issue

Closed

opened 2026-02-21 19:47:39 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-21 19:47:39 -05:00

Owner

Originally created by @N46AN on GitHub (Jun 1, 2019).

qbittorrent 4.1.5
Windows 7 x86

setup:
Use temp folder;
Do not use .!qb extension
create subfolder

Steps to reproduce:

Finish downloading a torrent
Pause the torrent
Close qbittorrent
Move data out of finished folder
Start qbittorrent, notice that the torrent is automatically paused dueto "missing files"
Close qbittorrent
Move data back to temp folder
Start qbittorrent
Attempt to recheck and resume seeding

Actual behaviour:

The first time "Force recheck" is clicked, The status rapidly flashes "Moving" and then "Paused". No hashing is performed.
Click "Force recheck" again, hashing begins. However, after it goes to 100%, hashing is performed again. Essentially, hashing is perfomed twice.

Expected behaviour:

Hashing should perform only once.
User should not have to click "Force recheck" twice when temp folder is used and missing data is moved back.

Side note:
It is a valid use case to temporarily move finished data to somewhere else, and move it back later to resume seeding. Readding task is not desireable since user would like to preserve stats for individual torrent. Unfortunately there seems to be numerous issues regarding such use case. Thanks for taking time to read this issue!

Originally created by @N46AN on GitHub (Jun 1, 2019). qbittorrent 4.1.5 Windows 7 x86 setup: Use temp folder; Do not use .!qb extension create subfolder Steps to reproduce: 1. Finish downloading a torrent 2. Pause the torrent 3. Close qbittorrent 4. Move data out of finished folder 5. Start qbittorrent, notice that the torrent is automatically paused dueto "missing files" 6. Close qbittorrent 7. Move data back to temp folder 8. Start qbittorrent 9. Attempt to recheck and resume seeding Actual behaviour: 1. The first time "Force recheck" is clicked, The status rapidly flashes "Moving" and then "Paused". No hashing is performed. 2. Click "Force recheck" again, hashing begins. However, after it goes to 100%, hashing is performed again. Essentially, hashing is perfomed twice. Expected behaviour: 1. Hashing should perform only once. 2. User should not have to click "Force recheck" twice when temp folder is used and missing data is moved back. Side note: It is a valid use case to temporarily move finished data to somewhere else, and move it back later to resume seeding. Readding task is not desireable since user would like to preserve stats for individual torrent. Unfortunately there seems to be numerous issues regarding such use case. Thanks for taking time to read this issue!

deekerman

2026-02-21 19:47:39 -05:00

closed this issue
added the
OS: Windows
label

deekerman commented

2026-02-21 19:47:44 -05:00

Author

Owner

@N46AN commented on GitHub (Jun 10, 2019):

After much tinkering with preferences, I found out that this double recheck is because of I ticked "Recheck on torrent completion" in advanced settings.

Since the torrent was in an errored state, the first recheck essentially "completes" the torrent. Then "recheck on completion" is triggered, hence the second recheck.

I'm not sure if this can be classified as a bug or not since the program has done everything it was to told to do.

@N46AN commented on GitHub (Jun 10, 2019): After much tinkering with preferences, I found out that this double recheck is because of I ticked "Recheck on torrent completion" in advanced settings. Since the torrent was in an errored state, the first recheck essentially "completes" the torrent. Then "recheck on completion" is triggered, hence the second recheck. I'm not sure if this can be classified as a bug or not since the program has done everything it was to told to do.

deekerman commented

2026-02-21 19:47:45 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Dec 17, 2023):

I'm not sure if this can be classified as a bug or not since the program has done everything it was to told to do.

👍

@xavier2k6 commented on GitHub (Dec 17, 2023): >I'm not sure if this can be classified as a bug or not since the program has done everything it was to told to do. 👍