rTorrent hash checking even when option set to no about rtorrent

[rakshasa]

How do you shut down the client, does it have time to write the session files?

Also, how much of the torrent (e.g. completed / downloading / all remaining chunks) get hashed?

[xxxxxxxxxxxx]

It happens even when torrent is completed at 100% .

I use it with screen. To quit its ctrl + q + q.

"Also, how much of the torrent (e.g. completed / downloading / all remaining chunks) get hashed?"

I am setting up my box from the ground up. (Reformat). Will try again in awhile to see if i could reproduce this.

I'll post my findings in a moment. Thank you for replying though.

[xxxxxxxxxxxx]

Okay, Well I tried it on a new machine and its still the same.

It happens on all torrents. You'd only notice it on larger ones (above 400MB) as they take a longer time to check.

Basically upon quitting rtorrent (CTRL + Q + Q) and starting it up, it would queue all torrents and start hash checking one by one.

The options in my .rtorrent.rc :

Hash

check_hash = no
hash_read_ahead = 30
hash_interval = 5
hash_max_tries = 5
pieces.preload.type.set = 1
max_memory_usage = 1250M

[rakshasa]

Those are all the options in your .rtorrent.rc?

[xxxxxxxxxxxx]

Nope.

Those are the hash options.

The full .rtorrent.rc is as below:

Directories

directory = /home/USERNAME/Downloads/Temp
session = /home/USERNAME/Downloads/.session
schedule = watch_directory,5,5,load_start=/home/USERNAME/Downloads/Watch/*.torrent
schedule = untied_directory,5,5,stop_untied=
system.method.set_key = event.download.finished,move_complete,"d.set_directory=/home/USERNAME/Downloads/Completed/;execute=mv,-u,$d.get_base_path=,/home/USERNAME/Downloads/Completed/"
schedule = low_diskspace,5,60,close_low_diskspace=100M

BitTorrent

max_downloads_global = 350
max_uploads_global = 15
min_peers = 50
max_peers = 300
min_peers_seed = 5
max_peers_seed = 5
max_uploads = 3
download_rate = 3500
upload_rate = 20

Network

port_range = 50000-50000
network.scgi.open_port = localhost:5000
network.http.ssl_verify_peer.set=0
port_random = no
use_udp_trackers = yes
encryption = allow_incoming,try_outgoing,enable_retry
network.max_open_files.set = 1024
network.max_open_sockets.set = 100
network.http.max_open.set = 48
network.send_buffer.size.set = 4M
network.receive_buffer.size.set = 4M
dht = on
dht.port.set = 6881
peer_exchange = yes

Hash

check_hash = no
hash_read_ahead = 30
hash_interval = 5
hash_max_tries = 5
pieces.preload.type.set = 1
max_memory_usage = 550M
execute = {sh,-c,/usr/bin/php /var/www/rutorrent/php/initplugins.php USERNAMEHERE &}

[buds]

Similar issue here.

Used 0.8.6 and 0.8.9 in the past OK. 0.8.9 gives me high CPU issue when used with rutorrent and XMLRP, so I tried git 0.9.0.
All this on Debian 6.

rtorrent wont start when built from git version, rtorrent error says: hash_read_ahead command not found.
I have to comment out all the following to get rtorrent to run.
#hash_read_ahead = 30
#hash_interval = 5
#hash_max_tries = 5

But now all torrents hash check, even new torrents never loaded before, even though I also still have the "check_hash = no" in the .rtorrent.rc file.

Just to be clear. Build Debian 6, install required packages, build 0.8.6 or 0.8.9 from tar and rtorrent will run with no complaints about invalid hash commands and also new torrents DON'T hash check.
Now "make clean" the libtorrent and rtorrent builds and grab from the git version 0.9.0 and remake.
Now rtorrent will not run because of the invalid hash command error.

EDIT:

OK, just seen that the hash_read_ahead is now obsolete! No idea how the guy above even got his rtorrent 0.9.0 to run!
222018e

Question still stands though. Is check_hash obsolete too? Are my new freshly loaded torrents supposed to hash check if I've set this to no?

[rakshasa]

Newly added torrents always hash checked in all versions. What seems to have broken is the hash check disabling of torrents that just completed.

This will be looked into in the next few days.

[buds]

Thanks for confirming and explaining the hash issue. I can honestly say I've never noticed any new torrents doing a hash check in the past, even now using 0.8.6 but I noticed it with the git version.

[rakshasa]

The hash checking got threaded not long ago, and it is currently not
working right for hashing whole torrents.

This should get fixed in the near future.

On 9. feb. 2012, at 22:32, buds
[email protected]
wrote:

Thanks for confirming and explaining the hash issue. I can honestly say I've never noticed any new torrents doing a hash check in the past, even now using 0.8.6 but I noticed it with the git version.

---

Reply to this email directly or view it on GitHub:
#26 (comment)

[rakshasa]

Ok, I've been testing stuff, and it seems I might have made some invalid assumptions on where the problem lies. Thus I'll need confirmation on the exact nature of the issue. So everyone who has encountered this;

Are you using rutorrent to disable the hash checking?

When does the unexpected hash checking happen; when a torrent finishes downloading, or when you add a new torrent? And if it happens when you add a new torrent, was there any files present (even if empty) or was it a completely new torrent.

How fast does the hash checking happen... E.g. 80MB/s, etc.

[hatifnatt]

For me hash checking doesn't work at all

* [OPEN]   0,0 / 5714,1 MB Rate:   0,0 /   0,0 KB Uploaded:  0,0 MB    [   R: 0,00]
* Hashing: Checking hash [ 2%]

in rutorrent hash check progress show 2.5% and any other torrents doesn't succeed with hash check.

libtorrent 0.13.0
rtorrent 0.9.0

[buds]

.rtorrent.rc has hash_check = no
BUT
From memory, the hash checking on new may have occured because there was an empty folder from a previous test, and if this is true, then my hash check report above on new torrents may be invalid.

I'll need to rebuild another server at some point this week to test this for sure. Will report back.

[rakshasa]

Can't reproduce the issue(s), so closing. Make a new ticket if the latest version shows this behavior.

[castanley]

This is still happening to me. I already downloaded before turning the checking off, now it's still checking 600GB and it is taking forever on an ARM processor. Is there something we can do to stop the checking, and continue seeding?

[PsySc0rpi0n]

I'm getting the same here. Please, let us know if is there anything wrong about this that is known to developers.
Thanks
Psy

[2knarf]

Same problem here