Make hash check more agressive (less lazy)

[gaby de wilde]

I know you love checking my files over and over again and it sure keeps things clean and neat but could it please go a bit faster, my client crashes 3 times per day now and it never quite makes it to the end of the 150 GB file.

A while back I mentioned on irc it took days to check my files and everyone laughed at me. Now I cant even get the first one done.

I'm going to test some different clients and see how long it takes. You never know, perhaps I'm just inpatient and frustrated. :|

[Firon]

It hashes as fast as your hard drive can read.

Why don't you solve the crash problem instead?

[gaby de wilde]

I don't know what caused the crash, utorrent froze then it died. Probably something wrong on my end. All I know is that my torrent list is a mess now and that hash checking goes faster in other clients so it takes ages to recover.

A few hours ago it quite interestingly started checking a torrent I had never downloaded. It took ages before it concluded it was 0% completed. It isn't configured to allocate memory so what was it doing? I had a few downloads running, normally the hash check waits for the disk to free up but now it was checking a file that didn't exist and it took quite a long time to do so.

I think my computer is haunted. I probably need a priest at this stage. lol

[Firon]

You should really check your hard drives for damage. Run a surface scan with HDDScan or something.

[BlueDragon]

It hashes as fast as your hard drive can read.

Not only the drive speed may be the bottleneck but also the CPU (or the LAN if the disk is not local) !!

The automatic (forced) piece re-check is really a pain in the a... especially if you have uT running on an older machine (which is my case).

Above all there's no reason at all to re-check what did never change but uT has been designed to do it. There's no question that checking the piece hashes is a very important thing to do to avoid spreading corrupt pieces (hash fails). But the problem is as soon as one moves a file around say from one directory to another uT starts to re-check the whole torrent from scratch. Why? Does that makes sense?

Besides as gaby de wilde correctly mentioned it may take ages for uT just to "see" that there's nothing left at all or in a .!ut file... Moreover where's the point since if some file is taken away (or incomplete) uT won't notice anything up to the moment when this file will be requested by a peer. Only at that very moment if the requested block is missing the torrent will be stopped immediately with an typical error (and sometimes I get this error simply because the file on a remote place is not available fast enough).

There can be many reasons one needs to move around files and one of them I am facing regularly is following one: I have a limited disk space. So why does uT force me to re-check something only because I change the disk position (path)?

Indeed (fortunately) there is a plain stupid way to avoid this by simply exiting uT, editing the resume.dat path with the bencode editor of ultima for instance, moving the file(s) to the needed place and restarting uT. No foolish re-cheking for nothing because the data remains the data except of course if my file system gets corrupted during the copy process but that is a risk which will always be there anyway.

[DreadWingKnight]

Not only the drive speed may be the bottleneck but also the CPU (or the LAN if the disk is not local) !!

It's EXTREMELY EXTREMELY rare that the CPU is EVER the bottleneck for piece hashing. The only occurrence of this I know of is when the particular hard drive being checked has lapsed into PIO mode, and you have more pressing issues if that has happened.

[monstrex]

Well, my cents for this is... I too have this problem. Many torrents and sometimes I forget to open my network drive. So, there it goes again checking every torrent... and it takes hours! Some are really big...

Lasy check is an option... or anything else but this long time is a pain the the ***....

Anyway, best program on earth for torrents!

Thank you.

[Switeck]

Back up your settings in uTorrent.

You forget to plug in/turn on the network drive, restart with the older settings once you get the drive turned on and ready.

[BlueDragon]

It's EXTREMELY EXTREMELY rare that the CPU is EVER the bottleneck for piece hashing.

EXTREME EXTREMES are depending of your position on the scale...

Anyway I am 100% sure of what I am stating. FYI I use an old Toshiba Notebook (originally designed for win98) Satellite 4070CDT with win xp and a Intel Celeron CPU 366MHz + 192MB RAM. I am surprised it's still alive now running 24/24 7/7 for over a year...

Back up your settings in uTorrent.

You forget to plug in/turn on the network drive, restart with the older settings once you get the drive turned on and ready.

Yes this is a walkaround exactly as I stated above for moving a file whilst avoiding the foolish automatic forced re-check. The problem is who wants to back up his resume.dat file every day or every time one switches the system off?...

A couple of hours ago I had following scenario (once more): I added a torrent and selected my default data storage path. As usual first I did not start the torrent. Then I analysed my HDD space and I realised I would have to select another drive. I openend the advanced panel --> Set Download Location in order to change the path. Remember: At that point I had not dl any single bit! After having corrected (set) the new dl location I started the torrent and guess what happened... uT started to check and check and check... Check what? :mad: There was not a *single* bit of data to check... And this could last minutes. So I cut the story short: Deleted the torrent without deleting the .torrent file and reloaded it, this time immediately entering the needed path. Started it and voila. That's uT gymnastics...