starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

recheck of files doesn't add new ones #6930

New issue

Closed

opened 2026-02-21 18:41:36 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-21 18:41:36 -05:00

Owner

Originally created by @YuryMatveev on GitHub (Feb 21, 2018).

QBittorrent 4.0.4 on Win7Sp1x64

If I start download files using torrent, and using http (separately),
stop the torrent, copy downloaded (by http) files to the torrent folder instead of .!qb files,
start rehashing -> it show 0% for these files.
CRC32 hash is ok.

I think qBittorrent should append these files as the already downloaded ones.

PS: if I delete torrent and .!qb files, then redownload .torrent file and start it, it finds and shows fully these downloaded files.

Originally created by @YuryMatveev on GitHub (Feb 21, 2018). QBittorrent 4.0.4 on Win7Sp1x64 If I start download files using torrent, and using http (separately), stop the torrent, copy downloaded (by http) files to the torrent folder instead of .!qb files, start rehashing -> it show 0% for these files. CRC32 hash is ok. I think qBittorrent should append these files as the already downloaded ones. PS: if I delete torrent and .!qb files, then redownload .torrent file and start it, it finds and shows fully these downloaded files.

deekerman

2026-02-21 18:41:36 -05:00

closed this issue
added the
OS: Windows
label

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@ghost commented on GitHub (Feb 27, 2018):

While Yury's a little wonky here, this is still an issue and has been an issue (#165) for quite some time.

Any file that is registered as not already being complete in a qBit torrent entry will continue to register as such, even if the file has been DLed via another torrent, client, method (DDL, XDCC) and the CRC checks out. The only solution I've found is, as Yury said, to delete the torrent entry from qBit and readd that file to the client: it will then check the file as being there, intact.

This happens when, for instance, a torrent is stalled and then paused, the files in question are found elsewhere, placed in the directory and then the torrent is rechecked. It will claim it's at the same percentage (or may actually drop to 0%).

Also happens when a private torrent or otherwise separate torrent that contains the same file finishes it, and the other is then rechecked (after having been paused), or vice versa. It will show as incomplete/missing.

It also happens when files are moved from one directory to another, the torrent (previously Complete) detects this and considers the files as missing, and you then recheck it after relocating the torrent's directory in qBit.

While I'm not sure if it's related to the .qB! extension as in 165, it's definitely a bug. The torrent in the client, in all cases, doesn't seem to recognise any files that it itself did not download there, without deleting and readding said torrent (I faintly recall working around this under very specific circumstances in 3.x, but I don't believe that workaround works anymore, if I could even remember how)

@glassez I figure I should ping you about this as you were active in the 165 issue. You said last that, with the the .qB! option enabled, so long as the file does not have the .qB! extension it will not be recognised by the client, even if it's one of the files the torrent would contain. Is there no possible workaround for this at this point other than by deleting and readding the torrent?

@ghost commented on GitHub (Feb 27, 2018): While Yury's a little wonky here, this is still an issue and has been an issue (#165) for quite some time. *Any* file that is registered as not already being complete in a qBit torrent entry will continue to register as such, even if the file has been DLed via another torrent, client, method (DDL, XDCC) and the CRC checks out. The only solution I've found is, as Yury said, to delete the torrent entry from qBit and readd that file to the client: it will then check the file as being there, intact. This happens when, for instance, a torrent is stalled and then paused, the files in question are found elsewhere, placed in the directory and then the torrent is rechecked. It will claim it's at the same percentage (or may actually drop to 0%). Also happens when a private torrent or otherwise separate torrent that contains the same file finishes it, and the other is then rechecked (after having been paused), or vice versa. It will show as incomplete/missing. It also happens when files are moved from one directory to another, the torrent (previously Complete) detects this and considers the files as missing, and you then recheck it after relocating the torrent's directory in qBit. While I'm not sure if it's related to the .qB! extension as in 165, it's definitely a bug. The torrent in the client, in all cases, doesn't seem to recognise any files that it itself did not download there, without deleting and readding said torrent (*I faintly recall working around this under very specific circumstances in 3.x, but I don't believe that workaround works anymore, if I could even remember how*) @glassez I figure I should ping you about this as you were active in the 165 issue. You said last that, with the the .qB! option enabled, so long as the file does not have the .qB! extension it will not be recognised by the client, even if it's one of the files the torrent would contain. Is there no possible workaround for this at this point other than by deleting and readding the torrent?

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@Ryrynz commented on GitHub (Mar 7, 2018):

This software seems quite buggy, I've had no luck with it accepting complete files when rechecking, only what it's downloaded. I should be able to just set everything to normal, do a recheck and it scans everything and this doesn't occur. I'm hoping re-adding the torrent will resolve it. But this is seriously annoying coming from a client (uTorrent) which is completely stable in this area, this is wasting a lot of my time.

Managed to re-add the torrent and all files are being checked and coming up 100%.. Finally.

@Ryrynz commented on GitHub (Mar 7, 2018): This software seems quite buggy, I've had no luck with it accepting complete files when rechecking, only what it's downloaded. I should be able to just set everything to normal, do a recheck and it scans everything and this doesn't occur. I'm hoping re-adding the torrent will resolve it. But this is seriously annoying coming from a client (uTorrent) which is completely stable in this area, this is wasting a lot of my time. Managed to re-add the torrent and all files are being checked and coming up 100%.. Finally.

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@Supralateral commented on GitHub (Mar 14, 2018):

@Nomuit

Is there no possible workaround for this at this point other than by deleting and readding the torrent?

I have found it far easier to go into the settings and disable the "Append .!qB extension to incomplete files" setting any time I have to re-check files.
Any time that setting is enabled, it seems the client will only recheck files with the .!qB extension appended.

Laughably sad qBittorrent has such poor rechecking handling after 6+ years of there being multiple issues.

@Supralateral commented on GitHub (Mar 14, 2018): @Nomuit >Is there no possible workaround for this at this point other than by deleting and readding the torrent? I have found it far easier to go into the settings and disable the "Append .!qB extension to incomplete files" setting any time I have to re-check files. Any time that setting is enabled, it seems the client will only recheck files with the .!qB extension appended. Laughably sad qBittorrent has such poor rechecking handling after 6+ years of there being multiple issues.

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@FireCulex commented on GitHub (Nov 24, 2018):

#9348

@FireCulex commented on GitHub (Nov 24, 2018): #9348

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@bathrobehero commented on GitHub (Feb 8, 2019):

After all this time force recheck still fails to detect files. The files are there, with real name without !dB, with content, not empty files, with the right name yet after a scan it's 0%. And if I disable !dB it empties the files completely. What a joke.

@bathrobehero commented on GitHub (Feb 8, 2019): After all this time force recheck still fails to detect files. The files are there, with real name without !dB, with content, not empty files, with the right name yet after a scan it's 0%. And if I disable !dB it empties the files completely. What a joke.

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@Ryrynz commented on GitHub (Feb 9, 2019):

Well I'd like to chime in that I've not had any issues with since the start of last year, but then I don't have .!qb enabled.. You may not have the files in the right location.

@Ryrynz commented on GitHub (Feb 9, 2019): Well I'd like to chime in that I've not had any issues with since the start of last year, but then I don't have .!qb enabled.. You may not have the files in the right location.

deekerman commented

2026-02-21 18:41:40 -05:00

Author

Owner

@ghost commented on GitHub (Jul 25, 2022):

This issue has been closed for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.

@ghost commented on GitHub (Jul 25, 2022): This issue has been closed for being too old, and thus either most likely resolved in recent versions or no longer applicable. If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.