requested download of chunked stream but no chunked found

[Maximiliano Galarza]

Hi, i have this problem to download a video from this link:  https://mitelefe.com/tiempo-final/temporada-2/capitulo-16/

How can i fix it?

[Wild Willy]

For reference, I am running Windows 7 64-bit, Firefox 109.0.1 64-bit, licensed VDH
7.6.5.a3 beta (same as 7.6.6), CoApp 1.6.3, VLC 3.0.18 Vetinari, ffmpeg from 2022/11/3.
This is the sort of thing you should include in any problem report here.

I went to your web page & the VDH menu was empty. So I clicked the play button on the
video. I got a popup message in Spanish, a language I don't speak. But I do speak
French & some of the words seemed vaguely similar to French. I believe the message was
telling me that the content was not available in my geographic region. The popup showed
the word Argentina. Well yes, I am in the USA, not Argentina, so any geoblocking would
shut me out. Nevertheless, VDH managed to show me what you can see in the attached
images #01 & #02. The VDH menu was long enough that it scrolled, so it took 2 images to
show the whole thing. It looked to me like VDH was recognizing this as separate video &
audio, as I've noted in image #02. So I downloaded those two variants. The video
downloaded fine, & it was indeed a video without audio, but it was only a couple of
minutes in duration. The audio-only variants claim this item is of duration 32:38, so
there was a problem. It did play fine, obviously without sound, but it was only a bit of
the whole thing. The audio variant failed to download, giving the MP2T error that we
have seen here so often. So I enabled the VDH setting for HLS as M2TS & tried to
download it again. This time, I got the no chunkset error you got. Worse, I was left
with a zombie active download in VDH. I cured that in the standard way: Reload the
extension.

Time to try something else. I opened the Firefox Network Monitor & reloaded the web
page. Sure enough, a master manifest showed up. I ran it through ffprobe, as you can
see in the attached file ffprobe.txt. You can see that there are 3 Programs (0, 1, & 2)
with video tracks of various resolutions, all of them rather low. The same audio track,
Stream 0:0, appears in all 3 Programs. This is a classic case that makes VDH erroneously
show separate video & audio. Just because certain programs share a common audio track
does not mean the video & audio are separate. This is a bug in VDH that I hope Michel
gets around to fixing.

But that's not the real problem here. You'll also note that each Program includes a
third Stream identified as timed_ID3 data. I have discussed this multiple times
elsewhere in this forum. Timed_ID3 data is known to cause problems for VDH. You'll also
note that ffprobe doesn't understand timed_ID3 data, either, as shown in the error
messages at the bottom of its report.

The information reported by ffprobe led me to believe this would be easy to get using
ffmpeg. It was. I used the parameters -map 0:5 -map 0:0 on my invocation of ffmpeg,
thus avoiding the problematic timed_ID3 data. I have attached the log from that download
as Argentine Videomp4 Log.txt. This download took 13:51, rather longer than I would have
expected from such a small file. It ended up being only 107M. I've attached image #03
to show the video & audio properties of the file. I emphasize, this file includes both
video & audio. They are not, as VDH would have us believe, separate.

If you look carefully at the ffmpeg log, you'll notice some rather strange errors,
beginning at line 256, when a little under 3 minutes of the video had been retrieved. I
don't know what these errors mean. I am guessing there was some sort of non-standard
tool used to create this content. Whatever the case, ffmpeg had some temporary problems
with the content. There are many instances in the log of ffmpeg dealing with this
problem. The speed factor reported in the log lines bounces around between about 2.4 &
2.5. That means our duration 32:38 video should have taken about 32:38/2.4 or about
13:30. The error processing does not seem to have significantly slowed the download.

In the end, the video appeared to play fine in VLC, with both audio & video all the way
to the end. I have to assume it was fine because, like I said, I don't speak Spanish.
The video was certainly fine. I didn't sit & watch the whole thing, just sampled it at
intervals, & it played fine. I made sure to play the last 20 seconds or so to confirm it
was all there.

I'm not entirely convinced VDH should get this video. The audio track shared by multiple
video tracks is certainly a condition that VDH is known to not handle correctly. I say
that's a bug in VDH that needs fixing. The presence of timed_ID3 data is something that
Michel has dealt with to a certain extent in the code of VDH, but I have reported before
that there remains more to be done in this area. But the errors found by ffmpeg tell me
there is more going on here than those 2 simple problems that VDH should handle. In any
case, if you really want to get this video, learn how to use ffmpeg.

You will find much background information, including a tutorial on how to use ffmpeg, by
clicking here:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/BzPLK2YyL-s

You could also just search this group for ffmpeg. You can find the ffmpeg tutorial that
way as well.