Module estimate 

How big a download is going to be when the server will not say.

A direct copy answers with Content-Length, and the worker reports exact progress from it. A transcode is produced as it is sent — chunked, with no length — and the worker used to report progress: 0.0 for its whole duration: an empty bar and “0%” while the byte count climbed for an hour. That is the case every film whose audio must be re-encoded lands in.

The backend does know enough to estimate. It fetches the item to decide the audio policy anyway, and that item carries the source’s size and runtime; the preset it chose fixes the bitrate. So the estimate is made where the URL is, persisted on the row as its file_size, and used only as a fallback: a real Content-Length always wins, and an estimated bar never claims completion.

TRACES: UR-071 | DR-290

Structs

ProgressTotal

What the progress bar measures against.

Constants

ESTIMATED_PROGRESS_CEILING

The progress bar never reports more than this from an estimate, so a source that encodes a little larger than predicted shows 99% until the last byte rather than 104% — completion is the worker’s to announce.

TICKS_PER_SECOND 🔒

Ticks per second in Jellyfin’s runtime unit.

Functions

expected_download_bytes

The size a download for quality is expected to produce, in bytes.

progress_fraction

The fraction complete, in 0.0..=1.0. An estimated total is capped at ESTIMATED_PROGRESS_CEILING so a prediction that ran low never shows a finished bar on a download still running.

progress_total

The total to report progress against, given what the response said and what was predicted before it was made. The server’s Content-Length always wins; the estimate fills in only when the server sent none.