What Is Sequential Download, and Should You Turn It On?

The honest answer is "sometimes". Sequential download is a reasonable tool for a narrow job and a poor default for everything else. This table is the quick version; the rest of the post explains why.

Situation	Sequential download?
You want to start watching a video before it finishes	Yes, for that one torrent
You want to check that a big archive or ISO is the right one	No, use "first and last pieces first"
You download lots of torrents and want them all in order	No
The swarm has one or two seeders and few peers	Better not
You want to jump to the middle of a film and watch from there	It will not help much (see below)

How a torrent normally downloads

A torrent splits every file into pieces, usually a power of two in size; the BitTorrent specification (BEP 3) says 256 KiB is the most common. Each piece is fetched in smaller blocks, and every current client requests blocks of 16 KiB. Your client asks many peers for different blocks at once and keeps several requests queued with each one, which the spec calls pipelining.

Which piece to ask for next is the important decision. Bram Cohen's 2003 paper on BitTorrent's design lays out the rules most clients still follow:

Random first piece. A brand-new peer has nothing to share, so it grabs a random, easy-to-find piece to get something to upload as soon as possible.
Rarest first. After that, it fetches the pieces that the fewest of its neighbours have.
Strict priority. Once one block of a piece is requested, the rest of that piece comes before anything else, so pieces complete quickly.
Endgame mode. Near the very end, the last outstanding blocks are requested from every peer at once, and the duplicates are cancelled as soon as one arrives, so a single slow peer cannot hold up the finish.

libtorrent, the engine inside qBittorrent, describes rarest first as "the normal mode of the picker".

Why rarest first matters

Rarest first is what keeps a swarm healthy. Cohen gives three reasons:

Every peer ends up holding pieces its neighbours want, so peers always have something to trade.
When a seeder uploads a piece, the swarm can see that someone already has it, so downloaders ask the seeder for pieces nobody has yet. The seeder's upload is spent on new data, not on copies of what is already out there.
If the original seeder leaves, the pieces that were rarest have already been copied as widely as possible, which lowers the risk that part of the file disappears from the swarm for good.

That last point is the one you feel as a downloader. A torrent stuck at 99.8% with no seeders is often one where the last missing pieces only ever existed on a seeder who left.

What sequential download changes

Sequential download replaces rarest first with "lowest piece number first". libtorrent's documentation puts it plainly: in this mode the picker "will pick pieces with low index numbers before pieces with high indices". Your client still talks to the same peers and still fills its request queues, but it fills them in file order.

The upside is obvious. After a few minutes, the first part of the file is complete on disk, and a media player can open it and play while the rest arrives.

The downside is less visible, because it lands on everyone else.

Is sequential download bad?

For one person, now and then, on a well-seeded torrent: not really. A big swarm with many seeders has every piece in plenty, so the order you pick in barely changes anything.

The trouble starts when it becomes the default. If every downloader goes from piece 0 upwards, they all want the same pieces at the same time and all hold the same pieces. Peers that are further along have nothing the newcomers want except the early pieces, and the late pieces stay concentrated on the seeders. If those seeders leave, the end of the file can vanish from the swarm. That is exactly the failure rarest first was designed to prevent.

Research backs this up. A SIGMETRICS 2008 paper that modelled on-demand streaming over BitTorrent warns that collecting pieces in order "may reduce the spatial and temporal diversity of pieces" in the swarm, "resulting in poor system performance", and its models help "explain the sluggishness of the system with strict In-Order streaming". The streaming designs it reviews all look for a compromise: the pieces you are about to play come in order, and the rest keep enough variety for the swarm to work.

This is also why qBittorrent has no global "always download sequentially" setting. Requests for one have been raised repeatedly on its issue tracker and closed. You have to turn it on per torrent, which nudges you towards using it on purpose.

How to turn on sequential download in qBittorrent

You can switch it on as you add a torrent or for one that is already downloading. Either way it applies to that torrent only.

When you add a torrent:

Open the magnet link or .torrent file so the dialog for adding a torrent appears.
Tick Download in sequential order.
Optionally tick Download first and last pieces first as well.
Click OK.

On a torrent that is already downloading:

Right-click it in the transfer list.
Click Download in sequential order. The same menu has Download first and last pieces first.

The menu items only appear while the torrent is still downloading. Recent versions (5.1 and later) also have both checkboxes in the right-click Torrent options dialog.

Turn it off again once you have what you need. If you are not watching while it downloads, sequential order gains you nothing.

What "download first and last pieces first" does

This option is gentler and often more useful. It moves the start and the end of each file to the front of the queue and leaves everything in between on normal rarest-first rules.

The reason is file structure. Many formats keep important information at the edges:

