Refactor GridScheduleGenerator and related components to improve cursor management and group handling
ci / build-backend (push) Successful in 1m17s
ci / build-frontend (push) Successful in 56s
ci / tests (push) Successful in 1m29s
ci / sonar (push) Successful in 3m34s

Updated the GridScheduleGenerator to reset cursors for slots with no aired positions, ensuring proper state management during rebuilds. Introduced a new method, ResetUnairedCursorsAsync, to handle cursor resets effectively. Enhanced the handling of interstitial groups in the scheduling process, preventing them from being included in slots or fallback groups. Updated related tests to verify the correct behavior of these changes, ensuring robust scheduling logic and accurate group categorization.
This commit is contained in:
Leonid Pershin
2026-07-30 09:55:14 +03:00
parent 5032614773
commit 398b60facc
14 changed files with 317 additions and 31 deletions
+9
View File
@@ -150,6 +150,15 @@ BuildLiveWindow(расписание, филлер, now, windowSegments, segment
UTC; локальный пояс показывает фронтенд. Раздача встык — типичный случай без филлера; филлер
подставляется только при пустом расписании.
**Плеер возвращается к живому краю сам.** Окно короткое, а вкладка в фоне живёт по другим правилам:
браузер душит таймеры, hls.js не успевает тянуть сегменты, видео доигрывает буфер и встаёт. Пока
зритель не смотрит, окно уходит вперёд на сколько угодно — и, вернувшись, он увидел бы программу,
которая в эфире давно кончилась. Поэтому отставание больше 30 секунд плеер закрывает прыжком на
живой край (`liveSyncPosition`, в нативной ветке — конец `seekable`), а не догоном: эфир общий
и неперематываемый, догнать его нельзя, можно только застать. Проверка — на каждом обновлении
медиаплейлиста и на возврате вкладки; после сетевого сбоя загрузка тоже возобновляется с края,
а не с позиции, на которой всё встало.
Это самая ответственная часть системы, покрывается юнит-тестами: границы записей, вставка рекламы,
монотонность `MEDIA-SEQUENCE`, правка хвоста на лету, вывод «следующей серии» из расписания.
Нагрузка на API при 10 зрителях — ~5 запросов/с за сегментами и ~5 за плейлистами, пренебрежимо.