Re: Testing VDH 7.6.3a6 beta

[Wild Willy]

I was under the impression that this was to be a livestream:

https://www.medici.tv/en/operas/mozarts-magic-flute-lydia-steier-joana-mallwitz

However, both VDH & ffprobe on the manifest that appeared gave me a duration value of 2:24:37.  I have never seen a livestream that specified a duration.  Livestreams specify durations of N/A, which makes sense, because a true livestream could be a little longer or a little shorter than whatever was planned.  So this turned out to be not the test I was hoping for.  I downloaded 2 copies of the same archived file instead of the 2 copies of the same livestream I had hoped to find today.

In any case, I ran concurrent downloads of this performance with VDH & ffmpeg & got essentially the same results.

The VDH download took about 50 minutes while the ffmpeg download took about 42 minutes.  The difference is due, no doubt, to the vagaries of the download speed Medici TV was giving me over the course of the downloads.  Both downloads showed varying speeds in Resource Monitor.  They were both in the 2 million bytes per second range but they fluctuated.  The resolution & the frame rate quoted for the VDH download are bogus.  Both ffprobe & VLC report that the file I downloaded with VDH in fact had a resolution of 1920x1080 & a frame rate of 25fps.  I don't know why VDH causes the Windows properties to be off like this but this seems to be a regular result these days, although it's not like this 100% of the time.

As an aside, a livestream of almost 2 & 1/2 hours is supposed to take about 2 & 1/2 hours to record.  It's live.  Duh.  Clearly, with both tools downloading the files in under an hour, this was absolutely not the livestream I was expecting.  But a test against a livestream is what I need to determine whether VDH 7.6.3a6 beta now handles those properly.  That will be the true test of whether 7.6.3a6 is a good version.  I'm hoping to get such a test soon.

Interestingly, the Windows file manager reported the file size was 5.37G for both downloaded files.  But looking more closely at the numbers, the VDH download was actually ahout 4M larger.  I don't know why.  4M in a file that is well over 5G is not a lot.  Both files consisted of just a video track & an audio track.  As you can see, the video & audio bit rates are exactly the same in both files.  Sampling them the little bit I did seemed to show I had 2 copies of the same performance.  So the size difference is a mystery.

A careful inspection of the Network Monitor showed that there was a manifest for English subtitles with this.  I used ffmpeg to download this separate stream.  Curiously, this download got rather pitiful service, under 100,000 bytes per second.  It took a little over 4 & 1/2 minutes to download only 166K of captions.  Like I say, pitiful.  In any case, I used this subtitle file with both the VDH & ffmpeg downloaded videos & it appears to work fine, which is no surprise.  I haven't watched the whole opera yet, just skimmed through it to make sure I have both video & audio in both files & that the captions display fine with both files.

You can replicate my results yourself.  All you need is a user ID & password on Medici TV.  That is a free registration.  This particular performance is available to people who do NOT have a paid subscription to the site.  I don't have such a paid subscription so you wouldn't need one either, just a free subscription.  The web page says that this particular performance will be available for the next 3 months, so you have plenty of time to check it out.

So this is an early result for testing VDH 7.6.3a6 beta.  It seems to work fine on the sort of thing that the earlier betas also had no problem with.  Like I said, the true test will come when I can exercise this beta against a livestream.  Stay tuned.

[Wild Willy]

In case anybody is wondering, this thread starts with a deleted message.  That's intentional.  I deleted that post.  It didn't contain anything.  I have discovered that if you include any embedded images in the lead post of a thread, the images are smaller than normal.  Only the second & subsequent posts in a thread get embedded images that are a reasonable size.  (This does not apply to attached images, only embedded images.)  So there's an ugly deleted post at the top of this thread.  But deleting that first post changed the title of the thread.  The title now begins with Re: which was not what I started with.  Google did that.  Oh well.

[Wild Willy]

