starred/qBittorrent

Fork 0

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

Recheck multiple torrents at a time #12329

New issue

Closed

opened 2026-02-21 22:36:20 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-21 22:36:20 -05:00

Owner

Originally created by @vincent-163 on GitHub (Aug 7, 2021).

Feature request

Checklist

I have read the feature request section in the contributing guidelines, so I know how to submit a good feature request with the required information
I have verified that the feature I am requesting is not available in the latest version
(optional but recommended) I have verified that the feature I am requesting is not available in the latest CI build
I have checked the frequent/common issues list and searched the issue tracker for similar feature requests (including closed ones) to avoid posting a duplicate
This request is not a support request or question, both of which are better suited for either the discussions section, forum, or subreddit. The wiki did not contain a suitable solution either

Description

Before #9120 was fixed, the client concurrently checks all torrents at the same time. After #9120, only one torrent is checked at a time. I think both behaviors are going to extremes.

Suggestion

Allow configuring the number of torrents that can be checked at a time, similar to maximum number of active simultaneous (downloads|uploads). The default would be 1 so as to be consistent with the current behavior.

Use case

While checking too many torrents concurrently would not be ideal for torrents on the same HDD, checking only one torrent at a time is not ideal either. I am rechecking a lot of small files (10MB for each file, 50MB for each torrent, 3000 torrents) on a computer. The iotop command shows that my qBittorrent instance is consuming only 3% of total disk IO, and there is a potential to check even faster.

Originally created by @vincent-163 on GitHub (Aug 7, 2021). # Feature request  ## Checklist  - [x] I have read the **feature request section** in the [contributing guidelines](https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md), so I know how to submit a good feature request with the required information - [x] I have verified that the **feature** I am requesting is **not available** in the **[latest version](https://www.qbittorrent.org/download.php)** - [ ] (optional but recommended) I have verified that the **feature** I am requesting is **not available** in the **[latest CI build](https://github.com/qbittorrent/qBittorrent/actions/workflows/ci.yaml?query=branch%3Amaster+event%3Apush)** - [x] I have **checked the [frequent/common issues list](https://github.com/qbittorrent/qBittorrent/projects/2)** and **searched** the issue tracker for similar feature requests (including closed ones) **to avoid posting a duplicate** - [x] This request is **not a support request or question**, both of which are better suited for either the [discussions section](https://github.com/qbittorrent/qBittorrent/discussions), [forum](https://qbforums.shiki.hu/), or [subreddit](https://www.reddit.com/r/qBittorrent/). The [wiki](https://github.com/qbittorrent/qBittorrent/wiki) did not contain a suitable solution either ## Description Before #9120 was fixed, the client concurrently checks all torrents at the same time. After #9120, only one torrent is checked at a time. I think both behaviors are going to extremes. ### Suggestion Allow configuring the number of torrents that can be checked at a time, similar to maximum number of active simultaneous (downloads|uploads). The default would be 1 so as to be consistent with the current behavior. ### Use case While checking too many torrents concurrently would not be ideal for torrents on the same HDD, checking only one torrent at a time is not ideal either. I am rechecking a lot of small files (10MB for each file, 50MB for each torrent, 3000 torrents) on a computer. The `iotop` command shows that my qBittorrent instance is consuming only 3% of total disk IO, and there is a potential to check even faster.

deekerman

2026-02-21 22:36:20 -05:00

closed this issue
added the
Feature request

Core
labels

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@nulldevde commented on GitHub (Sep 9, 2021):

This should include the ability to check one torrent per physical disk on all disk at the same time. For example: Setting the number of concurrent recheck to 6 and all six using the same HDD is a waste of both machine and developer time, while there is 6 HDDs with torrents.

@nulldevde commented on GitHub (Sep 9, 2021): This should include the ability to check one torrent per physical disk on all disk at the same time. For example: Setting the number of concurrent recheck to 6 and all six using the same HDD is a waste of both machine and developer time, while there is 6 HDDs with torrents.

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@vincent-163 commented on GitHub (Sep 10, 2021):

This should include the ability to check one torrent per physical disk on all disk at the same time. For example: Setting the number of concurrent recheck to 6 and all six using the same HDD is a waste of both machine and developer time, while there is 6 HDDs with torrents.

