All in One Downloader29 September 20264 min read

Why my downloads were stuck at 300 KB/s

An 8 MB/s line, a 300 KB/s download, and a week of blaming the wrong thing. The limit in All in One Downloader was never the line — it was using one connection.

The symptom was simple: a line that happily did 8 MB/s in a browser speed test was downloading a video at 300 KB/s. I suspected the site, then my ISP, then the machine. None of them was it.

Limits are per connection

Almost everything that slows a single download works per connection, not per file. Servers throttle each connection. The round trip time caps how much one TCP stream can have in flight. A box in the middle decides one stream has had enough. A speed test opens many connections at once, which is exactly why it looked fast.

So the fix is to stop downloading a file through one pipe. There is now a setting — connections per file, four by default — and it works in two places:

01Plain files are really split: each connection asks for its own byte range, writes at its own offset, and journals how far it got. A paused download resumes only the pieces that are missing.
02Streamed video (HLS and DASH) is already made of fragments, but yt-dlp fetches them one at a time by default — one round trip per fragment, thousands of times per film. Fetching several at once is the same idea applied to fragments.

GET /video.mp4   Range: bytes=0-104857599          → part 1
GET /video.mp4   Range: bytes=104857600-209715199  → part 2
GET /video.mp4   Range: bytes=209715200-314572799  → part 3
GET /video.mp4   Range: bytes=314572800-           → part 4

One file, four connections, each with its own range and its own place in the file.

Knowing when not to

Splitting only works when the server honours range requests. If it answers anything other than 206 Partial Content, the download quietly falls back to a single connection instead of writing four copies of the start of the file. And more is not always better: past eight or so, some sites start answering with 429 Too Many Requests. Four to eight turned out to be the sweet spot.

The line was never the bottleneck. The shape of the request was.

The same download that crawled at 300 KB/s now fills the line. The interface shows it too: every running transfer draws one bar per connection, so you can watch the pieces race each other to the end.

Next note

One recommender, two platforms