Video Download Failed or Stuck at 99%: What Actually Went Wrong

Short answer: download progress tracks bytes fetched, not a finished file. The final step — ordering segments, combining tracks, writing the container — happens after the last byte, and that is where “stuck at 99%” lives. The other common failures are an address that expired mid-run, one missing segment, a write blocked by disk space or folder permissions, and a server closing the connection under concurrency.

Failure modes, in order of how often they explain it

Symptom	Real cause	What to change
Stuck at 99%, file never appears	Mux/finalise step waiting on a missing segment or track	Re-run with segment listing on; confirm every part downloaded before the merge
Fails at the same percentage every time	One specific segment is unfetchable	Retry the failed part alone; don’t re-download everything
Starts fast then crawls	CDN throttling after an initial burst	Reduce parallel connections; let it settle
HTTP 403 halfway through	Signed address expired during the run	Re-open the page to mint fresh addresses, then resume
Zero bytes for a long video	Session not authorised, or wrong URL	Check playback works in the same context — see detecting no media
Error at the very end only	Disk full, or a protected folder blocked the write	Change destination to a plain working folder and retry
File exists but won’t play	Container written before all streams arrived	Re-mux from the complete parts rather than trusting the partial file

Why the last one per cent is the risky part

For segmented delivery the final file is a construction: segments must be ordered as the manifest specifies (see RFC 8216 for the playlist semantics), audio and video tracks combined, and timestamps normalised into the container. FFmpeg documents those container-level operations in its formats reference. None of that is byte transfer, so a progress bar that reached 99% of the download can still fail completely at finalisation — and a stalled finalisation usually means an input is missing, not that the machine is slow.

A recovery order that works

1. Check the destination: free space, and whether the folder is one the app can write to without elevation.
2. Re-open the page and confirm the video still plays there. If it doesn’t, nothing downstream will work.
3. Re-analyse so addresses are fresh, then resume rather than restart; signed URLs expire while you troubleshoot.
4. If a specific segment keeps failing, retry that part alone — the rest is already on disk.
5. Lower concurrency if the CDN appears to throttle; one steady connection often beats eight fighting ones.
6. Only after all parts exist, remux; verify duration and audio before deleting the parts.

Why online video downloaders fail so much more often

Three structural reasons, none to do with your connection. A web service must reproduce delivery logic for every site and falls behind each change; it cannot hold your session, so anything gated simply fails; and it has no control over the address’s remaining validity — you paste a link that had ninety seconds to live and it reports a mystery error. The failure you see is the service’s architecture, not your page. Local tools that observe an actual playing session avoid all three, which is the argument developed on the local-only downloading page.

Long downloads: what actually helps

• Keep the machine awake. Sleep mid-download aborts the connection and can leave a partial container behind.
• Don’t clean up early. Delete segments only after the merged file plays end-to-end.
• Expect re-authorisation. For anything longer than a few minutes, fresh addresses will be needed part-way — that is normal, not corruption.
• Prefer remux over re-encode when you finally convert, so a retry isn’t also a quality loss; rendition-choice details are in highest-quality downloads.

FAQ