I ran simultaneous recordings of a Golf Channel/NBC Sports livestream earlier using 2
Firefox profiles. In one profile, I used 7.6.3a6. In the other, I used 7.6.3a1. I got
identical results. As usual, the livestream is not available until 15 minutes before the
broadcast window, which lasted 3 hours. You'd think if you joined the livestream about
15 minutes before broadcast time, you'd get 15 minutes of prefix & then you'd get the
live broadcast. This is never the case with these golf tournaments. No matter when you
join the livestream, you always get about 1 hour of "Coverage will begin shortly" at the
start of the recording. Then you get your 3 hours of golf, then you get a few minutes of
"Coverage has ended." It so happens that I joined this livestream after almost 2 hours
were past. It didn't matter. Both betas recorded 1 hour & 39 minutes of "Coverage will
begin shortly." That's pretty bad, even for Golf Channel, probably the worst I have ever
seen. It's such a waste. I'm glad that no matter when you join the stream, VDH always
rewinds to the beginning. You made a comment about how VDH would always join a stream in
progress at the moment you join it. But that is clearly not what happens with these NBC
livestreams. I just wish "beginning" meant 15 minutes before the broadcast window
instead of an hour or more. I don't know why NBC does this. In any case, VDH records it
all with both betas.

Since I joined the livestream so late, I don't think either recording actually caught up
to 100%. Both recordings ran about 30 minutes past the end of the broadcast window.
This is also good. If you join the livestream late, it doesn't just quit when the
broadcast window ends. They serve the full livestream even after it's no longer live, so
you get the full recording. But because I never caught up, I didn't test the critical
boundary condition that has not been handled correctly by all the betas after 7.6.3a1. I
will have to join a livestream shortly after the 15 minute lead time before the broadcast
window. They don't publish the link to their livestreams until then. So on one of the
days during this golf tournament, I will try to join it early. That will give 7.6.3a6 a
chance to catch up to 100%. The recent betas have had the bug that makes them abandon
the livestream the first time they catch up to 100%. The true test will come when
there's hours left in the broadcast window & 7.6.3a6 reaches 100%. Will it exhibit the
same bug as the other recent betas & stop recording? Or will it do what 7.6.3a1 has
always done, which is to simply continue recording despite being at 100% complete? I
hope to exercise this condition in the coming days. Once again, stay tuned.

I will also need to test 7.6.3a6 on a Medici livestream. I will not be happy if VDH does
not rewind to the start of the livestream. Of course, I will be doing such a test
simultaneous with a recording via ffmpeg. Ffmpeg permits rewinding to the start of
Medici livestreams. This rewinding appears to be a feature of the livestream, not a
feature of ffmpeg. In general, the server has to permit rewinding. When it does, ffmpeg
can take advantage of it. I suggest you do the same. It is not necessary to keep
previous HLS chunks & therefore waste storage & leave yourself open to memory leaks.
What is necessary is to supply the relevant parameter on your recording API so that you
invoke the server's rewind option. This should not be a VDH setting. You should just do
it when you can. People joining livestreams late ALWAYS want to rewind the recording to
the beginning if possible. This does not mean there needs to be a VDH setting for it.
Just do it.

Speaking of Medici, they are based in Paris. It is practically your patriotic duty to
join the site. It costs nothing. You just supply your E-mail address & choose a
password. Then you can access many of their livestreams. Not all, but a reasonable
number. And it's free. No cost. 0 euros. This isn't like some random user expecting
you to sign up for a web site in order to diagnose a problem. This is a web site that is
your next door neighbor that is a source of livestreams that you can use for testing.
The opportunity is too good to pass up. You should do it.

[Wild Willy]

I did the duplicate recording trick again today with the golf & it looks like 7.6.3a6
handles the 100% complete case correctly now. I think I'll do the dual recording thing
once more tomorrow & then I'll just start trusting 7.6.3a6. I still need to find a
livestream on Medici. Their new videos the last few times have all been archived items,
not live, so it may be a while before I can test that properly. But so far, 7.6.3a6 is
looking good.

[Wild Willy]

Once again today, the parallel test shows 7.6.3a6 does the job correctly. I'm not going
to do any more parallel tests. My confidence in 7.6.3a6 is complete. I do still need to
test it on a Medici livestream but it works just fine on the NBC golf livestreams.

[Wild Willy]

