What happens
Every session resolves its disk allowance alone: min(2 GiB, a quarter of the tmp volume's free space), measured once at session start (HLSVideoEngine.sessionRetentionBudgetBytes, also used by the software live ring and the software VOD read-ahead).
Since 7.25.0 a host may run several engines at once (Sodalite's live multiview runs up to four). Each of them measures the same free space and takes a quarter of it, because a claim another session has made but not yet written is still "free" at that moment:
| free at start |
one session |
four sessions started together |
| 32 GiB |
2 GiB |
8 GiB |
| 8 GiB |
2 GiB |
8 GiB, the whole volume |
| 4 GiB |
1 GiB |
4 GiB, the whole volume |
The quarter-of-free-space clamp exists so that a nearly full device never trades playback headroom for seek history. With four sessions it protects nothing: four quarters are the volume. A failed segment write degrades to a cache miss and stalls playback, on all tiles at once.
Expected
A session's allowance is a quarter of what is really left: the free space minus what the other running sessions may still write. One session alone gets exactly what it gets today. Several sessions together can never claim the whole volume (n sessions leave at least (3/4)^n of it), and the live window already follows the allowance it is given (LiveWindowSizing.affordableSegments, AE#443), so a smaller share shortens the timeshift depth instead of breaking it.
Scope
- one process-wide ledger of the running sessions' claims, used by all three call sites (native session, software DVR ring, software VOD read-ahead)
- a claim is released when its session stops
- no public API change
Found while building Sodalite#175 (live multiview).
What happens
Every session resolves its disk allowance alone:
min(2 GiB, a quarter of the tmp volume's free space), measured once at session start (HLSVideoEngine.sessionRetentionBudgetBytes, also used by the software live ring and the software VOD read-ahead).Since 7.25.0 a host may run several engines at once (Sodalite's live multiview runs up to four). Each of them measures the same free space and takes a quarter of it, because a claim another session has made but not yet written is still "free" at that moment:
The quarter-of-free-space clamp exists so that a nearly full device never trades playback headroom for seek history. With four sessions it protects nothing: four quarters are the volume. A failed segment write degrades to a cache miss and stalls playback, on all tiles at once.
Expected
A session's allowance is a quarter of what is really left: the free space minus what the other running sessions may still write. One session alone gets exactly what it gets today. Several sessions together can never claim the whole volume (n sessions leave at least
(3/4)^nof it), and the live window already follows the allowance it is given (LiveWindowSizing.affordableSegments, AE#443), so a smaller share shortens the timeshift depth instead of breaking it.Scope
Found while building Sodalite#175 (live multiview).