VDH （add-on for Firefox） can't find and download twitch live stream

[Rex Shen]

Until yesterday,I still use VDH （add-on for Firefox） to download video,

Today it failed to find twitch live stream,other twitch video(VOD or clip) is normal, other website is normal too

at the sametime,VDH （add-on for chrome） is normal 

[Rex Shen]

Rex Shen 在 2023年4月19日 星期三下午4:50:52 [UTC+8] 的信中寫道：

[Yu-Hsiang Chen]

You can check your Firefox Version.

I also had this problem while i update to Version 102.

 When i downgrade to version 111.0.1,  VHD is working will.

Rex Shen 在 2023年4月19日 星期三下午5:00:26 [UTC+8] 的信中寫道：

[mjs]

I think there is a bug in the latest Firefox, it seems to be omitting the master manifest for the live streams when I looked in the developer tools.

Because of that VDH does not detect anything. Someone should file a bug on the bugzilla site. I'm  not doing it since I don't use twitch much.

[victor]

Hi.

To which version you downgraded exactly?

you said from  102 to 111.0.1

I downgraded to 112.0 since it was working with that some hours ago, but not anymore.

[mig]

There is indeed a regression in Firefox 112 causing the network listener to "forget" the tab that requested the video. VDH not being able to identify the original tab, it simply ignores the request.

I will post a bug entry about this in bugzilla and come back here to post the bug link.

[mig]

The issue has been filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1829200

You can get more technical details from the issue description.

[mjs]

Another site --  kick.com had the same issue as twitch.

[Wild Willy]

I have added myself as a listener to the Bugzilla report. Thanks for filing it, Michel.
You folks who are interested in this issue should add yourselves to the CC list in the
People section of the Bugzilla report. Then you will get notified when this bug in
Firefox has been corrected & rolled out to the general public. You might also vote for
the bug, as I have done, even though I have utterly no interest in Twitch.

That Bugzilla report contains instructions for implementing a workaround. I set the
indicated Firefox property as advised, then I visited Twitch, something I've never done
before & probably will never do again . . . unless there's some problem report here that
prompts me to do so. When I opened the VDH menu, there was the usual array of variants
listed. So the workaround reported in the Bugzilla report indeed does get around the
problem. I'm sure it's just a workaround. When the Mozilla devs get around to fixing
this regression, you should no doubt revert the property mentioned there.

So I went through the standard technique required to use ffmpeg to get the livestream
that is at the top of the Twitch home page. Why ffmpeg? Why not VDH? Because you
cannot tell VDH to record only 5 minutes of something. Hint hint. Product enhancement,
Michel. Also, my experience with stopping inflight downloads with VDH has had mixed
results. Sometimes VDH properly closes the download & writes the moov atom into the
target file. Sometimes it does not. When it does not, the resulting file is just
garbage, can't be played, can't be repaired, might as well erase it. It's an
intermittent, unpredictable thing. Hint hint. Program bug, Michel. I didn't want to
waste my time with a VDH recording that I might or might not be able to play after
recording it. In addition, ffmpeg offers me the option of discarding corrupt packets
instead of just failing. I'm not sure what VDH does when it gets a corrupt packet. I
think it should discard them. I don't think this should even be a user-selectable
setting. If a user sets VDH to download/record something, the user wants it recorded. A
corrupt packet is a lame excuse for terminating a download. So if VDH does not already
simply ignore corrupt packets, here's another hint hint for a product enhancement,
Michel.

In any case, ffmpeg was able to record 5 minutes of this livestream no problem, video +
audio. It looked like a guy interviewing a performer of some kind, perhaps rap. It was
in Spanish so I didn't understand a word of it. At least, I think it was Spanish. I
don't really know. Like I say, it was in a language I didn't understand.

Interestingly, there was timed_ID3 data in this livestream. I still don't know what
timed_ID3 data really is because I've never actually seen any. Even with ffmpeg set to
-strict experimental, it still simply ignores the timed_ID3 data. There is a better than
good chance that whatever VDH downloads from Twitch, at least for this particular
livestream, it won't play properly. It will be subject to skips. Maybe other Twitch
content doesn't have timed_ID3 data. But if you find that your Twitch recordings via VDH
skip, it will be because of timed_ID3 data. If it bothers you enough, you'll learn how
to use ffmpeg. I've put a tutorial on ffmpeg in here. I've referred to it enough times.
You should be able to find it easily enough. This problem with timed_ID3 data has been
reported several times in here. I believe you did something in the area of timed_ID3
data at some point, Michel, but you need to revisit that. You need to simply ignore &
discard any timed_ID3 data you encounter. You should know that on at least one occasion,
I encountered a site where there were multiple Streams of timed_ID3 data in Programs as
reported by ffprobe. So you can't just discard the first Stream of timed_ID3 data you
find. You have to keep looking to make sure there isn't another Stream of timed_ID3 data
hiding behind the first one. I encountered that case & discussed it in a thread here.
Fortunately, I bookmarked it for easy reference:

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

