Skip to content

Duplicate timelineregionenter and timelineregionexit events fired for the same event id. #8009

@git-archs

Description

@git-archs

Have you read the FAQ and checked for duplicate open issues?
Yes

If the problem is related to FairPlay, have you read the tutorial?

Not related to fairplay

What version of Shaka Player are you using?

4.7.0

Can you reproduce the issue with our latest release version?
Haven't tried it.

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

Are you using the demo app or your own custom app?
Custom App

If custom app, can you reproduce the issue using our demo app?
Working on getting a clear content url to try in the demo app.

What browser and OS are you using?
Chrome, Linux

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

What are the manifest and license server URIs?

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?

What did you do?

There is a live manifest being played by shaka, which has Server Side Dynamic ads inserted. The Ads period is having event Streams with unique ids. The manifest is parsed every 5 seconds.There are listeners attached for the following two events:
1.timelineregionexit
2.timelineregionexit
It is observed that for the same ad(Event Stream), there are two different events created by shaka, because they have the same event details except for the end time. During the manifest parsing, the duration of the event is created either by the period duration or the event duration. In most cases, the period duration is the event duration, which is typically calculated by the difference between start times of two periods. In case when this event is part of the last period, the typical period time calculation does not satisfy due to the non existence of the next period and the duration of the event is used instead. In the next set of parsings when the ad period is followed by another period, the period duration is used, and if its different than the original one already added, another event is included and it returns in generation of more than one events for the same event(ad).

Given below is a set of examples.
SET 1:(2025-01-30 11:39:21.282)
Event is created for ID 2616140790 with the given start and end times:
startTime 29023.231,endTime:29038.231

SET 2:(2025-01-30 11:39:36.471)
Event is created for ID 2616140790 with the given start and end times:
startTime 29023.231, endTime:29038.207"

At first the timelineregionenter event came for Set 1, and then it came again for the set 2. Similarly timelineregionexit events came twice.

Here is the logic for identifying similar region.Shaka player is treating these events as two unique events, as the logic is comparing end time as well. In this scenario the difference is really small for the end time.
findSimilarRegion_(region) {
for (const existing of this.regions_) {
// The same scheme ID and time range means that it is similar-enough to
// be the same region.
const isSimilar = existing.schemeIdUri == region.schemeIdUri &&
existing.id == region.id &&
existing.startTime == region.startTime;

  if (isSimilar) {
    return existing;
  }
}

return null;

}

What did you expect to happen?
The event should come only once, as it is the same event. I understand there is a slight difference in the end time, but while adding this event to the region timeline, there should be only one event included. So the latest one should overwrite. Since the enter event is already fired, there cannot be another enter event.

What actually happened?

Two start and two end events came instead of one.
SET 1:(2025-01-30 11:39:21.282)
Event is created for ID 2616140790 with the given start and end times:
startTime 29023.231,endTime:29038.231

SET 2:(2025-01-30 11:39:36.471)
Event is created for ID 2616140790 with the given start and end times:
startTime 29023.231, endTime:29038.207"

Are you planning to send a PR to fix it?
Not yet. In my case removing the check for endTime from the logic of determining similar region fixes the problem. this is not the right approach, and I have to check how likely it is in the real case scenario to have a different end time. Ideally overwriting the region is a better approach, but the issue is the Period with the event is already playing and the start event has been triggered. Have to explore the implication of what will happen if this is overwritten. Can the start event be still ignored as the startTime has not changed, and only end event is triggered with the latest end time.

Metadata

Metadata

Assignees

Labels

priority: P2Smaller impact or easy workaroundstatus: archivedArchived and locked; will not be updatedtype: bugSomething isn't working correctly

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions