MP4 not playing from HLS stream download (CoApp 2.0.3 + 8.1.0.0a4)

[Allen John]

Dear  VDH team,

A quick brief

HLS Stream -> Quick Sidedownload -> File downloads to designated download folder as MP4.

There is no "Stop", and instead there is an "Abort". After abort, the video has "weight", but doesn't play.

Any suggestions?

[Wild Willy]

Too brief.  What operating system?  Firefox is implied but what release?  And most important of all . . .

URLs

[Wild Willy]

In addition, of what relevance is Stop vs Abort?  What exactly are you trying to do?  Are you trying to interrupt a download before it has finished?

[Wild Willy]

In addition, I've never weighed my videos.  In fact, I've never weighed a computer file, not even going back decades into my past when I had uncounted millions of mainframe files to choose from.  How many grams or ounces do you expect a video to weigh?

[Paul Rouget]

Thanks for the report.

- Was it a live stream?
- Was the size more than 1Mb?
- Can you share the URL? (it's ok if you can't).
- What software do you use to play the file?

[Allen John]

• -Was it a live stream?: Yes

• - Was the size more than 1Mb?: Yes, the file size is above 20 MB at least

• - Can you share the URL? (it's ok if you can't).: An example below
  
  https://video-weaver.jfk06.hls.ttvnw.net/v1/playlist/CqMGunOGBETtpH0YfDqVjsLfMcP3o5i7p9PkiYiN6kvb830P7MdSpTBpYeCotfZCJwn65VI2N-W4uhARRz78rVcBKJuzxKo1_FqnwthzMWXdoZtMD9ZMs1DFxOF3FStVH9tIOYyiJLFZu6NhSU6GFqEbPEYdxhmlF8cbPYIaBGA5EhGsfeRih3LCHbFaSkR--UcHI3gSFL_3245yThFLsPwm7FG3x7Q3re_58uGugW42LcA1gvKnyAsrZdxBrsrcpuiyCkrMehc8PuOcoF47gku9O-KR0cO2FKtS-vGG1nsSEBP6RRFBVeCpwDdEmo1ZE1Z7Dk7ZaDVS3hsCFItx9HFk2IWHQtet7gbk0eS5ufqX-CUKEanYWZ3Cx-FawaJEM5Ae3_9GeUqDsuCyWxeO8jzn50TNh60cdIkkBaH6Rcl0ZjLUI-T8urLA35uvj5btm-4goAmuoSyyMrMSefdDyYFC2FKwYptxz91Lym_DTmXARHATeTCQ_BzqClkoJNem-ec4NVJFI6rQIqqU4UkdUE8HzrZnmsJmdq3VlG_h8iox-UvaT7gOYf6uvk-dGS_Gv-K2qFmEl0YqjiRkvuGCA1PLDVAScU88SMzuOu9rr4-_guccGIkjDavjFRggh8ohKELq1oR6phubgISjYbHu6N_s1KfsyzWNvkIDlGaehW-6dy6WL8AQMqKtDncvAtyxZ3QReagIDXe7dWPqrA9a4fDztgHbQvbeDtY24zXYuLC91kid1FNonoK5xNr-SyqPfB-_dzhrF5rXWCqfZ9LTgzsioa5Wq4cKKdqsF1uHHeVz71QKrjnnTDbGRhpBU-5-48BSQ_WXEn9DCOQ51el1_RxYgAhT7iP4Pz85qOK4k7cq8bky5pG7zrykCN-7C4xwjKoH7_zW9adjoAnVoMtdRNSnLQBR_5hnnbshBpFR3YXfVurcjVRSn21oG1YRMZsXC0GS80PU2cMUY31a0hWCQGZxXhYYWF4iz56JHjrqPW3V6uaiHO5oZfW1Tc12XAlxTIfMECvuulYmnThG1Pa7fG2aTlz7NFdiJOda-JGntGrDm48OoUkaDGU1VCcXVJ4EcQ9ayyABKgl1cy1lYXN0LTIw4wc.m3u8

• - What software do you use to play the file?: VLC, media player classic (K-Lite CODEC Mega)

[Wild Willy]

That URL is no good. First of all, it's the URL of an (I'm guessing) HLS master
manifest. Second, it has expired. These things with the strings of gibberish in them
are unique to the web session, meaning they are custom constructed dynamically by the web
site at the moment you, not anybody else, you visit the web page in question. So nobody
else can use the URL. In addition, these things expire after a time. Try the URL you
posted yourself right now. You will get a 404 Not Found error. You need to give us one
or more URLs of web pages on which the content resides so we can have the web site tailor
manifests for our visits. We need the URL of a web page that is not a moving target.
Most of the content on such web pages is a moving target. But the web page itself is a
stationary target & that's the URL we need.

Alternatively, you can run ffprobe against one of these video files already on your
system. I'm assuming you have at least one of these still on your system. But it could
be one of those broken files that you discarded so this would not be possible. Still,
the information Paul asked for about codecs can be provided by running ffprobe on one of
these after you download it, even if it's a broken file.

Meanwhile, you still haven't told us what operating system you are running nor what
release of Firefox you are using. Don't selectively ignore questions & other advice.

[Allen John]

OS: Windows 11 Pro
Firefox: 118.0.2 (64-bit)

It seems Paul understood the issue and was able to ask the right set of questions in the right manner I wanted to question to be asked. And I answered his questions the best way I can. On the other hand,  either "grampawildwilly " likes to be pretentious or has difficulty collecting his thoughts; sent three replies instead of one.

The requirement of a URL or Link was optional; the last reply with two paragraphs explaining why the link doesn't work is redundant. I was clear about the HLS stream being live-streamed. The link I provided was for an HLS livestream; so when the stream ends, the link will have become invalid.

And no, I do not want to go to GitHub or use FFprobe to check the file I downloaded. This doesn't seem like an issue isolated to the browser or the OS that I use.

So with the parameters I have provided, someone can check and confirm that this issue persists beyond my system instead.

Thanks.

[Wild Willy]

Put it down to sleep deprivation. Perhaps ffprobe is not the most useful thing you could
do here. On the other hand, it might offer a bit of insight. However, you don't need to
go to Github to run ffprobe. You need go only as far as your hard drive. Take a look
over here;

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

I explain how to find ffprobe on your system. Yes, you have it. It has always been &
continues to be distributed as part of the CoApp. I explain in detail over in that
thread where you can find it & how to execute it. Since I had just posted that, perhaps
it was still on my mind when I posted here.

Paul may have grasped the problem but it might help to make it clear to others. Is your
problem that when you interrupt a livestream because you want only a few minutes of it,
that VDH leaves behind a file that won't play? This is not a new problem. I discussed
it over here:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/4x37YO6LRf0

Note the dates on the posts there.

In addition, since it appears that you are talking about livestreams on Twitch, perhaps
this thread is relevant.

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

It is my understanding that the issue discussed there was fixed. That may actually not
be relevant here since you did record something. Still, it's about Twitch so maybe it
wouldn't hurt to look that one over.

[Paul Rouget]

Thanks to both of you.
The way we handle hls live streams have changed in the coapp v2 + vdh 8.1.

Thanks for the 2021 groups link, interesting work around, it shows that we might not handle disconnection correctly.

I need a bit of time to investigate what's going here, but I have all I need to start looking at this problems.

I'll reply here once I made progress.

[mjs]

I did already bring up that issue --> https://groups.google.com/g/video-downloadhelper-q-and-a/c/7p_5tpcCPtE

Indeed no usable file if it is terminated early using side download actions.

If  you want to do that, use quick download or download options then if needed terminate the download when you want.

[Allen John]

@GrandpaWildWilly

Thank you for the links and the step-by-step guide

Here is the screenshot of the FFProbe results.

[Allen John]

@ mjs
The reason why side download was introduced or implemented in VDH was because certain HLS live streams do not download using the "fundamental" quick download and download features. Side download worked once or twice before it started saving unusable files with sizeable weight in MB/GB.

[mjs]

> certain HLS live streams do not download using the "fundamental" quick download and download features. 

I don't think that is the case, I've downloaded live streams

from twitch and other sites and it did work. But the issue

is audio/video would not stay in sync as well as a stuttering video. Enabling the setting HLS as M2TS resolves it.

The newer side download options was also introduced to

fix those same problems.

[Wild Willy]

The issue here, as I understand it, is not about the recording of the livestream per se.
The issue is stopping the recording. VDH still does not terminate downloads, live or
otherwise, correctly. You get what Allen posted above as ffprobe output. I get the same
thing. Look over here:

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

In a post date October 19, I got the exact same result from a stop as Allen has. Look at
the images attached to that post.

