Jules-A

> cc @Jules-A (I thought you were working on it) I just implemented a hacky solution that worked okay and I settled on using myself but I gave up trying...

Percentage completion and fragment count update too slow for my liking, I liked them updating faster, maybe you can do different updating speeds for %/count to the others? Speed, while...

> I'll say let's first agree on the core implementation and leave the details for later: Do you guys agree with the thread lock and the tracking of fragments by...

> Looks like it is not guaranteed that the HTTP downloader return 'downloaded_bytes'. Can you reproduce it consistently? I'll make the implementation more defensive. Resumed fine that time with latest...

> Be aware that 1Mbit is 0.125 MB. And yt-dlp uses MiB so this seems to be roughly correct. Yes, I'm aware but it should still be around 6.7MiB/s not...

Latest commit is slightly better but still extremely far from being accurate. It starts at 5MiB/s and very slowly increases to 6.12MiB/s (real should be ~6.75). Running another download for...

> How do you determine the _real rate_? I mean the math is actually simple: `rate = downloaded bytes within timespan / timespan` I haven't tested the code but I...

I tested this as of https://github.com/yt-dlp/yt-dlp/commit/6c122499673d534771c8cd2ab9928805b614abea and things were a lot better with a few minor issues. Speed seemed to jump to slightly lower values than expected every now and...

> * When starting/resuming a download the speed is ramping up and then stabilizes at a certain rate (congestion control) > Since it is the initial data the average is...

Hmm... I think maybe it's showing absurd results because it's only updating every second? 0.4-0.5 seems like a better option for speed. With it at 1 second, updating the array...