SABnzbd Forums

I have this problem with all versions of sab (5.x, 6beta, 6.2), that my downloads disappear after they finished downloading
they're then gone from the download-list completely

depending on the size of the download, it takes up to 1 hour, until they finally appear in the history-section (at which time the post-processing starts)


its really weird, and costs a lot of time.

is this a known issue?
why does it take so long for the download to get from the download-section to the history-section?

There *is* a delay between the job disappearing from the Queue
and it re-appearing in the History, but it should be mere seconds.
That's still a bit dissatisfying, so I will look into this.
Why it needs hours on your system, I don't know.

shypike wrote: There *is* a delay between the job disappearing from the Queue
and it re-appearing in the History, but it should be mere seconds.
That's still a bit dissatisfying, so I will look into this.
Why it needs hours on your system, I don't know.

its an atom-based windows server....

do you think its because its a relatively slow machine ?

No, on my slower box (also Atom, doing 6MBytes/sec) it takes a bit longer but not even minutes.
I will look into this.

The reason for the delay is that the job is removed from the queue
immediately after the last article is in, but only added to History *after* the last file has been assembled.
The larger the file, the longer the lost time between Queue and History is.
The effect is only visual.
What makes it so long in your case, I cannot tell.
It could be that the system is so busy downloading that it has little time to work on the file assembly.
This slowness would be pervasive and only have a visible effect on transfer from Queue to History.

I can fix the visual delay in the next release.

shypike wrote: The reason for the delay is that the job is removed from the queue
immediately after the last article is in, but only added to History *after* the last file has been assembled.
The larger the file, the longer the lost time between Queue and History is.
The effect is only visual.
What makes it so long in your case, I cannot tell.
It could be that the system is so busy downloading that it has little time to work on the file assembly.
This slowness would be pervasive and only have a visible effect on transfer from Queue to History.

I can fix the visual delay in the next release.

I see.

I used to use Newsleecher before I switched to sab a few months ago....
but the thing with Newsleecher was, that it didn't had to "assemble" the downloaded files - they are immediately available in the folder after the file has been downloaded


I'm just curious of why it works without (visible) delay on this program - but takes (relatively) long on sab

In order to support articles coming in out of order they're kept in memory
and later written to disk. It's a design choice.
Someday that might be optimized.
Newleecher is a commercial program, which on the one hand is
more efficient and polished but on the other hand hasn't reached
the hands-free automation that SABnzbd has.

I understand.

thank you for the quick responses...

and also for the little fix in the upcoming version

This still seems to be happening in 0.6.10 — I had a download finish over 12 hours ago and it's not showing in queue or history. The last log entry relating to it is 18 hours old.

The files haven't been extracted; I've taken a copy and tried manual extraction and it looks like several parts are missing, which means they should be getting downloaded but nothing's happening — SABnzbd is just proceeding with the next download.

(It is a 30Gb download on an Ion box, but there should still be some indication that SABnzbd's doing something and hasn't just thrown the download away… I sync at 2Mbit/s on a good day, so losing this really isn't an option as it took DAYS to download )

Edit: Of course, I should have thought to run ls -lart — looks like files in the __ADMIN__ folder are still being updated, so it's still processing, at least. Phew

I guess you have multiple server of which one is not responding.
Make sure the less reliable servers are marked as "optional".
SABnzbd keeps trying non-responding servers for articles that none of the other servers have.

Nope, only one server — and it's responding OK as the next item on the queue is downloading.

One way to diagnose this is to pause (per job) each item in the queue.
Then check the Status->Connections page to see if SABnzbd is still trying to get articles for the stalling item.
It could be that the server refuses to say it doesn't have some articles, but times out instead.
Not that likely, but also not impossible. Which timeout did you set for the server?

Timeout is 120 seconds, which I think is the default (at least, I don't remember changing it!)

After pausing everything (very glad you can do that from multi-ops!) there doesn't seem to be anything running for the disappeared job.

In the __ADMIN__ folder, last modification to SABnzbd_attrib and SABnzbd_nzo_9u1xde was 2 hours ago, with everything else last being modified more than a day ago. Still no sign of it in the queue or history, though.

Possibly there has been a minor queue corruption.
If the job has disappeared from the queue and the history, it should be listed
on the Status->QueueRepair page, from where you can send it back to the queue.

I did look at that page earlier, and saw a load of things that were no longer in the queue (I'd had to restore from backup after a reinstall, and unfortunately the backup program had decided to ignore all the dot files, meaning I lost the .sabnzbd directory and had to rebuild the queue from scratch) so I deleted them all.

Unfortunately I didn't see whether this file was in there or not — but it certainly isn't now.

I've just hosed myself, haven't I?

Edit: Wasn't there to be repaired individually but a queue repair restored it. Just need to put the queue back in order again. Thanks for your help