Medici finally put up a livestream today that I wanted to see.  So I did parallel
recordings with VDH 7.6.3a6 & ffmpeg.  The results were the same.  Well, nearly.  VDH
once again gave me a file that the Windows Properties dialog claims to be resolution
1912x1088.  This is, as it has been every time so far, bogus.  The file is 1920x1080, as
reported by ffprobe & VLC.  The file from ffmpeg shows the correct 1920x1080.  Otherwise,
the duration 2:41:51 is the same for both files.  The video bit rates, audio bit rates, &
audio sampling rates are the same.  The video frame rate in the VDH file shows 24fps
according to Windows.  However, both ffprobe & VLC show that it is actually 25fps.
Windows, ffprobe, & VLC all agree that the frame rate on the ffmpeg file is 25fps.
Whatever VDH is doing to make windows report 1912x1088 instead of 1920x1080 must be
causing a similar error on the frame rate.  This has been very consistent with pretty
much every HLS stream, live & not, that I have downloaded with this VDH beta.  There is
something fishy going on there.  At least the files are not actually what the Windows
Properties dialog says they are.  But VDH is doing something to fool Windows.  I trust
VLC & ffprobe more & they report the truth.  But I think there is something worth looking
into here.  The file size is 5.04G for both files, but when I look more closely, the VDH
file is actually about 3M larger.  This is insignificant but interesting.

I launched my VDH download at 13:46 & it ended at 16:26, 2 hours & 40 minutes later.  I
launched my ffmpeg download at 13:50 & it ended at 16:24, 2 hours & 34 minutes later.
Despite the different start & end times for the recordings, the resulting files are of
the identical duration.  I am using -live_start_index 0 as a parameter on my input file
in my ffmpeg command.  This rewinds the livestream to the beginning if I join it after it
has launched.  In the case of today's livestream, I managed to get VDH going just 1
minute after the livestream became available on the Medici web site.  I launched ffmpeg 4
minutes later.  Yet both files start with the exact same duration of video of the empty
stage gradually filling up with orchestra members & all the rest of the pre-show stuff.
You told me, Michel, that VDH would pick up a livestream from the moment that you launch
the recording, which means you would not get a recording of the livestream from the
beginning.  As far as I can tell, even though Medici does not provide the livestream to
the web page until 15 minutes before show time, my recordings today (and on other
occasions) appear to start before that 15 minute mark.  In addition, it looks like VDH is
rewinding to the start, same as ffmpeg.  I don't know if this is something unique to
Medici.  I do know that VDH rewinds the golf tournaments, but that's on another site,
where NBC seems to be using a somewhat different approach than Medici.  On Medici, I got
the exact same recording, every second of it, all of the pre-show stuff, all of the
concert, all of the intermission, & all of the about 6 minutes of black screen after the
closing credits, with both VDH & ffmpeg.  Are you sure you're not doing something to
rewind livestreams with VDH?  I know with ffmpeg, I was missing stuff until I discovered
-live_start_index 0.  So I know it's doing something.  But you said VDH doesn't do that.
My observation is that it does.  Is this something the server is doing?  Come on, Michel.
I've begged you to do this before.  Join Medici.  They're in Paris, practically next door
to you.  It's free.  Use them as a source of livestreams to test VDH.

[mig]

When you have HLS variants being offered for download, pick one and apply the "Details action" on it, then pick field hls and develop it to see the data. It might look like that:

{

"EXT-X-STREAM-INF": {

  "PROGRAM-ID": "1"

  "BANDWIDTH": "2193700"

  "RESOLUTION": "1920x1080"

  "FRAME-RATE": "23.974"

  "CODECS": "avc1.640028,mp4a.40.2"

  }

}

The RESOLUTION field is what is being displayed by VDH for the size of the video. Note that a video resolution might not be as accurate as you could think. Image encoding algorithms work on small square pieces with 8 or 16 pixels side. This means if the size does not match the appropriate modulo, it might show an approximated with or height depending on the application you use. This is generally not a big issue.

Once the file has been downloaded, VDH performs a call to the coapp-embedded ffprobe to update resolution and save the fps. So if you reapply the "Details" action to this entry, you should now see a new fps field and a possibly modified size.

Quite frankly, i don't know why the fps and resolution might be reported slightly differently depending on the application but it's ffmpeg (the one in the coapp package) that does this actual job when aggregating audio and video, not really VDH.

Regarding the starting point of the recording of a live stream, you must understand that VDH cannot see where you are in the playing. If you start a download, it will download the chunks that are described in the HLS manifest starting with the first one. We could have chosen to start with the last chunk then wait for new chunks to appear in the manifest but this could lead to the beginning of the stream being lost if the video player was currently displaying an older chunk.

[Wild Willy]

You're up late.  Glad to see you here anyway.

