addAudioStreamsToVideo: Populate video.fullAudioData with the item's audio tracks.

Sources from the original item metadata (meta.mediaSourcesData), not from the PlaybackInfo response. The /PlaybackInfo response can return a transcode-shaped MediaSource carrying only the chosen audio stream, which would shrink the OSD picker to a single entry (issue #500). The OSD picker must always list every original track so the user can switch.

Add next episodes to the playback queue

fetchMostRecentVersionId: Ask the server which of an item's versions it would resume.

The resume query returns the version that owns the resume point, which is the answer the source order gives only from a primary (see versionResume.chooseResumeSource). Scoped to the item's parent (its season, or the folder holding a movie), so the reply is that parent's in-progress items rather than the whole of Continue Watching, and lean, because only ids are read.

answer, so the caller falls back to the order instead of asking again

fetchVersionPositions: Read each named version's own position into positions.

A version that does not answer is recorded as POSITION_UNREADABLE rather than left absent, so the caller's next pass cannot ask for it again and loop, and so an unread position is never mistaken for "this version has no progress", which would silently restart the content.

reloadProbedStreams: Replace the item's media sources with the ones the server saved when the first PlaybackInfo probed them. Leaves meta as it was when the read fails, so the caller's picks stand and nothing else changes.

resolveResumeVersion: Which of an item's versions resumes, and from where.

The imperative shell around versionResume.chooseResumeSource(): that function owns every rule and says what it still needs; this fetches it and asks again. Same division as ItemDetails, so both entry points reach an identical answer. The split between them is what made the app name one version on the details screen and play another.

Reads ride apiPipeline rather than a fetch loop: the pipeline keeps as many requests on the pool as it has slots, so N versions cost roughly one round trip instead of N. Each reply was ~150 bytes against the item's ~17 KB (measured 2026-09-19), and nothing is fetched at all unless something is already in progress, so an item nobody has started costs no requests on the playback path. When the source order cannot say which version was played last, one more request asks the server (fetchMostRecentVersionId).

setupVideoContentWithAuth: Configures video content URL and applies authentication

Determines the appropriate URL based on protocol and stream location, then applies Jellyfin authentication headers for internal streams. External streams (non-localhost) receive the raw URL without authentication to prevent credential leakage.

Protocol handling:

• "file": Direct stream from Jellyfin server (gets auth)
• Non-file with localhost domain: Proxied through Jellyfin (gets auth)
• Non-file with external domain: Direct external URL (NO auth)

upstreamManifestAnswers: Whether THIS device can load a source's upstream manifest URL.

The device check before playing a source from its own URL (getUpstreamManifestBlocker). The server reaching a URL says nothing about the Roku reaching it, and a Roku handed one it cannot reach does not error: an unroutable host or an unresolvable name leaves it buffering, so the direct-play fallback does not run. A GET within timeouts.UPSTREAM_PREFLIGHT_MS that returns a manifest of the declared format is the answer (isUpstreamManifestResponse); anything else uses the server's stream. Raw roUrlTransfer on this Task thread, no Jellyfin auth (the URL is not Jellyfin's) and the URL is never logged, because upstream URLs carry session tokens.