nzb file just disappears -- doesn't show up as failed nor enter download queue

[gvd]

Version: 0.6.2
OS: Ubuntu 11.04
Install-type: linux repository
Skin (if applicable): Default
Firewall Software:  dd-wrt (i.e. none on the local box)
Are you using IPV6? NO
Is the issue reproducible? sometimes


running sabnzbd 0.6.2...  Sometimes when I drop an nzb file into the watch folder, the nzb wiill neither start downloading nor show up as failed via the web interface.

If I look at the log (set to debug via the web interface), I only get a single line each time I add the nzb file:

2011-06-15 09:42:49,508::INFO::[dirscanner:311] Trying to import /mythtv/incoming/nzb_files_go_here/some_nzb_file.nzb

....and that's it.  If I re-add the file, I'll get the same thing (different time stamp, of course), but it neither starts downloading nor does it show up as failed in the log.  Other NZB files will download if I drop them in the watch for nzb folder.


However, if I click on config, I see these jobs come up as orphaned.  (Different time stamps depending on when I dropped them in the nzb folder.)  If I then click on "add" next to the orphaned job, it'll move the job to the download queue and proceed as it should normally.


This behavior is not consistent -- some (most) items that I drop in the watch folder go into downloading (or queue to download) properly.  Just certain ones (I have two examples but obviously can't post them) get orphaned immediately.

Thoughts and/or suggestions?

[shypike]

There's nothing wrong with the NZB files you sent and probably not with SABnzbd either.
They work perfectly well on Windows and Ubuntu 10.10.
Are you sure it's not a rights issue?
Do these files somehow have a different owner, group or rwx flags?
Do you have logging set to "Debug" level, that may show some more info.
BTW: 0.6.2 has been replaced with 0.6.5 now (probably doesn't matter in this case).

[gvd]

Are you sure it's not a rights issue?

Yep.  Working and non-working files have identical rights (-rw-r--r--), owners, and groups.  Worse, sometimes if I add the same file three or four times, sab will wake up and add it four times to the queue!


(Besides, if this were a permissions issue, clicking "add" next to the orphaned job shouldn't do anything as sab still wouldn't have rights.  Right?  )

Do you have logging set to "Debug" level, that may show some more info.

Is this done by clicking on status, then setting the logging dropdown to "+ Debug"?  If so, then yes.  (But again, it's not logging much.)




(Also, any jobs that were orphaned by sab go immediately to the queue upon restarting sab, I just found out.)

[gvd]

Any ideas on how I can even begin to track this issue?

Since just restarting SAB clears the logjam, definitely is pointing me in the direction of a SAB bug.  Kind of at an impasse since debug logging isn't logging anything.

[shypike]

What I do in such cases is fire up the debugger and step through the
code that handles the NZB intake.
I don't think that's an option for you.
Since you're on Unix, you must be running from sources.
If you want, I can tell you where to patch the source a bit,
so that you will see more info.
The first step would be to upgrade to 0.6.5, there have been many fixes
since 0.6.2, it might even solve your issue.

From what you tell, it isn't a rights issue anyway, because then no
orphan would result.
What is odd is that the orphan is picked up at restart. That should be a manual action.

Let me know if you're in for some assisted debugging.

[gvd]

What I do in such cases is fire up the debugger and step through the
code that handles the NZB intake.
I don't think that's an option for you.

Yeah...  if it did it on every nzb, then that'd be an option.  But it only does it maybe one out of every ten or so, so that's a lot of stepping to go through trying to catch a fish.

Since you're on Unix, you must be running from sources.
If you want, I can tell you where to patch the source a bit,
so that you will see more info.
The first step would be to upgrade to 0.6.5, there have been many fixes
since 0.6.2, it might even solve your issue.

I'm running from source, but they're being provided by a PPA (personal package archive).  Here's what I'll do...  I'll un-install the PPA (which was updated to 0.6.4, btw) and re-install from source (0.6.5), then apply your diffs.

From what you tell, it isn't a rights issue anyway, because then no orphan would result.
What is odd is that the orphan is picked up at restart. That should be a manual action.

Really?  I figured you guys read the orphans and try them on launch just for kicks.  I guess not!

Let me know if you're in for some assisted debugging.

Sure, if you're not part of the solution you're part of the problem.  I'd rather be the former than the latter.    Let me know what to change/patch and it'll be done.

[shypike]

0.6.5 contains very little compared to 0.6.4 and certainly nothing influencing this.
Don't un-install the PPA, because you might lose essential Python packages.
You can download and unpack the distribution tarbal to a folder of choice
and run it from there (just ./SABnzbd.py).

Is it a random problem or does a specific NZB trigger this behaviour every time you add it to the queue?
(That's what I guessed from your description, but I'm not sure).
Does the same thing happen if you enter the same problematic NZB through the "Add-NZB" dialog?
In other words: it the problem specific to the import folder or more general?

I have to look at the code a bit to give you further suggestions.
Cannot do that right now.

[gvd]

0.6.5 contains very little compared to 0.6.4 and certainly nothing influencing this.
Don't un-install the PPA, because you might lose essential Python packages.
You can download and unpack the distribution tarbal to a folder of choice
and run it from there (just ./SABnzbd.py).

Ahhh, good suggestion!  I did exactly as you suggested, downloading 0.6.5 but keeping the PPA for 0.6.4.  I extrated the tarball, then ran it, backgrounded it and disowned it.    It picked up its config files from my home directory A-OK, so I'm effectively running 0.6.5 now.

Is it a random problem or does a specific NZB trigger this behaviour every time you add it to the queue?

I used to think it was specific NZBs, and I saved two of them that used to cause problems, but haven't had a return of the symptom since I restarted SAB sometime last week.  (i.e. before I upgraded to 0.6.4.)

Does the same thing happen if you enter the same problematic NZB through the "Add-NZB" dialog?

Unknown at present; mainly just waiting for the problem to re-occur so I can test things out.

I have to look at the code a bit to give you further suggestions.
Cannot do that right now.

Is there anything that could be added by way of debug logging that might be helpful?

[shypike]

So far the only suggestion is this:
Open file /sabnzbd/dirscanner.py
Line 172 now says:

Code: Select all

    except:
        if data.find("<nzb") >= 0 and data.find("</nzb") < 0:

Add two lines below "except:" so that it reads:

Code: Select all

    except:
        logging.error('SUSPECT ERROR, check log')
        logging.info("Traceback: ", exc_info = True)
        if data.find("<nzb") >= 0 and data.find("</nzb") < 0:

So when you see "SUSPECT ERROR" as an error message, you can look at the track-back info in the log.
Debug log does not need to be on, but it is helpful.