rTorrent + ruTorrent application shutdown

[Cabalo]

Hi there.
I'm using rtorrent 0.8.6 + rutorrent 0.12.6 on Ubuntu 10.04 x64.
I have manually compiled rtorrent, and ran it via sudo on a terminal to verify what was going on.
rtorrent suddenly exits with this DownloadList::confirm_finished(...) download->resume_flags() != ~uint32_t() message.

At rTorrent's ticket system, this has been a known bug for around 3 years, and not much has been done about this.
I've tweaked the ulimit and the max number of open handles, but nothing fixes this mofo.
Just wondering does any of you know a solution for this ? Otherwise, I'm going to ditch it, which is a pitty as it's web interface is by far the best of all clients.

By the way, after thoroughly checking it, I must say it's buggy like fuck. And has some very nasty bugs.

[Thelen]

Ah, interesting. I may have an idea what is causing that, but not sure how to fix. That resume flags bit may be due to hash checking, I'd have to check your config.

[Cabalo]

It is. It happens whenever it's hash checking some file and then suddenly a file arrives.
It's documented here: http://libtorrent.rakshasa.no/ticket/1292

[executioner]

add this to your rtorrent.rc:

check_hash = no

I know its not a fix but may help you get around it.

Also you could try clearing out the session directory of rtorrent

[Cabalo]

Will try it, thanks for the help!

[seeder22]

i can tell you setting hash check to no did NOT fix my custom vps install of ru + rtorrent.

a while back i had a chat with a rapidpeer support guy and he said that they (rapidpeer) paid the rtorrent developer to directly address this hash check rtorrent crash issue as it was a big problem for support and all their users.


He didn't elaborate beyond saying among other things the fix, fixed, it made it so that a file was only hash checked ONE TIME, this helped when rtorrent is restarted it doesn't keep running through all your files hash checking and killing your disk IO. i could even see where if it does not hash check all you have to do is run a cron to keep restart rtorrent, peers and seeds will reconnect quickly and restarting rtorrent is transparent to rutorrent.


maybe email them (rapidpeer), im sure they will help you out as they advertise here on FST

[Cabalo]

Seems like an idea. It did not solve my problem either, so I ditched it.
The fact is rutorrent is by a long shot the best webui around, and I miss some of its features. I can only imagine the nightmare it must be for seedbox providers when they supply such a buggy client like rtorrent indeed is.

[Thelen]

Yea it is a nightmare, even more so when the users are too dumb to realise what certain problems are. IE, going over quota and wondering why rtorrent won't restart, etc.

[eroWIN]

Out of curiosity, did you compile from a the stable tarball, or from svn?

The 0.8.6 tarball doesn't have the fix (well, bodge)



if (download->resume_flags() != ~uint32_t())
throw torrent::internal_error("DownloadList::confirm_finished(...) download->resume_flags() != ~uint32_t().");

if (!download->is_active() && rpc::call_command_value("d.get_state", rpc::make_target(download)) == 1)

Was changed in revision 1161 to


download->set_resume_flags(~uint32_t());

if (!download->is_active() && rpc::call_command_value("d.state", rpc::make_target(download)) == 1)

Easiest way should be to grab the svn build, or see if the 0.8.7 tarball will suit your needs, else change that file, and recompile

[Cabalo]

Out of curiosity, did you compile from a the stable tarball, or from svn?

The 0.8.6 tarball doesn't have the fix (well, bodge)



Was changed in revision 1161 to


download->set_resume_flags(~uint32_t());

if (!download->is_active() && rpc::call_command_value("d.state", rpc::make_target(download)) == 1)

Easiest way should be to grab the svn build, or see if the 0.8.7 tarball will suit your needs, else change that file, and recompile
I compiled the stable 0.8.6 tarball.
Didn't know about that fix, that was very helpful. I will edit that file and recompile.
Do you know if that's a definitive fix for the problem?

[Thelen]

There is a new 0.8.7 release (unstable) which is most of the recent SVN, however we've been trialing the SVN versions for a while without much/any improvement.

[Cabalo]

There is a new 0.8.7 release (unstable) which is most of the recent SVN, however we've been trialing the SVN versions for a while without much/any improvement.
No improvement on this specific issue, or are you talking about other bugs ?

[Thelen]

Yea other bugs, though looking at the change eroWIN posted I don't expect it will fix your problem, since the change seems purely architectural.

[Cabalo]

on 0.12.7:


Better handling of resume after crash/reboot alliviating the need to
full hash checks. Sponsored by anonymous source.

Is this just the fix eroWIN posted, or is there something new? I haven't yet compiled the new version, so I don't know.

[Thelen]

No idea, eroWIN might have found what he posted by looking at the code, or from somewhere else, or maybe indeed he submitted it. But, the .7 was released before he made that post I think.

Anyway, we haven't noticed much difference :S