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

Bug #381318 reported by Menachem Shapiro
62
This bug affects 11 people
Affects Status Importance Assigned to Milestone
LottaNZB
Fix Released
Medium
Severin H
hellanzb
Fix Released
Unknown
hellanzb (Debian)
Fix Released
Unknown
hellanzb (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: hellanzb

I am running jaunty with hellanzb version 0.13-3ubuntu4

Every once in a while, I will have an nzb that just hangs after transfering files are complete. Hellanzb doesn't unrar the file or move the files to the done folder without doing anything. It just sits there saying "Transfered...etc." The files themselves stay in the daemon.processing/ folder until I do something with them manually. If I Ctrl-C to exit hellanzb and then restart it, it starts the download over again (probably because the nzb file is still in the daemon.current/ folder)

This doesn't happen with every nzb, but I am able to reproduce it with specific nzb files.

Here is some informtation about the latest file I was able to get it with:
I got the nzb file from here: http://www.tvnzb.com/nzb/21713

Here is the output of "hellanzb status":
-----------------------------------------------------
Queued: 410.8MB
Skipping pars.. (Skipped par2: the.unusuals.s01e07.hdtv.xvid-2hd.vol00+01.par2 (
1MB))
Skipped pars: 7 files, 39.7MB (actual skipped: 37.1MB)
 sample-the.unusuals.s01e07.hdtv.xvid-2hd.avi.vol0+1.par2 (1 files, 1.1MB, 1 blo
cks)
 the.unusuals.s01e07.hdtv.xvid-2hd.vol00+01.par2 ->
 the.unusuals.s01e07.hdtv.xvid-2hd.vol20+14.par2 (6 files, 38.6MB, 34 blocks)
Transferred 376.0MB in 6m 6s at 1050.3KB/s (The.Unusuals.S01E07.HDTV.XviD-2HD)

Downloading: None

Processing: None
Queued: None
-----------------------------------------------------

I will attach my hellanzb.conf, as well as a log and debug log of the process. Please let me know if you need anything more.

Revision history for this message
Menachem Shapiro (menachem) wrote :
Revision history for this message
Menachem Shapiro (menachem) wrote :
Revision history for this message
Menachem Shapiro (menachem) wrote :
Revision history for this message
Leon (leonbo) wrote :

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.

Revision history for this message
Menachem Shapiro (menachem) wrote :

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.

Revision history for this message
SubBASS (subbass) wrote :

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.

Revision history for this message
Stefhen (res0nat0r) wrote :

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.

Revision history for this message
SubBASS (subbass) wrote :

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.

Revision history for this message
vhp (vhp) wrote :

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.

Revision history for this message
Menachem Shapiro (menachem) wrote :

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.

Revision history for this message
Stefhen (res0nat0r) wrote :

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

Changed in hellanzb (Ubuntu):
status: New → Confirmed
Changed in hellanzb:
status: Unknown → New
Changed in lottanzb:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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)
-------

Severin H (severinh)
Changed in lottanzb:
status: Confirmed → Fix Committed
assignee: nobody → Severin Heiniger (lantash)
milestone: none → 0.5.2
Changed in hellanzb (Ubuntu):
assignee: nobody → Marcel de Vries (carresmd)
status: Confirmed → In Progress
Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :
Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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'.

Changed in hellanzb (Debian):
status: Unknown → New
Revision history for this message
Rick Nas (rick-nas) wrote :

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.

Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :
Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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

Changed in hellanzb (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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

Changed in hellanzb (Debian):
status: New → Fix Released
Severin H (severinh)
Changed in lottanzb:
status: Fix Committed → Fix Released
Severin H (severinh)
Changed in hellanzb (Ubuntu):
status: Fix Committed → Fix Released
Changed in hellanzb:
status: New → Fix Released
Revision history for this message
Narada2XK (narada2xk) wrote :

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?

Revision history for this message
Severin H (severinh) wrote :

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.

Revision history for this message
Severin H (severinh) wrote :
Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

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.

Revision history for this message
SubBASS (subbass) wrote :

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.

Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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/

Changed in hellanzb (Ubuntu):
status: Fix Released → Fix Committed
Severin H (severinh)
Changed in hellanzb (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
vhp (vhp) wrote :

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.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

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.

Revision history for this message
Marcel de Vries (carresmd-deactivatedaccount) wrote :

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).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.