Skip to content

Fix getPeriodForTime util #1738

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 3, 2025
Merged

Fix getPeriodForTime util #1738

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
47a4322
Fix `getPeriodForTime` util
peaBerberian Sep 2, 2025
0bca6a3
in StreamOrchestrator, re-compute nextPeriod to be sure
peaBerberian Sep 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions src/core/stream/orchestrator/stream_orchestrator.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -175,6 +175,16 @@ export default function StreamOrchestrator(
return;
}

const getNewBasePeriod = (): IPeriod | undefined =>
manifest.getPeriodForTime(time) ?? manifest.getNextPeriod(time);

let nextPeriod = getNewBasePeriod();
if (!isNullOrUndefined(nextPeriod) && periodList.has(nextPeriod)) {
// Last check just for resilience reasons that the wanted Period is
// not one of the already-handled ones
return;
}
Copy link
Collaborator Author

@peaBerberian peaBerberian Sep 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: This was the part just for resilience, as I was under the impression that the edge case of:

  • time is exactly at a Period's end
  • next Period is later (there's a discontinuity currently)

Was not properly considered here, but I never reproduced an issue with it.

Only risk that I can think of from that update is that we now compute nextPeriod before the periodStreamCleared() callback and currentCanceller.cancel() both which may perform unknown side-effects.

We could also just re-compute nextPeriod there - at the expense of code readability - as you wish.

Copy link
Collaborator Author

@peaBerberian peaBerberian Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I finally chose to just re-compute it.


log.info(
"Stream",
"Destroying all PeriodStreams due to out of bounds situation",
Expand All @@ -190,8 +200,9 @@ export default function StreamOrchestrator(
currentCanceller = new TaskCanceller();
currentCanceller.linkToSignal(orchestratorCancelSignal);

const nextPeriod =
manifest.getPeriodForTime(time) ?? manifest.getNextPeriod(time);
// As previous callbacks may have performed unknown side-effects, just
// re-compute the next Period now.
nextPeriod = getNewBasePeriod();
if (nextPeriod === undefined) {
log.warn("Stream", "The wanted position is not found in the Manifest.");
enableOutOfBoundsCheck = true;
Expand Down
3 changes: 2 additions & 1 deletion src/manifest/utils.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,7 +139,8 @@ export function getPeriodForTime(
time: number,
): IPeriod | IPeriodMetadata | undefined {
let nextPeriod = null;
for (const period of manifest.periods) {
for (let i = manifest.periods.length - 1; i >= 0; i--) {
const period = manifest.periods[i];
if (periodContainsTime(period, time, nextPeriod)) {
return period;
}
Expand Down
Loading