01Two shapes of trouble
Everything on this page is one of two stories, and the cure is opposite for each:
- It never actually moves data. The tool sits frozen on a line, or exits cheerfully having downloaded nothing. The problem is local — your disk, or a filter that quietly emptied the job — and no amount of retrying changes it.
- It moved data, but the data is wrong. The download completed and the files are the wrong size, or the game won't start. Here the tool's own validator is the fix, not a reinstall.
If instead you're seeing timeouts, SSL errors or "Failed to find any server with chunk…", that's the network, and it lives on its own page — when the network is the problem. This page is for when the network is fine and something else is stuck.
02Stuck on "Pre-allocating"
The single most alarming freeze, because it looks like a deadlock and isn't:
Pre-allocating /mnt/usb/game/data/textures.pak…and then nothing, for minutes. CPU near zero, network at zero. People kill it here and assume it crashed. It usually hasn't. Before writing a single chunk, DepotDownloader creates each output file at its full final size — it calls the .NET equivalent of "make this file 8 GB right now." The relevant lines are blunt:
Console.WriteLine("Pre-allocating {0}", fileFinalPath);
using var fs = File.Create(fileFinalPath);
fs.SetLength((long)file.TotalSize);On NTFS and ext4, that SetLength is a sparse allocation — the filesystem just records "this file is 8 GB" and returns instantly. But on filesystems that can't do sparse files, the OS has to physically write zeros across the entire size before it returns. The usual suspects:
- exFAT and FAT32 — the default format on most USB sticks and SD cards. No sparse support, so every gigabyte is zeroed for real.
- USB flash drives and slow external HDDs — even on NTFS, a slow drive zeroing tens of gigabytes takes genuine wall-clock time.
- Network / SMB shares and NAS mounts — pre-allocation over the wire is painfully slow, and this is a common report.
- Antivirus — real-time scanning pounces on each freshly-created large file, adding its own delay on top.
Open your OS disk-activity monitor. If the target drive shows steady write activity, it's working — leave it. A clean test: try the same download to a fast internal drive (a local folder with -dir). If that flies and the USB stick crawls, you've confirmed it's the filesystem, not a bug. The freeze that prompted issue #563 ("hangs after pre-allocating") sat at exactly this point with no network activity.
The fix is placement, not flags. This is the one I reach for every time now: download to a fast internal NTFS or ext4 disk first, then copy the finished folder to the slow drive or share. You pay the slow write once, at the end, on your terms — instead of fighting the tool's up-front allocation. If you must write directly to the slow target, the only honest advice is patience: it will finish, it's just zeroing.
03"Couldn't find any depots to download"
The opposite failure: it doesn't hang, it finishes instantly, having grabbed nothing. The line is exact:
Couldn't find any depots to download for app 1127500This is not "the app has no files." It means every candidate depot was filtered out before the download could start. DepotDownloader walks the app's depot list and silently skips any depot that doesn't match your run — and if that leaves zero, you get the line above. The reasons, in order of how often they bite:
- The OS filter. Depots are tagged with an OS list. If you're on Linux and every depot is Windows-only — common for Windows-only games you intend to run under Proton — they all get skipped. Override with
-os windowsto request the Windows depot, or-all-platformsto take everything. - The architecture filter. Same mechanism on 32/64-bit tags.
-osarch 32to pick,-all-archsto ignore the tag. - The language filter. Language-specific depots (voice packs, localized assets) are skipped unless they match;
-all-languagestakes the lot. - A
-depotlist that matches nothing. If you passed a depot ID that doesn't belong to that app — a typo, or a number copied from the wrong row on SteamDB — there's nothing to download. This is where finding your IDs correctly earns its keep. - Ownership. If a specific depot isn't on your account you'll usually get the sharper line instead —
Depot {id} is not available from this account.— which has its own diagnostic.
The reliable cure is to stop guessing and name things explicitly: look the app up on SteamDB, read which depot actually holds the content you want, and pass it with -depot (plus -os/-all-platforms if the tag is the culprit). A bare -app on its own leans entirely on these filters matching your machine — which is exactly when they don't.
04Frozen mid-download
Progress climbs, then stops dead at some percentage — no error, no completion. Work through this in order:
- Give it a minute, then check the disk. A mid-download stall is very often the same pre-allocation story from section 02 hitting a later, larger file — the percentage you froze at is just where the next big file's zero-fill began. Disk monitor shows writes? It's still going.
- Then just kill it and rerun. Downloads resume chunk-wise (section 06), so a restart costs you only the in-flight chunks and frequently lands a healthier content server. If a single bad CDN node was stalling one chunk, the rerun routes around it.
- If it dies rather than hangs, with
Failed to find any server with chunk … Aborting., that's a CDN-side gap, not your disk — follow the missing-chunk path. - Lower the parallelism. On a thin or shared connection, a high
-max-downloadscan saturate the link to the point of looking frozen. Drop it (try-max-downloads 4); counter-intuitively, fewer connections can finish faster. The speed knobs all live on the slow-downloads page. - Check free space. Because files are allocated at full size up front, a disk that can't fit the whole download fails early and loudly — see the next section — but a disk that fills mid-job from other activity can wedge it. Make sure the target has room for the uncompressed total, not the download size.
05It finished, but it's wrong
The download reported success, but a file is the wrong size, the game crashes on launch, or you simply don't trust it. Two cases.
It ran out of disk. If allocation couldn't reserve the full size, DepotDownloader doesn't silently truncate — it throws, with one of these:
Failed to allocate file /path/to/file: There is not enough space on the disk.
Failed to resize file to expected size …Both fire up front, before chunks are written, precisely because the tool reserves the whole file first. The fix is room: a full download needs space for the uncompressed total, which on SteamDB's depot page is larger than the "size on disk" download figure you might be eyeing.
It corrupted in transit. Rare, but it happens — a chunk arrives wrong and slips through. You don't need to wipe and re-pull the whole thing, because the tool can re-check an existing install against the manifest. Point it at the same folder with the validate flag:
DepotDownloader -app 218620 -depot 218621 -manifest 3319603951769285328 -validateWhat it does under the hood: for each file it compares the on-disk data to the manifest's recorded chunk checksums, and re-downloads only the chunks that don't match — not the whole file, not the whole depot. You'll see it print Validating … as it works through them. This is the same machinery the -validate alias drives (the source calls it verify-all); it's the surgical repair tool, and it's almost always faster than starting over. Issue #66 is the long-standing "corrupted download" thread where this came up — note that there, a validate pass flagged different files each run, which is the fingerprint of download-time corruption (a flaky link or failing disk) rather than one permanently-bad file. If validate keeps finding fresh damage on every pass, suspect your hardware or connection, not the depot.
06The .DepotDownloader folder & resume
Inside whatever directory you downloaded to, there's a hidden .DepotDownloader folder. It's not litter — it's the bookkeeping that makes resume and incremental updates work:
- A
depot.configrecords which manifest ID you currently have for each depot. That's how a re-run can diff old against new and fetch only changed chunks instead of the whole depot again. - A
stagingarea holds files as they download; completed files are moved into place. That staging step is why an interrupted run doesn't leave your existing install half-overwritten — the partial lives in staging, not on top of your good files.
The practical upshot: if a download wedged into a state that keeps failing the same way, deleting the .DepotDownloader folder clears the tracking and staging, so the next run starts from a clean slate and re-checks everything. It's the "have you tried turning resume off and on again" move — reach for it when a stuck partial won't recover, not as a routine step (you lose the resume shortcut, so the next run does more work). For a healthy install you want to keep it, because it's what turns a multi-gigabyte update into a few-megabyte delta.
Still stuck after all this? The useful bug report carries four things: your exact command, the full output up to the freeze, your OS, and the target filesystem (NTFS? exFAT? an SMB share?) — that last one resolves most pre-allocation reports on sight. The issue tracker is the place; once it downloads cleanly, the what-do-I-do-with-the-files guide takes it from there.