SABnzbd Forums

shypike wrote:Re-reading your message gives me some thought.
NzbDrone mis-interprets what's going on in SABnzbd.
Now I don't know why that is, but can do some guesses.
Are you using folder renaming? (Config->Switches)
Other than that, did you ask this also on the NzbDrone forum?

I just checked and yes, Enable folder rename and Replace Illegal Characters in Folder Names are checked.

Yes I did and the administrator is right away pointing that the problem is sabnzbd even without any troubleshooting on their side. He did reply once on this thread.

Of course I can just as easily claim a problem with nzbDrone.
Can you set logging to "Debug" on the Status page?
Then let nzbDrone do whatever it needs to do until things fail.
Then send the log file (downloadable from the same Status page) to [email protected]
Please add the URL of this message.

shypike wrote:Of course I can just as easily claim a problem with nzbDrone.
Can you set logging to "Debug" on the Status page?
Then let nzbDrone do whatever it needs to do until things fail.
Then send the log file (downloadable from the same Status page) to [email protected]
Please add the URL of this message.

I sent it already. Take note that the logging was set to Debug already even before I posted on this thread, so the error message log that I stated here was the only thing there that was related to nzbdrone failing to delete the failed download in the history. But I still sent the sabnzbd log.

Thanks for the log, but I cannot find any API call that I can relate NzbDrone's actions.
Specifically the "mode=history&name=delete" API-call is not logged.

shypike wrote:Thanks for the log, but I cannot find any API call that I can relate NzbDrone's actions.
Specifically the "mode=history&name=delete" API-call is not logged.

Hmmm, what should I do? The log file I sent you contained one instance of the issue.

kevindd992002 wrote: Hmmm, what should I do? The log file I sent you contained one instance of the issue.

The delete actions of NzbDrone have not been recorded.
All API calls are "debug" logged and several are present, but no call is associated with deleting history elements.

shypike wrote:

kevindd992002 wrote: Hmmm, what should I do? The log file I sent you contained one instance of the issue.

The delete actions of NzbDrone have not been recorded.
All API calls are "debug" logged and several are present, but no call is associated with deleting history elements.

Does that mean I have to replicate the issue again?

kevindd992002 wrote: Does that mean I have to replicate the issue again?

That's up to you.
If it's difficult to reproduce, then it cannot be a big problem.

shypike wrote:

kevindd992002 wrote: Does that mean I have to replicate the issue again?

That's up to you.
If it's difficult to reproduce, then it cannot be a big problem.

Ok. Nope, it's actually easy to reproduce as long as I'm downloading like a set of episodes in one season of a particular series. Should I delete the current debug logs first?

SABnzbd cycles through 5 files. If you copy sabnzbd.log right after things go wrong, that should be enough.
You check it yourself by searching for name=delete

shypike wrote:SABnzbd cycles through 5 files. If you copy sabnzbd.log right after things go wrong, that should be enough.
You check it yourself by searching for name=delete

I recreated another clean sabnzbd.log and uploaded it here: https://www.dropbox.com/s/1wujtr6bf4d1e ... 281%29.log

Here's another instance of that error:

2014-06-18 10:36:44,842 ERROR: Failed to remove nzo from postproc queue (id) SABnzbd_nzo_kperf2

Again, no logging of the problem.

From what I can see in the code, it might be a time issue where
nzbDrone tries to delete the current, but failed, job just before it's been transferred to the History database.

shypike wrote:Again, no logging of the problem.

From what I can see in the code, it might be a time issue where
nzbDrone tries to delete the current, but failed, job just before it's been transferred to the History database.

I understand and it makes sense but how can I fix that?

You cannot fix it.
A short pause in nzbDrone so that it doesn't remove a job prematurely, would fix it.
Or a fix in SABnzbd that will remove the race-condition.
The latter is probably possible, but its priority on my to-do list isn't very high.
It will need to be fixed at a later date.

Guessing at what the issue could be here, I have zero proof that this is the case, but reading the thread leads me to believe its possibly the cause:

1. Download "completes" (goes from Queue to History for post proc)
2. par2 check fails
3. drone checks SAB's history and sees the failed download
4. SAB puts the item back in the queue to grab extra par2 files
5. drone attempts to delete the item from SAB's history, but it fails to delete
6. SAB logs the failure
7. drone doesn't handle the failed download

If this is happening drone could wait until the next check (60 seconds) or waiting a few before re-verifying and failing the download. This could also explain how a successful download failed (showed as failed, then completed, but drone deleted it anyways).

Queue/History related question: is there a case where SAB would change the ID of the job? Possibly when trying to return the download to the queue to find missing parts? Dealing with an issue with failed downloads where the ID seems to be changing from what was originally returned via the nzb upload to SAB from drone.