Type Alias: Retryable
type Retryable = boolean;
Defined in: packages/player/src/errors.ts:88
Whether repeating the identical operation could plausibly succeed with nothing else changed.
Remarks
Present on every member of PlayerError — that is the point: an app that wants "retry on transient failures" should read this field rather than maintain its own table of codes, which is how such tables go stale. It is also what PlayerOptions.retry consumes to decide whether a failed entry gets another attempt before the queue advances.
The classification, and the reasoning behind each row:
| code | retryable | why |
|---|---|---|
network | true | a dropped connection, a premature EOF, a CDN hiccup — the definition of transient |
unsupported-format | false | no demuxer/codec exists in this binary; a second attempt runs the same code |
load-failed | false* | see below |
disposed | false | an app bug, and the object is gone |
invalid-state | false | the argument was rejected before mpv saw it; the same argument is rejected again |
unsupported | false | the operation does not exist in the audio core |
mpv | per errno | see isRetryableErrno |
* load-failed is false on the classified path, and that is a fact
about the classifier rather than a policy. classifyEndFile splits a
failed open on isNetworkUri: a network URI becomes network, and
everything else becomes load-failed. So a load-failed produced from an
end-file is by construction never a network source — it is a local file
that is missing or unreadable, or a source whose URI was not known at all.
Neither improves by being asked twice in a row.
The one load-failed that carries a real URI is the source-resolver failure
(SourceResolverController), which builds the error itself and sets this
field from isNetworkUri of the URI it was asked to resolve — a signing
endpoint that timed out genuinely is worth another go.
retryable is advice about one repetition, not a promise. It never means
"this will work"; it means "asking again is not obviously pointless".