Stalled and stuck transfers
Stalled in a BitTorrent client means the torrent is running and connected but no piece has arrived recently, which in almost every case means nobody in the swarm is currently sending.
It is a waiting state, not an error state. The client has not crashed, the torrent is not corrupt, and nothing needs repairing. qBittorrent shows it as stalled, other clients use words like idle or waiting, and all of them mean the same thing: everything is in place except a peer with the data.
Stalled: connected, and waiting for a piece nobody is sending
A stalled torrent is one the client is still actively working on. It is announcing to the tracker, it is asking the DHT for peers, it holds whatever connections it has, and the moment a peer with a piece you need unchokes you the figure starts moving again without any action from you. Four situations produce it:
- No seeder is online and the leechers between them do not hold the missing pieces, which shows as an availability figure below 1.000.
- Every peer you can reach is already choking you, common on a busy torrent with one slow seeder and many leechers.
- Your client is firewalled, so it has no incoming connections and can only trade with peers it dialed itself. On a thin swarm that can leave it with nobody.
- The torrent is simply old, and the swarm has gone. This is the ordinary end of most torrents and no setting brings it back.
A torrent that shows queued rather than stalled is a different case entirely: it has not started. Most clients limit how many torrents run at once, and the rest wait in line. Raising that limit, or moving the torrent to the top of the queue, starts it immediately.
Downloading metadata: what a magnet link is waiting for
Downloading metadata means the client has a magnet link but not yet the torrent's own description of itself, and it is asking the swarm for it. A magnet link carries an info hash, an identifier, and little else. Before a single piece can be requested, the client has to obtain the file list, the piece length and the piece hashes, and it gets them from a peer that already has them. That requires finding a peer first, through the DHT or through any trackers named in the link, which takes tens of seconds on a live torrent and forever on a dead one.
A stage that sits on downloading metadata for a long time usually means the info hash has no swarm left, or that the DHT is unreachable on that network. Two checks separate those: confirm that DHT and peer exchange are enabled in the client's settings, and confirm the client is not offline, since a client that has reached no tracker at all reports that separately. Adding the same content from a torrent file instead of a magnet link skips this stage completely, because the metadata is inside the file already.
Checking resume data, and why it appears after a crash
Checking resume data means the client is comparing what is on the disk against the piece hashes in the torrent, and it is a read operation over data you already have. Clients keep a small record of which pieces were verified so they do not need to do this every time. When that record is missing, stale, or cannot be trusted, the client rebuilds it by hashing the files again.
It appears after a power cut or a forced quit, after moving files to a new location, after adding a torrent whose data is already on disk, and after a manual force recheck. On a large torrent it can take a long time and it is limited by how fast the disk reads, not by the network, so the transfer sits at 0 B/s throughout. A torrent whose files are all present and correct comes out of the check at 100% and goes straight to seeding. Interrupting it only means it starts over.
Errored, and what the message under it is telling you
Errored is the one state in this group that is genuinely broken, and it is almost always about storage rather than the internet. The message the client shows comes from the layer that writes files, so it names a problem the operating system reported: a folder that no longer exists because an external drive was unplugged or a network share went away, a volume mounted read only, a disk with no space left, or a file the operating system will not let the client write because of permissions or because another program is holding it open.
| State | What it means | What to look at first |
|---|---|---|
| Stalled | Connected, nothing arriving right now | Seeds, peers and availability for that torrent |
| Queued | Not started, waiting behind other torrents | The client's limit on active torrents |
| Downloading metadata | Has a magnet link, still looking for the torrent's description | Whether DHT is enabled and whether the swarm still exists |
| Checking resume data | Verifying existing files against the piece hashes | Nothing. Let it finish. It is limited by disk speed |
| Errored | The client cannot read or write the files | The save path, the drive, free space and permissions |
| Firewalled, in the status bar | No incoming connections reach the client | The listening port and the forwarding rule |
Fixing an errored torrent is usually a matter of restoring what moved: reconnect the drive, recreate or reselect the save location, free space, then use the client's option to set a new location and force a recheck so it reconciles the files it finds with the pieces it expected.
What to check first, in order
- Read the state word itself, since stalled, queued, errored and checking have nothing in common and each has its own cause.
- Open the trackers tab for that torrent and see whether the announces are working or reporting a failure.
- Read the availability figure, because below 1.000 the transfer cannot finish no matter what else is adjusted.
- Check the connection status in the status bar, since a firewalled client sees a smaller swarm than exists.
- Confirm the save path is reachable and the disk has room, which resolves nearly every errored torrent.
- Leave it running, because a stalled torrent costs nothing to keep open and resumes by itself when a seeder returns.
Where a torrent is moving but slowly rather than stopped, this is not the page for it: Why a transfer is slow works through the swarm, the connection, the client and the line in order.
Whether Deluge would behave differently from qBittorrent
Deluge and qBittorrent behave the same way on a stalled torrent, because both are built on libtorrent, the same underlying engine, and it is libtorrent that decides when a torrent is waiting, checking or errored. What differs is the vocabulary on screen and where the detail is shown. Deluge separates its interface from a background daemon, so it can keep transfers running with no window open at all, and its state labels do not always use the same words. Switching between them does not restart a stalled transfer, and a torrent moved from one to the other keeps the same info hash and rejoins the same swarm.
One genuine exception to a swarm having nothing to give: some torrents name an ordinary web address inside the torrent itself, a web seed, and a client that supports it can fetch pieces over HTTP when no peer is sending. The Internet Archive publishes torrents for its items, and material that has been quiet for years often remains retrievable that way long after the peers have gone. How a transfer works and The swarm cover the two mechanisms this page keeps pointing at: how a piece is requested, and who is there to answer.