Details.  Never thought of that.  I'll have to try that on the next thing I download that has this funky 1912x1088 resolution.  I have seen the sort of thing you described but I've always looked at details of a hit before I tried downloading it.  I'll have to try that after a download completes & see if it fixes the file.  That would be a neat trick.  I hope it works.

As for the start of the livestream recording, I understand what you're saying.  So you got the beginning of the livestream, same as my ffmpeg recording did, because that's where the manifest said the first chunk was.  Like I said, I started this VDH recording barely a minute after the page updated to say the stream was live.  I should try waiting an hour & see what it does on Medici.  It so happened that I did record a round of golf today with this beta of VDH & I did launch it late, nearly an hour & a half.  But it still picked up the useless "Coverage will begin shortly" for about 55 minutes & then it recorded everything that had been streamed before I connected.  I'm sure this is a quirk of NBC & it's just too bad you can't do any testing with this.  But Medici is in your backyard.  You could test with their livestreams.  I will try waiting an hour or so on the next Medici livestream I record & then launching VDH to see what I get.  I already know ffmpeg will rewind on Medici.  I've done that a number of times.  But I'll have to try it with VDH & I'll let you know.

[Wild Willy]

One other thing I just noticed in what you said. You talked about how VDH might not be
starting its recording from the same position as where you were while playing the video
on the web page. I can see a certain logic in considering starting the VDH recording at
the point where you stopped playing the video on the web page. The thinking would be
well, you've already watched that so I (VDH) don't need to download it. I'm glad that's
not how it works. But in addition, Medici generally does not need you to launch
playback. Usually, it's enough to just reload the page at the moment the stream goes
live & poof magic, here comes a master manifest without having to click the Play button.
So any discussion of first or last or what you last played just isn't relevant. But you
don't use that in your decision of where to start so we're just talking about design
alternatives. It's good to exercise the brain every once in a while just for the fun of
it.

[mig]

I'm not sure i follow you. VDH does not have much information about where the video player is in the web page. It just detects the network request to the manifest and uses this URL to reload it regularly. Also, i don't think reloading the page would change anything as it won't change the content of the manifest.

[Wild Willy]

It seems you can't follow me because I misunderstood you. Never mind.

About reloading the page, the situation on Medici is like this. If you visit the page
for a livestream within a few hours before they open the stream, it shows a counter that
counts down to the time the show starts. When that counter gets to 15 minutes until show
time, you can reload the page & it will show that the stream is live. The counter will
be gone. On occasion, the counter counts down to 0 at 15 minutes before show time, & the
page automatically reloads to show the stream is live. It's 15 minutes before show time
but the stream will be available. Doing that reload, either manually or automatically,
causes the master manifest to appear in the Network Monitor. At the same time, of course
VDH detects it & populates its menu. These 2 events are intimately related, I understand
that. It's just that you don't even have to click the Play button in the player to make
this happen. Reloading the page is all it takes. But that observation was probably
relevant only in the context of my understanding of what you do as I understood things
when I made that post. Now I see that I didn't understand so it probably doesn't make
any difference.

Just out of curiosity, what can we expect in the next beta or general release, assuming
of course that annoying users don't keep pestering you with silly questions based on
faulty assumptions?

[Wild Willy]

I recorded golf livestreams both yesterday & today. Both days, I went through these
steps. On the main VDH menu before I launched the recording, I looked at the hit details
for the variant I was about to record. I expanded the HLS section, like you said. I
also scrolled down to the label SIZE. They both said the variant was 1920x1080.

Then I launched my recording. I went to the blue dot status menu & looked at the hit
details for the recording that was in progress. Once again, VDH reported in 2 places
that it was looking at a 1920x1080 video.

After the recording completed, I once again went to the main VDH menu & looked at the hit
details for the recording that was now on my hard drive. Once again, VDH reported in 2
places that it was looking at a 1920x1080 video.

The Windows Properties dialog reported the resolution as 1912x1088 both days. The files
are, of course, 1920x1080. VLC plays them just fine. It's just weird that this is
happening.

The frame rate is reported in the Windows Properties as 29fps. Ffprobe says it's
29.97fps. VLC says it's 29.970030fps. Windows is, of course, silly. It truncates the
number instead of rounding it. Obviously, the frame rate is more like 30fps. I think
30fps is the way most sources would refer to this video. At least this number is showing
up correctly in the Window Properties. Well, as correctly as Windows ever gets it.

