0.7.0 Post-Processing/Fetching Loops and Fails

[bortonej]

Version: 0.7.0
OS: Windows 7 x64
Install-type: Windows Installer
Skin: Plush
Firewall Software: ESET
Are you using IPV6? No
Is the issue reproducible? Yes

post processing/fetching loops, fails and continuouly stops all other downloads. Switched back to 0.6.15 and all is back to normal.

[shypike]

One specific NZB or several?
If a specific one, can you email it to bugs@sabnzbd.org ?

[pkruithof]

I can confirm this. When upgrading to 0.7.0 this morning, none of my downloads completed normally. They always seem to hang when extra blocks are being fetched. No par's are being downloaded and the queue continues with the next download, leaving the incomplete one showing "fetching extra blocks". After that I also can't remove them from my queue (they keep re-appearing).

Screenshots:


The green row is not changing...the bottom row (the 17,6 GB download) is actually downloading.


This row also doesn't change.


OS: OS X Lion
Browser: Safari
Skin: smpl-white

[shypike]

They always seem to hang when extra blocks are being fetched. No par's are being downloaded and the queue continues with the next download, leaving the incomplete one showing "fetching extra blocks". After that I also can't remove them from my queue (they keep re-appearing).

I'm investigating this currently.
It's not a general phenomenon and only occurs in some situations (which may very well have happened to you).

Work-around: set the priority of a stalled item to "Stop".
I suspect that the par2 files have been downloaded but that SABnzbd is still waiting for something.

[stgarf]

I'm currently experiencing the same issue...

Version: 0.7.0
OS: Win7 Pro
Install-type: Windows Zip
Skin (if applicable): N/A (AFAIK)
Firewall Software: N/A
Are you using IPV6? no
Is the issue reproducible? yes

EDIT: Also, the suggested workaround of setting the download to "stop" doesn't work; It's just set back to "Force" automatically.
FWIW, quitting and restarted SAB seems to have cleared this download from it's stuck state, however, it's also not downloaded.

[shypike]

Will be fixed by 0.7.1 this week.

[pkruithof]

0.7.1 seems to fix the problem, thanks!

[kr0ll0]

Hi, I believe I'm experiencing the same (or a similar) issue.

Version: 0.7.2
OS: Win7 x64 Pro
Install-type: Windows Installer
Skin: Plush
Reproducible? Unknown
Download Priority: Forced
Post-Processing: +Delete

When issue was noticed, main articles were complete and there were 4 identically named tasks fetching extra blocks, download speed = nil. Did manual check of par2, missing 2 blocks. Messed around with the interface for a few minutes trying to get things moving, no luck. After a restart of sabnzbd, a pop-up showing extraction failed due to lack of disk space was displayed, but extra queue items still present. Re-checked with par2, now missing 32 blocks (may be due to lack of space but how can it attempt extraction if not enough space to repair?). At this point I set the extra queue items to priority "Stop", but 3 of the 5 (an extra one was created at some point) could not be affected in any way. Shutdown and manually deleted all related files.

[shypike]

may be due to lack of space but how can it attempt extraction if not enough space to repair?

Both par2 verification/repair and extraction are done by external utilities, over which we have little control.
For the "temporary download folder" you can set a minimum free space, below which downloading will be stopped.
Any running repair job will continue.
So make sure you set a safe threshold.
The final destination drive is not guarded, but any failed unpack can easily be retried from the history.

[kr0ll0]

The free disk space option is set, and in this example the queue was paused - only the items set to Forced priority, of which there were 2, were active. The issue that I have is that where the files were ~98% complete when I first checked them, but after restarting sabnzbd and letting it do its thing almost a third of that data somehow disappeared... I don't understand how it ended up trying to extract it since the par2 repair obviously failed. Anyway, I reverted to 0.7.1 and ran the same job, no issues this time (albeit there was sufficient disk space to complete all stages and I enabled the "Pause queue during post-processing" switch to prevent other jobs from using space needed while repairing/extracting.

[shypike]

Very strange.
There are no changes in 0.7.2 compared to 0.7.1 that can explain the difference,
so I doubt that it's a 0.7.2-specific problem.

[kr0ll0]

Indeed. I'm not aware if there was a need to fetch blocks the 2nd time around, but if you tell me how that's written in the log file I'll see what I can find.

[shypike]

That so much data "disappeared" may be explainable when many files were "almost" complete.
Normally that doesn't happen, but sometimes it does.
If at that moment the disk is full, SABnzbd can neither dump its article cache,
nor can it save its internal admin. This could end in significant data loss,
especially if SABnzbd is shut down in that situation.

I see that you had "forced" entries in the queue.
The bad thing is that "forced" will override the pause-because-of-almost-full disk condition.
Consider that to be a design error.
I'll see what I can do about that.

[kr0ll0]

My cache is set to 200MB, while the 32 block PAR2 file is only about 72MB... I suppose there could be data from other downloads present in the cache however, so that could very well explain it.

As for the Forced entries I'm all in favor of the current behavior - actually I'm counting on it. My threshold keeps enough space to grab and extract one or two important downloads, while the other stuff gets paused until I clean up. So if you're intent on changing that, I'd like to vote that it be an option rather than a "fix".

[shypike]

My threshold keeps enough space to grab and extract one or two important downloads,

Apparently not this time
The threshold works optimally when you have separate drives for "incomplete" and "complete".