Variable: LIVE_EOF_BUDGET_RESET_SECONDS

const LIVE_EOF_BUDGET_RESET_SECONDS: 30 = 30;

Defined in: packages/player/src/player.ts:1524

How long a live entry must play, after a RetryOptions.retryLiveEof re-attempt, before its attempt budget starts over.

Remarks

30, and the number is chosen against two bounds rather than picked:

• It must be longer than a reconnect loop can plausibly take, or a server that accepts a connection and immediately hangs up would reset the budget on every cycle and retry forever — the exact bug this constant exists to prevent. Such a cycle completes in well under a second; even layer 1 gives up after ~4 s at the default reconnect_delay_max of DEFAULT_RECONNECT_DELAY_MAX_SECONDS. 30 s clears that by an order of magnitude.
• It must be shorter than any real listening session, so a station that drops once an hour recovers every time instead of exhausting a budget it spent months ago. Half a minute of continuous audio is the smallest interval nobody would call "it never really played".

It is deliberately the same number as DEFAULT_CACHE_SECS, which makes it say something concrete rather than arbitrary: the entry played for longer than the audio the player is willing to hold, so what the listener heard came from the network over time and not from one cache fill.

Measured as wall-clock since the restart, not decoded seconds: a live stream that is playing advances both at the same rate, and reading time-pos instead would put a synchronous mpv round-trip on a failure path (see #handleBatch's read budget) to learn something this already knows.