[mjs]

I don't think timed_ID3 data causes too much trouble, I've downloaded videos before that have it and it still plays smoothly.

But the difference is that I have HLS as M2TS enabled. If you have this setting off the resulting file is quite choppy.

Mig has acknowledged  that there is a problem as well as solution which is being held back due to licensing.

Back onto timed_ID3 data , have you noticed on live streams if you watch them long enough they cut to adverts before resuming back to

the live stream. I'm guessing the timed_ID3 data is what specifies the live feed to insert ads.

[Wild Willy]

Ads. That's a thought. But since neither of us has ever seen any timed_ID3 data, we're
just guessing. YouTube inserts ads & I don't believe there is any timed_ID3 data over
there. So, the guesses can go on forever.

[Wild Willy]

And no, the livestreams I have watched generally don't cut to ads. There are no ads on
Medici.tv, for example. Other livestreams I have watched have ads because they are TV
broadcasts & the TV networks plop ads into their content as a matter of course. But
that's kind of a special case. I can't say I've ever attempted to watch any livestreams
on any platform like YouTube, Twitch, Facebook, or any other platform of that type. I
know about YouTube ads because I have encountered them interrupting classical music
videos. But those aren't livestreams. I hardly every watch anything on YouTube because
of the ads. I usually use VDH to download the content instead because the downloads are
ad-free. Even if it's only a couple of minutes long, I'll download it.

[Name Redacted]

FYI

Same issue with WinkTV and PandaTV

Setting dom.workers.pFetch.enabled to false restores my ability to download videos from WinkTV and PandaTV.

[Wild Willy]

According to recent activity on Bugzilla, it appears that our solution to this problem
will not be in the next release of Firefox, which will be 113. But it has been scheduled
for Firefox 114. I'm guessing we're looking at a delay of about 2 more months. So in
the interim, either you need to continue to use the circumvention described on Bugzilla
or you need to learn how to use ffmpeg.

[Wild Willy]

I have speculated in other threads that it didn't look to me like Michel's Bugzilla report would get a fix that actually made it into Firefox 114.  There appears to be no progress there & other Mozillians have been prodding the owner of that bug to do something.  The latest response there, which was a week ago, is that there is some kind of delay waiting on something or other.  I'm not a Firefox developer.  I don't understand half of what it says there.  But I can figure out enough to reach my conclusions.  Firefox 114 was released today & indeed it does look like our bug correction has not made it in.

However, there has been some progress.  I reverted my pFetch preference in about:config to default.  Then I opened a Firefox window, opened the Network Monitor, filtered on .m3u8, then navigated to the Twitch home page.  An HLS master manifest showed up.  This was not happening when this issue was first raised.  So there has been some progress.  I was able use ffmpeg to record 2 minutes of the livestream that was at the top of the page at the time, something utterly boring that I barely glanced at.

Unfortunately, the VDH menu remained blank through several reloads of the page & launches of the livestream.  So our problem is not yet solved.  Another problem is solved, but not ours.

[Wild Willy]

Recent activity on Michel's Bugzilla report appears to be extremely discouraging.  If I am reading the tracking information correctly, the developers involved (there appear to be several in addition to the one who seems to be the programmer fixing the problem) look like they've decided that this fix won't go into a public release of the browser until Firefox version 118.  I'm guessing that means we won't get our fix for at least another 3-4 months.  In addition, it looks like the lead developer on this bug finally, after a lengthy silence, pushed a fix for this earlier today.  Problem is another developer, I would assume somebody in quality control, has rejected the fix because it failed some standard tests.  Now, I admit this is just my interpretation of the activity over there.  I'm no expert.  I have never contributed code to Firefox.  I probably wouldn't understand any part of their code even if I got my hands on it.  So I would certainly accept more informed opinions on what's going on over there.  My view is they have assigned the wrong programmer to fix this & they need to give it to somebody more skilled, more talented.  They appear to be wasting time with this.  But that's just my assessment.  Perhaps Michel sees it differently.

[mjs]

I think we almost forgot about this issue but good news is that they fixed it. It was resolved 24 days ago & the bug closed on bugzilla.

Streams are detected again for Twitch and Kick. If you changed the setting in about:config don't forget to reverse it to true.