hellanzb hangs after transfering - doesn't unrar or move to done

I'm having the same problem here. It hangs after "transferred". I tried disabling the unrar option and the smart par option, but that didn't have any effect.

I found a bug report on hellanzb's website that describes the same bug:
http://hellanzb.com/trac/hellanzb/ticket/429

One of the comments links to another bug report of the similar issue:
http://hellanzb.com/trac/hellanzb/ticket/429

In the comments to that bug report, they find that if the nzb file fed to hellanzb includes an nzb file, hellanzb will hang after downloading everything. I have confirmed that this is the case. In all the nzb files that hang after transfer, an nzb file was also downloaded.

I upgraded to Jaunty a couple days ago and now I have everything setup I started to download a few things. I promptly encountered the problem with Hellanzb hanging after downloading.

Its happened a few times now today and in all cases so far there was an nzb file in the working folder of Hellanzb (daemon.working I think)

This is really a problem and renders Hellanzb almost useless to me, but I really do not want to use anything else, its always served me so well.

This exact problem is happening to me also since I upgraded to Jaunty.

Note I also downgraded from what shipped with Jaunty: 0.13-3ubuntu4 to version 0.13-3 (from Hardy) which was running perfectly fine for me forever to see if this problem would go away and it has not.

I have made a temporary (I hope it is) workaround for this by adding a cron job to simply remove any nzb files from the working directory every 5minutes like so:

