Timed metadata are raised all at once when loading a Live DASH DAI stream in a middle of an ad break (4.3.6)

[thomthomgo]

Have you read the FAQ and checked for duplicate open issues?
Yes. I found this issue from 2020, but:

• This issue was only reproducible after a long period of streaming (20, 30 minutes), while I'm experiencing it immediately.
• I'm using a more recent version of shaka.

What version of Shaka Player are you using?
4.3.6 and 2.3.7 (on the DAI Video Suite Inspector)

Can you reproduce the issue with our latest release version?
Yes (4.3.6).

Can you reproduce the issue with the latest code from main?
Yes

Are you using the demo app or your own custom app?
I first experienced the issue on a custom app using the DAI API.
I then reproduced it on the DAI IMA HTML5 Video Suite Inspector.

If custom app, can you reproduce the issue using our demo app?
Yes, using the DAI IMA HTML5 Video Suite Inspector.

What browser and OS are you using?
Mac OS 13.3.1 / Chrome 112.0.5615.137 (Official Build) (x86_64)

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
URI: https://dai.google.com/linear/dash/pa/event/PSzZMzAkSXCmlJOWDmRj8Q/stream/f61416c6-50b8-40df-9c3f-3cb1c312975a:BRU/manifest.mpd

What configuration are you using? What is the output of player.getConfiguration()?
No specific configuration is added to the default.

What did you do?

1. Visit https://googleads.github.io/googleads-ima-html5-dai/vsi/
2. Enter this asset key PSzZMzAkSXCmlJOWDmRj8Q (official sample LIVE DASH) and select dash
3. Click on load. You don't need to start playing the stream.
4. You should land in a middle of an ad break to reproduce issue. If not, reproduce step 3 until you do.

What did you expect to happen?

Timed metadata events should be fired progressively, as they are being raised in the stream.

What actually happened?

A bunch of events are raised all at once when the stream is loaded (not played):

Stream event: streamInitialized
Stream event: loaded
Stream ID: f61416c6-50b8-40df-9c3f-3cb1c312975a:BRU
Stream event: adBreakStarted
Stream event: started
Stream event: firstquartile
Stream event: midpoint
Stream event: thirdquartile
Stream event: complete
Stream event: started

[theodab]

I'm not 100% sure, but I think what is going on is that if we load a manifest and there is a region that is before the playhead, we count that as having skipped the region.
And when we skip a region, we fire both timelineregionenter and timelineregionexit events. See here:

shaka-player/lib/player.js

Lines 2949 to 2962 in 70823f9

	regionObserver.addEventListener('skip', (event) => {
	/** @type {shaka.extern.TimelineRegionInfo} */
	const region = event['region'];
	/** @type {boolean} */
	const seeking = event['seeking'];
	// If we are seeking, we don't want to surface the enter/exit events since
	// they didn't play through them.
	if (!seeking) {
	this.onRegionEvent_(
	shaka.util.FakeEvent.EventName.TimelineRegionEnter, region);
	this.onRegionEvent_(
	shaka.util.FakeEvent.EventName.TimelineRegionExit, region);
	}
	});

I can think of a few possible solutions to this on our part, offhand.

1. Add a timelineregionskip event instead of firing both an enter and exit event.
2. Add a configuration value to ignore skipped regions, or something like that?
3. Attach an additional data value to the timelineregionenter and timelineregionexit events that tells you if they are actually representing a skipped region. You could then read that value, and ignore those events as appropriate.

[joeyparrish]

I like adding a skip event, personally. @thomthomgo, would that work for you?

[thomthomgo]

Thanks for looking into this. +1, a skip event would better describe the player behaviour.

[theodab]

The solution I proposed initially ended up not being ideal. It turns out that, since the regions in your stream all have 0 duration, we technically skip over them even in the "normal" case. So making a new skip event didn't help, since it would fire all of the time.

Anyway, while looking for a better solution, I think I found an underlying bug. Sometimes, I think based on how long the stream takes to load, we start checking for regions before the media element's currentTime is set. So when the time is moved to the live head, the region observer ends up thinking we went from time=0 to the live head, and triggers all regions that are between those two points.

So I have made a fix for that instead.

[thomthomgo]

Thanks so much for looking into this! Do you happen to know what is the target release date for 4.4.0? Thanks!