torrent "checking" is extremely slow

[mpollachek]

Under search I had seen that someone had a post about this in 2013, but the problem was never solved.

I just switched from utorrent, so I brought in a few open torrents. qtorrent needs to "check" the files that are already on my hdd. my hdd is a 2 tb 5400 rpm hdd, and it looks like it will take hours to look at how much is already downloaded of a 40 gb file. In addition, it greatly slows down my download speed on other files. I think qtorrent is scanning the entire drive for each file rather than just finding the directory and making a note of what files I have in there.

[chrishirst]

qtorrent is scanning the entire drive for each file rather than just finding the directory

Nope, it will only check the location that you have told it where the payload is located, however; if the drive is fragmented and the payload is not in contiguous drive space it WILL take longer, as uTorrent v3 + was [and probably still is] pretty poor in the payload fragmentation department.

[mpollachek]

Thanks for your response. I will try defragmenting the hard drive and see if it speeds up the process.

[ghost]

That sounds pretty normal. I've found qB is much faster at checking torrents than uT. It just takes time to check the files. Plus, a 5400 rpm hdd isn't the fastest.

[wlerin]

It has to do more than just make sure the files are there, it has to make sure the files are complete, and that the checksums match. To do this it has to read the entirety of each file, so this make take a long time when there are many and/or large files. (A 40 GB file counts as "large", even worse when it's only there in parts).

it will only check the location that you have told it where the payload is located

If only this were the case. It seems to only check the Incomplete/Temp folder, not whatever destination you set.

[chrishirst]

It seems to only check the Incomplete/Temp folder,

The recheck will check the payload no matter where it is located.

To do this it has to read the entirety of each file, so this make take a long time when there are many and/or large files

Not strictly true. Yes, the total size of the payload will determine the time it takes, but the number or size of individual files does not matter. It is individual pieces of the payload that are 'read', hash summed and checked against the metadata, not individual files.

[jonathanlyonmoore]

Refer to this thread.

https://qbforums.shiki.hu/index.php?topic=4230.0

I think the skip rechecking is in Tools->Options->Advanced "Confirm Torrent Recheck"

It is the "skip checking" label. I think, I might be wrong

[fisherwei]

sorry for reply an old thread, but I have the same issue.

qbittorrent rechecks a 700GB folder is very very slow.

I have an SSD pool as storage and a 4-cores 3.2GHz cpu,
when qbittorrent is checking, the task manager shown 17-20%@0.8-0.9GHz CPU usage and 30-40MB/s disk usage.

[2play]

qbit is really slow in checking by far. Compared same files / location Vuze is blasting compared to qbit.
I m planning to test other clients. Anyone with feedback please advise for the sake of all :-)

[thalieht]

The next version (4.1.2) should have some optimizations in this regard (from newer libtorrent version) and from exposing a libtorrent setting in the advanced options: Asynchronous I/O threads (not sure if this will make it to 4.1.2).

[2play]

I have tested PicoTorrent client and did well for a 110GB check
Ok I wont post further but Im happy to hear from @thalieht that the issue is being looked at and will hopefully fixed or imporeve witht the next release! Much appreciated

[grommit]

I think the issue, coming from uTorrent and others, is that on uTorrent when you select a large list of torrents, it checks them one at a time, while on qtBitTorrent, it checks them all simultaneously. This is very bad for IO performance if your storage array is spinning disks, especially 5400rpm spinning disks, since it seeks randomly all over hundreds of GB while checking all the torrents simultaneously.

I haven't found it yet, but is there an option to queue checking to only X torrents at a time? I would set it to 1. The single-torrent performance for checking is very good, but it takes way longer to do 10 if you set them to run at the same time than if you manually check each one after the first one finishes. But that's tedious compared to queuing multiple to check one at a time for better performance.

[Seeker2]

As grommit pointed out about qBT trying to recheck every torrent at once...there's an issue ticket on that as well:
[Behavior] Force Recheck of Multiple Torrents #9120

[matbrgz]

The next version (4.1.2) should have some optimizations in this regard (from newer libtorrent version) and from exposing a libtorrent setting in the advanced options: Asynchronous I/O threads (not sure if this will make it to 4.1.2).

Still have not achieved surprising results, I have a 500GB files running on HDD 7200RPM and I'm taking about 4 hours to generate the dotTorrent files and another 4 hours to recheck the file. It would be too much if it were possible to generate the hashs of the dotTorrent file faster as well as optimize the recoding. Would it be possible to change the protocol to perfect it? Where to start?

Nice reading: https://bench.cr.yp.to/results-sha3.html
https://crypto.stackexchange.com/questions/418/is-the-number-of-creatable-torrents-limited
bittorrent/bittorrent.org#58

[dessalines]

This is a huge problem rn that is killing my hard drive. I had to repair it, and now all my 500+ torrents are being checked simultaneously instead of in a queue.

[ano0]

its probably single threaded or something. it cant even check multiple torrents at the same time so that slows things down even more. thats not a qb specific issue tho because its a problem in all torrent clients.

[wlerin]

I barely notice it in rtorrent or Transmission though, even though the former is using the same underlying library. (Transmission probably is too I've just never looked under the hood.)

[AB1908]

Refer to this thread.

https://qbforums.shiki.hu/index.php?topic=4230.0

I think the skip rechecking is in Tools->Options->Advanced "Confirm Torrent Recheck"

It is the "skip checking" label. I think, I might be wrong

@jdm7dv Thanks!

[thalieht]

Torrents are no longer checked in parallel and now there are a few advanced options to experiment with. I don't think there's anything more to do for this issue.

[vith]

I think this is still a problem with the default settings in qBittorrent, at least for HDDs.

I made these changes to advanced settings:

Asynchronous I/O threads: 1
Hashing threads: 1
Outstanding memory when checking torrents: 512 MiB

The recheck speed went from 100MB/s to 165MB/s, now matching the speed I get with Tixati.