I can extract them manually fine. I'll re-enable the plugin and try to get some more info on exactly what it (isn't) doing...

Under Fedora 13 (and Deluge 1.3.0), the extractor plugin launches a rar process, which then hangs at 100% CPU eternally...Anyone know why and/or how to fix?

It doesn't work...Deluge itself looks good, but still getting connection reset by peer errors...

Would the git pull of libtorrent (when I got it on 04/30) have included the latest patch that was mentioned?

Just compiled the latest dev build with libtorrent, both pulled through GIT, so testing in progress!

Everything looks good so far, at least where deluge is concerned. No missing torrents or blocklist problems, like I was having the last time I tested...

Excellent! I'll try to get it all compiled today and let ya know...

And now I see this... Thanks for the report! Here's a patch that I believe will fix this: Index: src/torrent.cpp =================================================================== --- src/torrent.cpp (revision 4490) +++ src/torrent.cpp (working copy) @@ -5179,14 +5179,14 @@ if (i->is_working()) { t...

That sounds mostly like the problem, although the particular tracker I use most often seems highly stable, which is contrary to the amount of reset by peer errors I was seeing...Whether it is the bug as reported, or it is creating its own reset by peer error somehow, the problem does seem to lie in ...

1.2.3 with libtorrent 0.14.10 (both via Fedora koji rpm packages) seems to be working...

So...Either a problem with libtorrent 0.15 and/or however it is compiling on my system...

I see this with the 1.2.3 release as well...

That may be...

BTW, elysian, if you roll back to 1.2.3 things work fine...That's what I did, at least for the duration of the dev build being rather jacked up (there are some other issues with it to, like blocklisting not working beyond the initial load)...