[Wild Willy]

I did another parallel recording off Medici today. VDH & ffmpeg got the exact same
thing. The difference today was that the show started at 13:30 but it was after 15:00
when I launched the 2 recordings. They both recorded beginning at a time that was almost
2 hours before when I launched the recordings. So even though you're telling me, Michel,
that VDH won't rewind to the beginning of a livestream when you join it in progress, it
does appear to do exactly that. It's also true for the Golf Channel content. I don't
know how this is happening. You can't check this out with the NBC/Golf Channel
livestreams since that is a cable channel here in the US. Geographic restrictions & all
that rot. Plus it's not free. But Medici is a site you can get FREE access to in YOUR
country. You could investigate this. They don't have livestreams every day but they do
have them usually at least once a week. They're usually timed for after dinner viewing
in YOUR time zone, in fact, in YOUR country. You could look into this. Some, not all,
some livestreams that they say are for paid subscribers only are actually available for
free if you join them while they are actually live. They are for the paying subscribers
only after the fact, after the shows are archived on the site for on-demand viewing. So
you could look into how VDH is managing to rewind these livestreams even though you said
that wouldn't happen. It may be a side-effect of something the site is doing. I know
with ffmpeg, if I don't code the relevant parameter, I don't get the livestream from the
start. I get it from the moment I join the livestream in progress, like you said VDH
would do. So I suspect what happens is due to some combination of what the site tells
VDH & the way you record the livestreams. I'm not complaining. I just want to know if
this is a fluke, if I can expect this with any site.

Most reports on here about problems with livestreams can't be investigated. They're
one-off events. The problem reports are necessarily posted after it would be possible
for you to investigate them. But here's a site that regularly puts up livestreams that
are of a consistent nature. They can always be recorded with both VDH & ffmpeg. The
manifests are not off the wall weird. They are plain-jane box-standard HLS manifests.
You couldn't ask for better test cases. Please look into this. It is a free membership.
Truly. I've been trawling around there for a while now & I haven't paid them anything.
Never even gave them my credit card number. They get my E-mail address & I get pleasant
pseudo-spam from them a couple of times a week advertising what they have on their
schedule, along with subtle nudges to buy a subscription, which I easily ignore. In
particular, they E-mail you when a livestream is about to go live. They are a French
company based in Paris. It's not a trap. It's worth it to you to look into it.

Minor aside for mjs. I was at a doctor's appointment this afternoon at show time. I
launched these recordings, both the VDH one & the ffmpeg one, via my cell phone to remote
control my computer at home. You know how I did that. The amazing thing is the
ridiculously low data usage it reports on my phone. I happened to be connected to the
WiFi in the doctor's office. But with data usage so low, I wouldn't hesitate to do
something like this over the regular phone network. Not that it's particularly relevant
but I think my doctor has the same Internet service I do. His WiFi speed was the same as
what I have at home. So there was minimal lag. Other than the ridiculously small screen
a cell phone gives you, it was almost like astral projecting myself home. But it's
possible to compensate for the stupid small cell phone screen via the usual
thumb/forefinger gesture. I'm so glad you told me about this one. It's come in quite
handy on the odd occasion. Sadly, it hasn't been for the occasions we envisioned, but
that's been beyond our control.

[mjs]

That's unreal to be able to do that , I've never done something like this but that's what remote control software can do.

Another use case is a family member or friend has a problem with their computer and they aren't very good at using computers or technically

minded. You remotely connect to them to check out the problem and or walk them through the steps to fix it. Similar to an issue I had with the  anti-virus software.

I still think the screen sharing option could be useful if the person with the problem wants to do that. Very few if any do though.

[mig]

Willy: maybe i was not clear when explaining how VDH records HLS live streams, i'll do it again.

An  HLS broadcast is known by its m3u8 manifest. This manifest is a network downloadable document containing a list of media chunks that, when played sequentially, make the actual stream. This manifest is read periodically by VDH. If the video is static (non-live), like a movie, reading the manifest always returns the same document with the entire video in it. For a live stream, media chunks are regularly added to the list, while older ones might be removed (or not).

By default, when the user requests the download, VDH starts recording from the first chunk in the manifest to the last one. The manifest being read periodically, VDH queues new chunks that are added and considers the download as complete when no new media chunk has appeared in the manifest for a period of time.

