How FetchDL measures download speed and reports failures
Understand the difference between URL resolution, first byte, complete transfer and playlist preparation, with public measurement data.
A first-byte time is not a whole-file download time. Cold retrieval and cached archive preparation are different workloads. FetchDL publishes the sample scope, attempted and successful counts, formats and limitations beside its measurements.
1Measure each stage separately
2State cache and environment
The original playlist test ran on a one-core ARM VPS. Cold audio retrieval took 124.81 seconds for 89 attempted tracks, with 88 saved; a new ZIP using existing audio took 8.10 seconds. Subsequent browser transfer is excluded.
Do not remove live cache files to manufacture a cold result. Use a separate private cache namespace for another controlled run.
3Requirements for a competitor comparison
Use the same permitted fixture corpus, client, network window and requested quality. Record domains, versions, several runs, failures and unsupported cases. Publish median/range and test conditions.
No controlled competitor-speed study has been completed. We do not promote fixed platform-versus-competitor bars as measured evidence.
4What remains unmeasured
The historical ten-hour full-file validation used the legacy file downloader. The public browser-stream test transferred a 64 MiB sample. They do not establish a complete ten-hour diskless browser transfer or a 1,000-user capacity.
CPU, storage, network and provider constraints remain. A missing measurement is marked unavailable rather than given a guessed number.
test this workflow directly
Choose video, original audio or collection ZIPs. Archives attempt up to 100 items.
questions and answers
Does first byte prove completion?＋
No. It measures startup after stated preparation, not a complete playable file.
Was competitor speed measured?＋
No controlled head-to-head speed study was completed.