Stalled Download

Also known as: stuck queue, hung download

A queue that stops advancing while connections stay open, usually because the remaining segments all return 430 and the client keeps retrying instead of failing the file. Other causes are a full destination volume, a post-processing script waiting on something, and an oversized retry setting. Checking whether any connection is still moving bytes separates a dead release from a client stuck on its own logic.

A stall and a slow transfer are separate faults, and the difference shows in the byte counter rather than in the speed reading. A slow job still advances, just gradually. A stalled job stops advancing while the client continues to report its connections as connected, because a TCP session waiting on a response that will never arrive looks identical to a healthy one from the client's status panel.

Confirming the stall is real

Several clients average throughput over a window long enough that a job which dropped to zero a moment ago still displays a plausible figure. The dependable check is the downloaded total on the job itself: reading it, waiting sixty seconds, and reading it again. If the figure has not moved, nothing is arriving. Worth watching at the same time is the article counter. A queue burning through failed articles quickly is not stalled, it is failing fast, and it will reach the end of the file and hand it to repair without intervention.

Where the queue is actually stuck

Almost every stall is decided on the local machine rather than at the provider, and there are four usual places for it to happen.

Dead connections. Sessions dropped silently by a router, a firewall state table, or the server, which the client has not yet timed out. Each one holds a slot that a working connection could be using.
An article the client will not abandon. With retries set high, or a long chain of servers to walk before giving up, a single absent segment can occupy a connection for many minutes.
A blocked post-processing step. A repair, an unpack, or a user script running on another job holds the queue while the download side sits idle. Some clients serialize this deliberately.
Nowhere to write. A destination volume with no free space stops the writer, and the resulting message is usually a generic write error rather than anything mentioning space.

Clearing it without losing progress

Pausing and resuming the queue is the cheapest first action, since most clients tear down and rebuild their connections on resume and dispose of dead sessions in the process. If the job runs briefly and then freezes at the same point again, the articles rather than the connections are responsible. Restarting the client does the same thing more bluntly. Neither loses completed work: the incomplete folder retains what has already arrived and the job continues from there. Deleting and re-adding the .nzb does discard that work, and is rarely necessary.

Stalls that are not faults

A job sitting at zero while a different job runs .par2 verification is behaving exactly as designed. So is a pause of a few seconds between files. A release whose remaining articles are simply absent from the spool will always end in a run of failures rather than in movement, and where those failures exceed what the recovery blocks can cover, a second source on a different backbone is the only technical remedy. None of those situations calls for a change of setting.

Frequently asked questions

Why is my nzb download stuck at 0 B/s but still connected?

Because an open connection and a moving connection are not the same thing. Sessions dropped by a router or by the server remain listed as connected until the client's read timeout expires, so the panel looks healthy while nothing arrives. Pausing and resuming the queue forces those sessions to be rebuilt, and movement usually returns within seconds.

Is a stalled usenet download the provider's fault?

Usually not. Most stalls come from dead connections the client has not timed out, a retry setting keeping one article alive far too long, a full destination volume, or post-processing blocking the queue. The provider is implicated only when the remaining articles are missing from its spool, and that presents as fast failures rather than as a frozen counter.

What is the difference between a stalled download and a slow download?

A slow download still advances: the completed size climbs, just below the expected rate. A stalled download stops advancing entirely. The test is to note the job's downloaded total, wait a minute, and compare. Slow points at connection count, processor load, or disk contention. Stalled points at connections, retries, or a blocked queue.

Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.