I think that in general, it is hard to distinguish whether the files are on different disks or not correctly. For example, in order to do it in Linux, you have to check the mount that each file belongs to and then its underlying block device, whereas in Windows you have to check the disk that a partition belongs to. There is also a lot of corner cases like LVM and RAID.

A better way is to have the user select which disk a torrent belongs to. This can be set per category, for example, and then the user may specify the number of concurrent rechecks per category. However I believe the easiest solution would be to run a qBittorrent instance per disk, which requires little work on developer's part.

@vincent-163 commented on GitHub (Sep 10, 2021): > This should include the ability to check one torrent per physical disk on all disk at the same time. For example: Setting the number of concurrent recheck to 6 and all six using the same HDD is a waste of both machine and developer time, while there is 6 HDDs with torrents. I think that in general, it is hard to distinguish whether the files are on different disks or not correctly. For example, in order to do it in Linux, you have to check the mount that each file belongs to and then its underlying block device, whereas in Windows you have to check the disk that a partition belongs to. There is also a lot of corner cases like LVM and RAID. A better way is to have the user select which disk a torrent belongs to. This can be set per category, for example, and then the user may specify the number of concurrent rechecks per category. However I believe the easiest solution would be to run a qBittorrent instance *per disk*, which requires little work on developer's part.

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Oct 16, 2021):

Can this be considered a duplicate of https://github.com/qbittorrent/qBittorrent/issues/12210?

@FranciscoPombal commented on GitHub (Oct 16, 2021): Can this be considered a duplicate of https://github.com/qbittorrent/qBittorrent/issues/12210?

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@vincent-163 commented on GitHub (Oct 17, 2021):

Can this be considered a duplicate of #12210?

I think this is different from #12210. I'm not requesting to recheck torrents per physical drive, since it's hard to implement. Instead I'm proposing something more concrete. I'd like to allow rechecking multiple torrents simultaneously, even if they're on the same drive, depending on the user's configuration.

The thing is that it's not always fastest to recheck a single torrent at a time, and there's potential for performance improvements in many cases:

If there are other I/O operations on the same disk, using more threads for rechecking helps competing for disk I/O.
Rehashing can be CPU-bound at times (especially when other processes are using lots of CPU) and multithreading can make it faster.
Certain disk configurations like RAID or LVM or mergerfs may have complex performance behaviors, where files in the same directory can come from two different disks.

I think it's best to leave it to the user to manage these complexity. Specifically, I would like to request:

A per instance limit of how many torrents to check simultaneously. It should default to 1 to retain the current behavior, so only one torrent is rechecked at a time, but the user can tune it to its needs.
A per category limit of above. It should default to infinity, and rely on the per instance limit instead. This covers #12210 as well. Instead of having qBittorrent detect which files are on which disk, the user can group torrents into categories depending on which disk the torrent is on.

This should be the simplest way to allow the behavior of old versions and new versions, and also cover requests like #12210.

@vincent-163 commented on GitHub (Oct 17, 2021): > Can this be considered a duplicate of #12210? I think this is different from #12210. I'm not requesting to recheck torrents per physical drive, since it's hard to implement. Instead I'm proposing something more concrete. I'd like to allow rechecking multiple torrents simultaneously, even if they're on the same drive, depending on the user's configuration. The thing is that it's not always fastest to recheck a single torrent at a time, and there's potential for performance improvements in many cases: * If there are other I/O operations on the same disk, using more threads for rechecking helps competing for disk I/O. * Rehashing can be CPU-bound at times (especially when other processes are using lots of CPU) and multithreading can make it faster. * Certain disk configurations like RAID or LVM or mergerfs may have complex performance behaviors, where files in the same directory can come from two different disks. I think it's best to leave it to the user to manage these complexity. Specifically, I would like to request: 1. A per instance limit of how many torrents to check simultaneously. It should default to 1 to retain the current behavior, so only one torrent is rechecked at a time, but the user can tune it to its needs. 2. A per category limit of above. It should default to infinity, and rely on the per instance limit instead. This covers #12210 as well. Instead of having qBittorrent detect which files are on which disk, the user can group torrents into categories depending on which disk the torrent is on. This should be the simplest way to allow the behavior of old versions and new versions, and also cover requests like #12210.

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Oct 18, 2021):

@vincent-163

Thanks for the clarification. You make good points. The only thing I dislike about your approach is the reliance on having multiple instances of qBittorrent running to make this work, each with their own config. It would be best if only one instance could do this on its own. Perhaps a slider with which the user can dynamically set the number of simultaneous recheck jobs?

