dirkf

If the manual is the spec, then I can't understand why `--no-continue` wouldn't start from 0%. Presumably this was overlooked when fragment downloading was added. >Do not resume partially downloaded...

>That wasn't enough Additionally, the ETA is being calculated incorrectly and a "continued" fragment download is (can be?) incorrect. This seems to be better. The handling of the resumed **fragment**...

Try `--external_downloader ffmpeg`, as you do have _ffmpeg_.

For me, this works with _yt_dlp_: wait for fragment without _ffmpeg_, straight to `stdout` with it, but _ffmpeg_ is ignored in yt-dl. There are two issues: 1. tell `FFmpegFD` to...

When streaming to _mpv_ as in my example, it's only downloading fast enough to fill the various buffers in _ffmpeg_ and _mpv_ while playing the stream, so there shouldn't be...

>... the rate-limiting is to reduce network usage. It's pointless if you're streaming to a player because the network usage will be as much as needed to play the media...

As it's a bug/enhancement resulting from https://github.com/ytdl-org/youtube-dl/commit/3da17834a49fad2a97c308fdd89aa26781ef4d60, I'll close it when the 1-line patch is committed, thanks.

What would normally be a precious output file becomes an intermediate file when `-x` is used. Maybe `--keep` should have been the default for `-x`, but I guess it's too...

You personally can mark your precious existing file RO. But as I pointed out, the problem is that the `-x`/`--extract-audio` function was defined as an add-on to the normal download,...

It's how the program is documented to work. The underlying UI concept is that you can repeatedly issue the same command: if it works, so much the better; if it...