I occasionally download with yt-dlp. I've recently learned that it includes the feature:
Multi-threaded fragment downloads: Download multiple fragments of m3u8/mpd videos in parallel. Use --concurrent-fragments (-N) option to set the number of threads used
Seems useful with a MultiWAN configuration. While it does download multiple fragments, it seems to stick with one ISP for all of them regardless of the number I choose. I did try forcing all downloads to IPv4 (it's an ISP issue I have), and that didn't help.
Is this a Windows limitation, a yt-dlp thing, or is there something I'm missing?
Could you perhaps track how many connections are opened by yt-dlp to the server you're downloading from, with and without this option?
My guess is there is still the same number of TCP connections opened, and this option just enables multiple simultaneous downloads through that unique pipe. If that's the case, it'd be expected for MultiWAN to have no effect.
Try launching multiple downloads to use all the bandwidth?: Can the 1 computer use all the bandwdth to roll over to the other wan? yt-dlp usually averages 30mbps-175mbps. What is your expected multiwan bandwidth/load demand?
Try using the yt-dlp "datebefore/dateafter" args to break up bigger channels? (or filesize args) More unique instances may get better distributed across the available wan ifaces.
Make unique mac's VM's as more than 4-5 connections from one mac may get refused.
-c - Continue downloading a partially downloaded file. Use this option to resume a download started by a web browser or another program which downloads files sequentially from the beginning. Currently this option is only applicable to HTTP(S)/FTP downloads.
-j 3 - maximum number of parallel downloads (in this case 3)
-x 3 - maximum connections per server (also 3 in this case)
Thanks. I already have aria2, but rarely use it. I'll give it a go and see if that solves the problem.
Edit: Doesn't seem to. Changed all the '3' in the args to '4's, but still stuck on one ISP.
Btw, arguments need double quotes, not single.
Edit 2: So I tried adding '--disable-ipv6 true' to aria2c, even though I have -4 on yt-dlp... no change.
Started a download and everything was still on wana. Disabled wana and the download continued uninterrupted on wanb. Re-enabled wana and everything stayed on wanb.
Got sick of this issues. Rebooted Netgear that had OpenWrt, the Linksys running Fresh Tomato as a dumb access point, and the modems...
And now everything works just fine. Weird, but happy now.
I tried the -n that helped with the bigger file downloads.
But big channels with lots of smaller files were still slow.
So then I tried to test how to download lots and lots of smaller files on a single yt channel more rapidly:
Split a download in 2 chronologically at the midpoint (with datebefore and dateafter args) and got it roughly twice as fast on one router.
However yt-dlp cannot immediately ascertain the midpoint - it loads each file sequentially for date comparison which takes around ~1.5s per file on the before arg. The after arg started downloading right away. -n worked on big files but didn't seem to help as much on smaller files. Smaller files could never spool up to hit the max download speed.