*/5 * * * * rm -f /mnt/store/hella/daemon.working/*.nzb* > /dev/null 2>&1

Adjust "/mnt/store/hella/daemon.working/" wo your working directory, most likely a simple path change. Speed of your internet may require a tweak of the timing, if you have 100mbit then 5minutes might be too long ;)

Is Hella in development still as this seems like it should be something trivial to fix.

I can confirm this bug. Though it does not only occur for me in Jaunty, the same does occur in Intrepid. It does seem as if it should be quite trivial to fix. I assume a simple logical check for .nzb extensions would more than suffice. As for if Hellnzb is still in development, the current release in 0.13 though their is a 0.14 trunk in the source tree.

Somebody posted a temporary fix as a comment to this bug report:
http://hellanzb.com/trac/hellanzb/ticket/425

Here is the comment:
http://hellanzb.com/trac/hellanzb/ticket/425#comment:6

The fix has hellanzb delete any nzb files downloaded before beginning the post processing.

Attached is a patch to implement the workaround listed at:

http://hellanzb.com/trac/hellanzb/ticket/425#comment:6

Also I have applied this fix in my PPA:

deb http://ppa.launchpad.net/res0nat0r/ppa/ubuntu jaunty main

After a lot of testing with hellanzb and LottaNZB, I found the reason why this is happening. The problem is that IF the downloaded NZB file (from for example newzbin) contains an entry with a NZB file which has exactly the same name as the download NZB file, it will fail. At the end of this post I made 2 sample files which are pretty self-explanatory. I'll continue using those examples.

File A fails, File B doesn't. This is because File A contains entry File A.3 (a NZB file with exactly the same name as the NZB file in the queue). I discovered this while testing with LottaNZB. If you add a NZB file (in this example File A) via the 'Add file' dialog in LottaNZB it makes the name pretty. This is what it does; File A.1 "ubuntu-9.10-desktop-amd64/" ---> "ubuntu 9.10 desktop amd64/". File A.3 stays the same and because the File A.1 and File A.3 aren't the same anymore, it works as intended. However adding the file via 'file associations' or the command line doesn't make the name prettier File A.1 and File A.3 stay the same and it will fail. This is a workaround for this bug which happened to be in our code without knowing it. Another workaround would be to remove File A.3 from File A when the NZB file is added to LottaNZB, which makes it File B. And then pass it to hellanzb. Both work, and Severin already implemented the second workaround so for our LottaNZB users it should be fixed (or worked around) in LottaNZB 0.5.2 which will be released in the near future.

However, workarounds aren't good practice. But because a fixed hellanzb package won't be in Ubuntu until Ubuntu 10.04 we decided to implement the workaround first. Next we're going to give it a try to fix the actual hellanzb package, and get the patched package into Debian and therefore in Ubuntu (10.04).

File A:
-------
1. ubuntu-9.10-desktop-amd64.nzb (NZB file)
2. |--> ubuntu-9.10-desktop-amd64.iso (file embedded in the NZB file)
3. |--> ubuntu-9.10-desktop-amd64.nzb (file embedded in the NZB file)
-------

File B:
-------
1. ubuntu-9.10-desktop-amd64.nzb (NZB file)
2. |--> ubuntu-9.10-desktop-amd64.iso (file embeeded in the NZB file)
-------

I have written a patch for hellanzb to fix this bug. Severin is taking care of getting it into Debian, etc. If all goes well, it should be available in Ubuntu 10.4.

I have posted two patches, source_fix_postprocessing_bug.patch and local_fix_postprocessing_bug.patch. The latter you can apply to an already installed hellanzb package.
Apply it with 'sudo patch -p0 < local_fix_postprocessing_bug.patch'.

Thanks Marcel for creating these patches.

There is a small error in the local_fix patch: a missing ")" before the ":" at the end of the line.

Thanks Rick, they both have the same typo... I've edited them and reuploaded.

The fixed package has landed in Debian Unstable. Thank you Severin! I've marked hellanzb (Ubuntu) as Fix Committed.

narada@ubuntu:~/Downloads$ sudo patch -p0 < local_fix_postprocessing_bug.patch
patching file /usr/share/python-support/hellanzb/Hellanzb/Daemon.py
Hunk #1 FAILED at 353.
1 out of 1 hunk FAILED -- saving rejects to file /usr/share/python-support/hellanzb/Hellanzb/Daemon.py.rej

is this what is supposed to happen?

Hi Narada2XK,

this is not supposed to happen. The patch probably interferes with other patches that have been applied to Daemon.py in the Debian/Ubuntu package.

I suggest you to install the HellaNZB package built for the upcoming Ubuntu 10.04, as it already contains this patch as well as other bug fixes. It should be possible to install it on Ubuntu 9.10 without any problems.

Forgot the link: https://edge.launchpad.net/ubuntu/+archive/primary/+files/hellanzb_0.13-5.4_all.deb

I've tried this patch after several months of hellanzb just hanging, repeating downloading the same article over and over. The behaviour I'm seeing in 9.10 with this patch is now the same article is only redownloaded if the previous attempt failed (although I dont see any errors on the console, I just see partial download of .rar files). It then just sits there, and doesn't pick up the next nzb file.

If I restart hellanzb it will resume downloading the unsuccessful attempt (renamed_0 appended) and may succeed. Then it moves to the next .nzb. The behaviour is better, but not like it used to be in 9.04 or earlier. At best its burning up more bandwidth than necessary with failed attempts to download a .nzb and obviously then hangs/waits for something indefinitely until I kick it again (Ctrl-C restart it).

Let me know if there are logs I can collect, its fairly consistently hanging up when it thinks its downloaded an .nzb file and doesn't move to the next even though it lists the ones its found in daemon.queue.

I just want to add that I think I am seeing the same behaviour described by Michael Cook above in post #22.

Certainly things are a lot better now, but there is something still amiss by the looks of it.

Because the hellanzb project is pretty much dead, such bugs won't be fixed anymore. The patch I wrote did fix the behavior I had on my machine with the .nzb files a got from some of the reporters here. However, as the hellanzb project is dead and we are focusing on LottaNZB 0.6 (which has SABnzbd as it's backend instead of hellanzb), we aren't going to devote our time to fixing bugs in hellanzb or any other project we don't depend on anymore. If you decide to not switch to LottaNZB 0.6 and stay with LottaNZB 0.5.x (thus hellanzb), your best bet is to fork hellanzb and fix the remaining bugs. Perhaps, if that happens we could port the LottaNZB 0.5.x to that fork (if the fork hasn't overcome huge changes) to somewhat support our users that insist on using hellanzb.

You can also read about the migration to SABnzbd on our website,
http://www.lottanzb.org/2009/06/thoughts-about-the-future-of-lottanzb/

Id like to note that the patch posted in post #17 by Mr. Marcel de Vries, does not seem to work. In fact, it forced every download to the stalled state, where it just says "Transferred 1641.1MB in 7m 49s at 3578.2KB/s ("file")". Since Mr. de Vries will no longer be working on the project, another patch needs to be made. It would seem easier to just delete all *.nzb files, rather than dealing with them.

Following on from #22 after the initial issue of stuck .nzbs in the queue I have found in general the downloading of individual nzbs works most of the time. The client doesn't get stuck downloading the same nzb over and over. Instead, it will defer many times and eventually return to them once the 'current' one found in the queue is completed. It does still hang, not proceeding to the next in the queue occasionally. Restarting it usually resolved the issue. I find multiple-file selections say through newzbin into one nzb rarely works first time and 50-50 whether the same nzb will work the second time. Creating individual nzbs for each file to be downloaded is the most successful although laborious. Again, this is all 'recent' as two years ago (pre-jaunty) I had no problems with hellanzb.

The fix in comment #10 and the patch in comment #11 do the same thing vhp is suggesting. I have no idea if that fix even works or not. But it is worth the shot.

vhp, I never 'worked' on the hellanzb project. I just wrote a fix that resolved the reported issues (on my machine though).