Variable: DEFAULT_RESOLVER_TIMEOUT_MS

const DEFAULT_RESOLVER_TIMEOUT_MS: 10000 = 10_000;

Defined in: packages/player/src/source-resolver.ts:88

Default resolverTimeoutMs: how long a play-time miss may hold mpv's core.

The hold is safe at play time — the entry has not opened yet, so there is no audio of its own to starve, and the previous entry has already ended — but it is still a stall with nothing on screen moving, so it is bounded. Ten seconds is a network round-trip plus a retry, and it is far short of the point where a user concludes the app has hung.

Note this budget applies to the play-time path only. The prefetch path never waits, at any timeout: it fires mid-track over live audio backed by ~0.2–0.8 s of device buffer (ARCHITECTURE §12), so a miss there is answered by continuing mpv immediately and warming the cache for the play-time pass.

The hold parks the event thread, and that is the honest cost. The wait is taken by the thread that drains mpv's event queue, so while it runs no property change and — this is the part that surprises people — no command reply reaches JavaScript. A seekTo() or play() Promise issued during an unresolved play-time load can therefore stay pending for up to this long. Nothing is lost (the replies arrive as soon as the hold ends) and nothing can hang forever (the budget is the bound), but the latency is real. Resolve-ahead exists to keep this path cold: with the current and next entries answered as the queue moves, a play-time miss should be the exception, and an app that cannot tolerate the stall at all can set the budget to 0 and rely on the pre-warmed cache alone.