Other than that, right now I can only think of a rather complex solution that is probably very difficult to implement reliably: automatic adjustment of number of simultaneous recheck jobs based on disk and CPU performance metrics, (possibly compared against a pre-benchmarked baseline, to help make better decisions). libtorrent might actually provide at least some of the necessary metrics in its API, but I haven't looked into it.

@FranciscoPombal commented on GitHub (Oct 18, 2021): @vincent-163 Thanks for the clarification. You make good points. The only thing I dislike about your approach is the reliance on having multiple instances of qBittorrent running to make this work, each with their own config. It would be best if only one instance could do this on its own. Perhaps a slider with which the user can dynamically set the number of simultaneous recheck jobs? Other than that, right now I can only think of a rather complex solution that is probably very difficult to implement reliably: automatic adjustment of number of simultaneous recheck jobs based on disk and CPU performance metrics, (possibly compared against a pre-benchmarked baseline, to help make better decisions). libtorrent might actually provide at least some of the necessary metrics in its API, but I haven't looked into it.

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@vincent-163 commented on GitHub (Oct 19, 2021):

@vincent-163

Thanks for the clarification. You make good points. The only thing I dislike about your approach is the reliance on having multiple instances of qBittorrent running to make this work, each with their own config. It would be best if only one instance could do this on its own. Perhaps a slider with which the user can dynamically set the number of simultaneous recheck jobs?

Currently there are settings like "max number of connections", "max connections per torrent", "upload windows per torrent", etc. The user can enter a number to change these limits, or uncheck that setting to remove the limits.

I think it would suffice to add a setting called "max number of simultaneous recheck jobs" or something similar, implement it just like how all these number-valued settings are implemented, and leave the problem of deciding that number to the user. A default value between 1 and 5 would be sane IMHO. While CPU and disk performance metrics are useful, it probably doesn't make much sense to automatically adjust these settings, since the user might have other specific needs (they may want to reduce CPU/disk IO so other programs get more share, or disable the limit entirely to eat up all their SSD bandwidth, etc) and the default value should be able to cover a majority of cases.

@vincent-163 commented on GitHub (Oct 19, 2021): > @vincent-163 > > Thanks for the clarification. You make good points. The only thing I dislike about your approach is the reliance on having multiple instances of qBittorrent running to make this work, each with their own config. It would be best if only one instance could do this on its own. Perhaps a slider with which the user can dynamically set the number of simultaneous recheck jobs? Currently there are settings like "max number of connections", "max connections per torrent", "upload windows per torrent", etc. The user can enter a number to change these limits, or uncheck that setting to remove the limits. I think it would suffice to add a setting called "max number of simultaneous recheck jobs" or something similar, implement it just like how all these number-valued settings are implemented, and leave the problem of deciding that number to the user. A default value between 1 and 5 would be sane IMHO. While CPU and disk performance metrics are useful, it probably doesn't make much sense to automatically adjust these settings, since the user might have other specific needs (they may want to reduce CPU/disk IO so other programs get more share, or disable the limit entirely to eat up all their SSD bandwidth, etc) and the default value should be able to cover a majority of cases.

deekerman commented

2026-02-21 22:36:33 -05:00

Author

Owner

@mintro32 commented on GitHub (Jun 6, 2022):

In my case, I seed a lot from a cloud drive where each one read is capped at 1gbps, so multiple simultaneous rechecks would allow me to utilize my 10gbps connection much better.

I understand that it's hard to make this feature work properly automatically, but maybe you can add a "check now" action on each torrent to allow users to manually start a recheck right away. To mitigate the issue of people using this option accidentally, this could be a feature that must be enabled in settings before using.

@mintro32 commented on GitHub (Jun 6, 2022): In my case, I seed a lot from a cloud drive where each one read is capped at 1gbps, so multiple simultaneous rechecks would allow me to utilize my 10gbps connection much better. I understand that it's hard to make this feature work properly automatically, but maybe you can add a "check now" action on each torrent to allow users to manually start a recheck right away. To mitigate the issue of people using this option accidentally, this could be a feature that must be enabled in settings before using.

deekerman referenced this issue

2026-02-21 23:29:09 -05:00

Invalid Handle Crash Dump #13036