Seeding
Seeding in torrenting is what a BitTorrent client does after the progress bar fills: it keeps the torrent open and uploads verified pieces to peers who still need them, while taking nothing back.
A transfer has two halves, and seeding is the second one. Downloading ends when the last piece verifies. Seeding ends when you decide it does, or when a limit you set in the client decides for you.
What the client is doing after the download finishes
After the download finishes, the client stops requesting pieces and starts answering requests only. Nothing about the files on your disk changes. The client keeps the torrent in its list, keeps its connections to the tracker and the DHT alive, keeps announcing that it holds a complete copy, and hands out whichever pieces the peers that reach it ask for. Your machine has become one of the seeders that everybody else in the swarm counts.
That is the entire mechanism, and it explains the two things newcomers find strange about seeding. The progress bar reads 100% and stays there, and the transfer never shows a finish time, because there is nothing left to finish. And the upload speed is not yours to set: it is demand, and demand comes from other people. How a transfer works covers the request and response cycle underneath this.
Why a seeding torrent often shows almost no speed
A seeding torrent shows almost no speed most of the time because nobody is asking it for anything. Upload happens only when a peer that lacks a piece connects, gets unchoked, and requests it. Four situations produce a seeding transfer that sits at zero for hours:
- Every other peer already has the data, which is normal on an old torrent with several seeders and no leechers left.
- Nobody can reach you, because your client is firewalled. It has no incoming connections, so only peers you connected to first can ever ask you for a piece.
- Other seeders are faster, closer or better connected, and the leechers are getting their pieces there.
- Your own upload rate is capped, either by a setting in the client or by the upstream capacity your line actually has, which on most home connections is a fraction of the downstream figure.
A seeding rate of zero is a waiting state, not an error state. The distinction matters, because a client that is genuinely stuck says so with a different word, and no amount of restarting changes a swarm that simply does not need what you have.
Super seeding, and the narrow case it is for
Super seeding is a mode for one situation only: you are the very first seeder of a brand new torrent, and no complete copy exists anywhere else. In normal seeding the client hands out whatever is requested, which means an early leecher can take the same popular pieces several peers already have. In super seeding the client pretends to hold only one piece at a time, gives that piece to a peer, waits until it sees the piece has been passed on, and only then offers a different one to somebody else.
The effect is that a full copy gets spread across the swarm using close to the minimum upload, instead of the original seeder sending the same data over and over. The cost is that it is unhelpful in every other case. Turning super seeding on for a torrent that already has several seeders slows the swarm down, because the mode deliberately refuses requests it would otherwise answer. qBittorrent exposes it in the right click menu for a completed torrent, and it is off by default for good reason.
Stopping, and what stopping costs the swarm
Stopping a torrent removes your copy from the pool of reachable seeders, immediately and completely. What that costs depends entirely on how many other seeders remain. On a well seeded torrent, nothing measurable. On a torrent where you are the only complete copy, the swarm stops where it is: leechers below an availability of 1.000 cannot finish, and they stay at the same percentage until somebody with the missing pieces comes back.
| What you do | What the swarm sees | What happens to your files |
|---|---|---|
| Pause or stop the torrent | Your copy leaves the swarm until you resume it | Nothing. The files stay where they are |
| Set a ratio limit | Your client stops seeding automatically once it has uploaded that multiple of the torrent size, so 2.00 stops it after twice the torrent has gone out | Nothing |
| Set a seeding time limit | Your client stops after that many minutes of seeding, whatever it has uploaded | Nothing |
| Remove the torrent from the list | Same as stopping, permanently, unless you add it again | Nothing, unless you also tick the option to delete the data |
| Close the client, or let the machine sleep | Your copy disappears without warning and the tracker eventually times you out | Nothing |
In qBittorrent the automatic limits live in the options under BitTorrent, where a ratio limit and a seeding time limit can be set once for every torrent and then overridden per torrent from the right click menu. The choice of what to do at the limit, pause the torrent, stop seeding, or remove it, is a separate setting next to them. Deluge and Transmission have equivalents under different names. This site does not tell anybody what figure to put in those boxes; The swarm explains what the numbers do, and the decision is yours.
Sleep, laptops and overnight seeding
Sleep ends seeding as surely as closing the client does. A laptop that suspends when the lid closes drops every connection, and the client resumes them when the machine wakes, which is why a torrent left seeding overnight on a laptop often shows almost nothing uploaded by morning. A desktop set never to sleep, or a machine that stays on for other reasons, keeps its connections and its place in the swarm. Some clients ask the operating system to prevent sleep while transfers are active, and some do not, so it is worth checking the power settings rather than the client if a machine keeps disappearing from the swarm.
Whether one client seeds or downloads faster than another
No mainstream client is faster than another at the same torrent, because none of them controls the thing that sets the speed. qBittorrent and uTorrent both implement the same protocol, request the same pieces from the same peers, and are limited by the same swarm and the same line. A comparison between them is a comparison of what surrounds the transfer: what the interface shows, what the program installs alongside itself, whether there is a web interface, how the defaults are set out of the box. If a transfer runs at a different speed in one client than in another on the same machine, the difference is almost always a rate limit or a connection limit set in one of them, or the swarm having changed between the two attempts.
One setting genuinely does affect seeding rather than downloading: protocol encryption. Where a connection is refused because one side requires encryption and the other has it turned off, the two never trade at all, and a seeder with restrictive settings can sit at zero in a busy swarm. Encryption in a client explains what that option covers and what it does not.