MP4 files have an index (the "moov atom") that can sit at either end. FFmpeg, for one, leaves it at the end unless you use its faststart option, which its documentation describes as a second pass "moving the index (moov atom) to the beginning of the file".
Matroska (MKV) files written by FFmpeg put their seeking index, called cues, at the end of the file by default.
Archives and disk images often keep headers or directories at one end.

A player that cannot read the index may refuse to open the file or may be unable to seek. qBittorrent's implementation gives top priority to the first and last 1% of each selected file, with a comment in the source noting that this covers the worst case of an AVI index.

A long-running feature request on the qBittorrent issue tracker describes first-and-last as "peer safe" and full sequential mode as something to use sparingly. That is a fair way to think about it. If you only want to preview a file or check it is what you expect, first-and-last on its own is usually enough.

Why skipping ahead still stalls

Suppose you turned on sequential download, opened the video in a player at 10%, and now want to jump to the 60-minute mark. Often the picture freezes and stays frozen for far longer than the jump should take. There are three reasons.

The client does not know where you are watching

A download client's sequential mode is a sort order, nothing more. It does not know that a player is reading the file, or where. When you jump ahead, the player asks the disk for data that is not there yet, and the client carries on downloading from where it was, around the 10% mark. The piece you need moves up the queue only as fast as the download reaches it.

Requests already queued from the start

Even a smarter app that does notice the jump has a backlog to clear. Clients keep several requests in flight with each peer to keep the connection busy. At the moment you skip, every one of those queued requests is for data near the old position, and peers serve them in order. Unless the app cancels them, your new position waits behind data you no longer need.

Slow peers holding urgent pieces

In a swarm, peer speeds vary enormously. libtorrent's own streaming notes describe the problem: in sequential mode, "piece 0 may be requested from a slow peer" while fast peers fetch later pieces. One slow peer holding the piece you need right now stalls playback, however fast the rest of the swarm is. libtorrent's documentation states it outright: "Sequential mode is not ideal for streaming media". It points developers at piece deadlines instead.

How a player built for streaming handles a skip

Apps designed to stream torrents treat the playhead, not the start of the file, as the most important position. The details differ between apps. Here is how TorrentStream, the free and open-source player we make, does it with its own engine:

Playhead first. It requests the pieces at the current playback position before anything else, then the file's index, then a read-ahead window sized from the video's bitrate.
Cancel what is no longer urgent. On a skip, it cancels outstanding requests that the new position does not need, so they stop holding up the connection.
Fastest peers for urgent pieces. The pieces at the new position go to the peers that have been delivering fastest.
Duplicate the most urgent blocks. The most urgent blocks are also requested from a second peer, so one slow peer cannot stall playback. It is the same idea as BitTorrent's endgame mode, applied at the playhead rather than at the end of the download.

Outside that urgent window, the background download goes rarest piece first, like a normal client, so the swarm still gets the variety it needs.

What that looks like in numbers

Measured with TorrentStream's benchmark tool, timing until the data at the new position is ready, with an empty cache and a fresh session for each skip:

Test	Median skip	95th percentile
Local seeder, 8 MiB/s link	0.27 s	not measured
Public swarm (Ubuntu 24.04 ISO, ~600 peers), capped at 10 MiB/s	0.70 s	1.47 s

Start-up on that public swarm took 1.2 to 2.8 seconds. In a recorded demo using healthy Blender open-movie swarms, playback started 0.53 seconds after pressing Play, and skips resumed in 0.6 to 1.25 seconds. Public swarms vary, and a torrent with few seeders will be slower whatever the app does.

Two caveats so the numbers are not misleading. These figures are for TorrentStream's own engine, which handles .torrent files. Magnet links currently default to an embedded librqbit engine, which on the same swarm measured 3.7 seconds to start and 2.7 seconds per skip; you can route magnets through the faster engine in Settings, Advanced, Engine. And TorrentStream is an early preview with unsigned installers, so Windows SmartScreen and macOS Gatekeeper will warn you. Its built-in player also cannot decode some audio formats (AC-3, DTS) yet. If you want a full download manager with RSS and a web UI, stay with qBittorrent and use sequential download for the occasional preview.

For a wider look at the options, see the best torrent streaming apps and how to stream a torrent without downloading it first.

A sensible way to use it

Previewing or checking a file: first and last pieces first, nothing else.
Watching while it downloads, start to finish, in qBittorrent: both options on, for that torrent only, then turn them off.
Watching and skipping around: use a player built for streaming rather than a download client in sequential mode.
Everything else: leave it off. Rarest first is faster overall for you and better for the swarm.

If a torrent is crawling whatever order you pick, the order is rarely the problem. Seeders, ports, and VPN settings matter far more; why a torrent is slow or stuck covers those.

Sources

Checked on 20 October 2026.