VDH has not done proper termination of downloads for years. Sometimes it works,
sometimes it doesn't. Livestream or otherwise, doesn't matter. You can't rely on the
VDH stop command. That's the gist of one of the threads I mention in a post upthread
here. That is still a problem & that is what we should be focusing on here.

Furthermore, since there is no moov atom, ffmpeg won't repair the file. I've tried.
Ffmpeg is fixated on the moov atom. Any attempt to refer to any video that is missing
its moov atom just gets a complaint from ffmpeg that the moov atom is missing. The moov
atom is critical to proper mp4 files. If there is no moov atom, the file is trash. Sad
but true. The solution, as I see it, is for VDH/CoApp to terminate a download by sending
q to the ffmpeg child task. When ffmpeg gets a q, it gracefully terminates the download.
Gracefully means it writes the moov atom before it closes the file. Apparently, the
CoApp is not sending q to ffmpeg. It seems clear to me that the CoApp is simply killing
the ffmpeg child task. That doesn't work. Both Allen & I have confirmed that
empirically. Now we wait for a solution. I have every confidence in Paul, who seems to
be leading this effort. He will come up with a solution. We just need to be patient.

[mjs]

Guess what Willy, your idea to disconnect internet using the command prompt resulted in a playable file from a Twitch stream.

@Allen John , there is a link Willy left in this discussion to learn how to do it.

[Wild Willy]

That's great. My experience has been that it works sometimes & not others. I believe it
works if the connection VDH is using happens to be of type IPV4. If the serving web site
lets VDH connect on an IPV6 link, I'm not sure it works. The choice of IPV4 or IPV6 is
pretty much up to the server. I don't think there's any way for a program to specify one
type or the other. I believe the client side is at the mercy of whatever the server
chooses. I could be wrong. Maybe Paul or Michel could confirm or deny this. I imagine
you could turn off IPV6 inside the operating system. I think there's a way to do this,
although I'm not sufficiently motivated to go find out. Then you would be guaranteed to
be connecting via IPV4. But I think you would be disabling access to a fair chunk of the
Internet if you turned off IPV6. IPV6 is no longer particularly new. My sense is that a
lot of sites use it & those sites would not be accessible if you disabled IPV6. On the
other hand, my sense is that many sites permit both IPV4 & IPV6 access as a sort of
legacy procedure. So it's all rather murky.

It may also be an issue of the version of Windows. You know I'm still on W7. There's no
telling what bugs are in here, bugs Microsoft is most assuredly not even going to
consider pursuing at this stage. I suppose it never hurts to try the command & see if it
works. If it doesn't, just pull the plug on your Internet connection. Either way will
look the same to VDH. When I discovered way back when that the command worked, I was all
excited. Until I discovered some cases in which it didn't work.

The one thing I never do is click the Stop button on the VDH status menu you get from the
blue dot. That is something else that sometimes works, sometimes doesn't. Since there's
no way to know in advance whether it will work, I do it only on things I don't care if I
lose. For anything I care about, I pull the plug. This is how I will continue to
operate until we get definite confirmation that VDH is sending a q to ffmpeg when we
click the stop button on the status menu. That is something I know from experience is an
entirely safe way to interrupt an inflight download, livestream or not.

[Allen John]

@GrandpaWildWilly: I hope you picked on why I mentioned this earlier, "There is no "Stop", and instead there is an "Abort".

Now, I need to check the link for the disconnection trick and see if it works

[Paul]

With the help of WildWilly, we found the issue.

We believe that the CoApp 2.0.5 solves this specific issue, give it a try: https://www.downloadhelper.net/install-coapp-v2

[Allen John]

Dear Paul.
Good morning to you.

I can confirm that CoApp 2.0.5 has solved this specific issue. 

Thank you to @Grandpawildwilly, you and your team in fixing this issue.

[Wild Willy]

One loose end needs to be tied up: Stop vs Abort. I think it's splitting semantic hairs
to distinguish between the two words. The button is meant to interrupt an inflight
download before the download completes on its own initiative. You could call that Stop.
You could call that Abort. You could call it Allen. You could call it John. Just don't
call me late for dinner. As long as we understand what the button does, I don't think
it's too important whether it's called Stop or Abort.

[Allen John]

@grampawildwilly: You like to bully and insult people, don't you?

[Wild Willy]

Ahh . . . The shortcomings of forums like this. You can't see my facial expression.
You misconstrue my humor.