Variable: OBSERVED_PROPERTIES

const OBSERVED_PROPERTIES: readonly ObservedProperty[];

Defined in: packages/player/src/properties.ts:348

Every property the Player observes, with the format it observes it in. This is the complete set — time-pos is deliberately absent (see the position-projection contract in docs/specs/player-core.md §3).

Remarks

playlist-pos and playlist-count are int64 properties observed as number: mpv/client.h guarantees that "MPV_FORMAT_INT64 is always converted to MPV_FORMAT_DOUBLE", so this is lossless for any playlist that fits in a double's integer range.

loop-file/loop-playlist are observed as string because their value domain is "no" | "inf" | <count> — no numeric format can represent it.

seekable is a yes/no property (partially-seekable's entry in mpv's input.rst states "If this property returns yes/true, so will seekable"), so it is observed as bool. It is what tells a live stream apart from a finite one — see PlayerState.isLive.

metadata is observed as string only to learn that the tag map changed — the value is dropped on the floor, never parsed. mpv's own manual says the property cannot be read as a raw string, so nothing may depend on what that string contains; the typed map is rebuilt from metadata/list/… instead. Together with media-title (which mpv invalidates on the same MP_EVENT_METADATA_UPDATE, player/command.c) it is what drives the metadataChanged event.

Three of these are observed for state fields that only ever move when something asks them to, so each costs one event at startup and nothing afterwards: pitch and chapter change on an app call or a chapter boundary, and chapter is simply unavailable on a file with no chapters. cache-buffering-state is the exception — mpv republishes it while a stall is filling — which is why the reducer quantises it and publishes it only while the player is actually stalled (PlayerState.bufferingPercent), the same treatment demuxer-cache-time gets and for the same reason.