d/l get stuck at 1 MB on all d/l

[guardianx]

the problem recently start when i use version 4.5 of sab. it would stop d/l when the last file hit 1 mb or so.. and to fix this problem i would have to d/l another big file.. and  constantly switch between the 1mb file and the new big file in the que list ..

i'm using win xp.

[shypike]

Do you get timeout warnings from one or more servers?

[sander]

I've had that a few times in the past. Very strange. I couldn't find a reason or real solution. I worked around it by swapping the order of the downloads in the queue, and/or restarting PC & SAB, and/or by adding/removing servers.

Quite annoying.

[temp]

i had this 2 not all the time but at least 10 times in the last month i am using version 0.4.5 on XP and ubuntu 8.10 on both OS i have this problem
its gets stuck at around 1 MB and the speed go's to near 0 kb/s if you leave it like that it will start to download the rest again but it takes at least 5 to 15 min most of the time i worked around it by swapping the order of the downloads in the queue

[shypike]

The only thing we have been able to reproduce is this:
http://trac2.assembla.com/SABnzbd/ticket/150

Thereason is that we do not have a limited number of retries (like some other readers have).
It's  dilemma.
Either a download hangs on a stuck server (with infine retries) or you may miss articles (with limited retries).

I think we are going to implement a user-specified retry count soon.

BTW: I'm not sure that this is actually the cause of your problem.
But what I described is the only situation which we have been able to reproduce.

[sander]

shypike: I'm not sure too that that is the reason; it would be a big coincidence that only the last article(s) of a post are missing. And I can't remember that SAB was saying anything about missing articles.

I think the cause is on SAB's side and not the server side.

But let's see what happens when you implement that switch.

[shypike]

It's not necessarily the last articles, but that's the easiest case to reproduce.
The option "Only get articles for top of the queue" will have an influence too.
Enabling this will increase the chance of hangups (but decreases memory usage).

[sander]

shypike,

On http://trac2.assembla.com/SABnzbd/ticket/150 you write:

"Unlike other newsreaders we do not have a retry limit. Such a limit would solve this problem. An alternative would be to disable the server for a given amount of minutes one the retries have been used up (only possible in 0.5.0). "

Does this mean SAB keeps on trying to connecting the (failing) server, causing the stuck around 1 MB?

If so, I should be able to verify this hypothesis by using tcpdump / ethereal / wireshark: it should see SAB's outgoing NNTP connection and the server's reaction (if any), right?

[shypike]

Yes, that's the problem.
Normally it tries every server until it gets the article.
When a server says is doesn't have it, SABnzbd goes to the next one.
If the last server stays silent, SABnzbd keeps retrying forever (hoping the server will
come back). As soon as it gets an article-not-found response, it's OK.

Yes, you would be able to see it.
Instead of ethereal one could add extra debug-logging.

I know it's a real problem, but:
a) It's not an easy fix
b) I don't know if it solves the problems described earlier.

[sander]

I know it's a real problem, but:
a) It's not an easy fix
b) I don't know if it solves the problems described earlier.

I know. Let's together find out what's going on. My first step will be to wait for the stuck to happen and then watch "tail -f ~/.sabnzbd/logs/sabnzbd.log".

And thank you for SABnzbd and all your work.

[sander]

Another hypothesis: it could be something in the par2 downloading process. I see that that takes a lot of time at the end of the download ("0.49/4821.17 MB") and the download speed drops. So the behavior looks the same.

Now just find what exactly could be going wrong. ;-) Maybe it's just some SAB internal par2 unpacking that stops ...

Just a thought.