OK. You convinced me to try this. For completeness, I'm running Windows 7 64-bit,
Firefox 95.0.2 64-bit, licensed VDH 7.6.3a1 beta, CoApp 1.6.3.
First, with HLS as M2TS not enabled, I tried to download the 2 variants. Both downloads
ran to completion but terminated with the error as you have described, leaving small
..part files in my download directory. It's annoying that the download would run for 15
or 20 minutes only to end in an error. You'd hope the error would occur at the start,
not the end. Good thing I don't have any sort of data cap or charge per G of download on
my ISP account. Then I enabled HLS as M2TS & tried again. I had to reload the extension
& then reload the web page before things seemed to look right. This time, the downloads
actually completed successfully, with the expected popup notifications from VDH that the
downloads were ready. But the VDH error log contained warnings that the files might be
corrupt. Indeed, they wouldn't play in VLC. Once again, you wish these errors would
occur quickly, not after downloading 5G of data. I guess that's just the way it is. You
also wish VDH wouldn't say the download had completed successfully when it actually
failed.
So I went to my trusty ffmpeg technique. There is a reference to a complete tutorial on
this in the Table of Contents.
https://groups.google.com/g/video-downloadhelper-q-and-a/c/BzPLK2YyL-s
Look for the mention of an alternative technique to try when VDH fails. When I was
downloading the variants via VDH, the Windows Resource Monitor was showing me that the
server site was letting me have on the order of 2 million bytes per second. Using
ffmpeg, it was letting me have just under 8 million bytes per second. That's very odd.
I would not expect there to be such a discrepancy, but here again, I guess that's just
the way it is. But that was only for the video. The audio was getting just over 1
million bytes per second. Most curious. Not a big deal, though, because audio files are
generally considerably smaller than video files.
In the manifest I got here, there was a single audio stream shared by 5 video streams of
various resolutions. I downloaded the one audio stream (of course, there wasn't any
choice for that) & the 1920x1080 video stream. The audio downloaded in about 2 minutes.
But it was only 144M. The video took longer, of course: 12 minutes for 5.16G. You can
see the results of the ffmpeg downloads in the attached images. The Files image shows
the directory into which I downloaded the files. (There is one file shown that has
nothng to do with this discussion.) The Properties image shows the Windows Properties
for the 2 files. I played the 2 files synchronously in VLC & it was fine, video & audio
all the way through. I didn't merge the 2 files into a single MP4, but that is a
possibility if that is your preference. Of course, I didn't sit & watch it. For one
thing, it's in German, a language I don't speak. For another, it's 2 hours long. So I
just skimmed through it, sampling short stretches of it to make sure the video & the
audio were always playing. It appeared to be all there.
So now the question is why was ffmpeg able to download this content while VDH was not?
It's all well & good to say you've got a way to download this content so you should be
happy. But VDH really should have been able to get this. The fact that ffmpeg got it
without any problem should make it clear that there is nothing wrong with the content
being served by the web site. It's most disappointing that VDH couldn't get these things.