If parameter HLS live history is set to true, VDH remembers all chunks that showed up in the manifest starting from when the media has been detected. When the recording is requested, VDH starts downloading from the first chunk in the history. In your case, you must make sure this parameter is set to false.

VDH does not rewind, it just starts from the beginning. If the manifest starts with 2 hours of a waiting screen, you'll get that in the recording. VDH is not smart enough to analyse the video and to detect that real action has started. Nor is VDH able to know what chunk is currently being played in the page, which is what you, as a site page visitor, consider as being the present time.

Another alternative would have been for VDH to, when starting the download, only consider the newly added chunks. My guess is that for that particular site, it would work as you expect, but on other sites, the beginning of the broadcast would end up being lost. Having to choose between too much and not enough recording, i preferred the first option.

What we might consider in a future release is to have a user configurable parameter to decide between starting from the first chunk and starting from the last one. That would not be a big deal to develop but it would only be useful for VDH experts like you.

Regarding the Medici site, i've been there several times but never saw a live show nor the announce of one. Where do they advertise for them ?

[Wild Willy]

I knew about how the master manifest points to a stream manifest (usually several stream
manifests, one for each resolution & maybe bit rate). I think the part I didn't quite
get is that the site is responsible for chunk 0 in the stream manifest. Evidently, for
both Golf Channel & Medici, their stream manifests routinely have chunk 0 pointing to the
beginning of the stream, which is not the time you open the page, not the time you launch
playback, but rather the time when you find that there is a variant on the VDH menu & a
master manifest in the Network Monitor of the browser. See, I don't usually launch
playback. "Now" is whenever I click the variant on the VDH menu or launch ffmpeg. "Now"
is not defined by what I am playing on the page because I am almost never playing
anything on the page. "Now" is defined by whenever I open the page to start recording
the stream. Today, I didn't do that until over 90 minutes after the show started, which
was nearly 2 hours after the livestream actually went live. Given how this works, it's
utterly no surprise that both VDH & ffmpeg recorded the exact same result. I just wish
NBC didn't have to give me an entire hour of "Coverage will begin shortly." You'd think
10 minutes of that, 15 minutes max, would be quite sufficient. But VDH is just the
messenger. That's what their manifest says is chunk 0 so what I've been getting is what
I'm supposed to be getting. That's why they invented fast forward in video players,
right?

I think I've been thrown off by this ffmpeg parameter -live_start_index 0. It must be
that ffmpeg is aware of the stuff about "now" vs "beginning" that you're telling me VDH
pays no attention to. I like the way VDH works, now that I understand it. I do not have
that HLS live history box checked. I've never had it checked. I'm not sure I'm quite
the expert you think I am. I don't see a reason to check that box. I also don't see a
reason to change the way VDH fiddles with what chunk it starts recording at. I say
always go to chunk 0 & be done with it.

But this means that it is the web site determining chunk 0. I sort of had that figured
out but wasn't verbalizing it that way. I can imagine a web site continually adjusting
its stream manifest so that chunk 0 keeps getting updated to a later & later chunk.
Meaning, if you didn't get into the livestream early enough, you're out of luck. I could
see something like that for a long stream, like a live radio station. I can imagine that
chunk 0 of the stream manifest would never be older than a couple of hours. I don't know
if that's true. I'm just reasoning it out. I could see this approach with something
like one of those web cams that's set up in a cage in a zoo to monitor, I don't know, a
newborn panda or something. Surely for them, chunk 0 is never more than 6 hours ago, or
maybe 24 hours, tops. But no matter how the site manages their chunk 0, VDH should
simply start recording there. If that's not actually the start of the livestream, hey,
you didn't tune in soon enough. But we should be grateful NBC & Medici do it that way.
Their content is normally shows of a few hours, anywhere from 2 to 6 hours. Chunk 0 is
never a prohibitively long time in the past like it would be for the radio station or
cage-cam.

On Medici, I start here:

https://www.medici.tv

This automatically changes to this:

https://www.medici.tv/en/

I should imagine for you, it changes to this:

https://www.medici.tv/fr/

Just for grins & giggles, I went to that page. Here's a sequence of what I'm seeing
right now.

[Wild Willy]

Oops. Typo in image #02. I meant to say . . .

Despite the gold button, the stream might be FREE if you tune in during the show.

And please, Michel, read up on stealth quoting:

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