Speed-cap and progress math use a hard-coded 320 kbps assumption instead of the track's real bitrate #16

New issue

Open

opened 2026-07-06 16:34:33 +02:00 by maleszka · 0 comments

maleszka commented

2026-07-06 16:34:33 +02:00

Owner

Summary

The speed-cap throttle and all UI progress math (position, percentage, ETA, speed multiplier) assume every track is encoded at a flat 320 kbps, via the hard-coded constant OGG_320_BYTES_PER_SEC = 40_000 (bytes/sec) in src/download/worker.rs. This value is passed unconditionally regardless of which audio format a given track actually resolves to.

This also contradicts specs/core_architecture.md, which currently documents Track.duration_secs as the input to speed-cap byte-rate calculation — that is not what the code does today.

Details

src/download/worker.rs:19 defines OGG_320_BYTES_PER_SEC: u64 = 40_000.
It is passed as audio_bytes_per_sec into write_stream's speed-cap throttle (worker.rs:250-254) unconditionally, from both src/download/session.rs:129 (interactive mode) and src/cli/script.rs:106 (script mode).
The UI (src/ui/progress.rs:239,249) uses the same constant — not track.duration_secs — to derive percentage, position ("elapsed"), ETA, and the speed multiplier for every entry.
The real per-track bitrate is already resolved once, during open_stream, in src/provider/spotify/stream.rs:83-84 (select_audio_format → bps), but this value is never surfaced back to the worker or the UI — it's discarded after Stage 1 starts.
Net effect: for any track whose real encoded format isn't 320 kbps OGG Vorbis (e.g. a fallback to 160 kbps or 96 kbps when 320 kbps isn't available), the speed cap throttles to the wrong absolute rate, and the UI's percentage, position, ETA, and multiplier are all computed against the wrong reference rate.

Proposed fix

Thread the real per-format byte rate (already computed in src/provider/spotify/stream.rs as bps) through to the worker and the UI, replacing the hard-coded OGG_320_BYTES_PER_SEC constant at both call sites. Alternatively/additionally, correct specs/core_architecture.md's existing claim so the doc matches whichever behavior is implemented.

## Summary The speed-cap throttle and all UI progress math (position, percentage, ETA, speed multiplier) assume every track is encoded at a flat 320 kbps, via the hard-coded constant `OGG_320_BYTES_PER_SEC = 40_000` (bytes/sec) in `src/download/worker.rs`. This value is passed unconditionally regardless of which audio format a given track actually resolves to. This also contradicts `specs/core_architecture.md`, which currently documents `Track.duration_secs` as the input to speed-cap byte-rate calculation — that is not what the code does today. ## Details - `src/download/worker.rs:19` defines `OGG_320_BYTES_PER_SEC: u64 = 40_000`. - It is passed as `audio_bytes_per_sec` into `write_stream`'s speed-cap throttle (`worker.rs:250-254`) unconditionally, from both `src/download/session.rs:129` (interactive mode) and `src/cli/script.rs:106` (script mode). - The UI (`src/ui/progress.rs:239,249`) uses the same constant — not `track.duration_secs` — to derive percentage, position ("elapsed"), ETA, and the speed multiplier for every entry. - The real per-track bitrate is already resolved once, during `open_stream`, in `src/provider/spotify/stream.rs:83-84` (`select_audio_format` → `bps`), but this value is never surfaced back to the worker or the UI — it's discarded after Stage 1 starts. - Net effect: for any track whose real encoded format isn't 320 kbps OGG Vorbis (e.g. a fallback to 160 kbps or 96 kbps when 320 kbps isn't available), the speed cap throttles to the wrong absolute rate, and the UI's percentage, position, ETA, and multiplier are all computed against the wrong reference rate. ## Proposed fix Thread the real per-format byte rate (already computed in `src/provider/spotify/stream.rs` as `bps`) through to the worker and the UI, replacing the hard-coded `OGG_320_BYTES_PER_SEC` constant at both call sites. Alternatively/additionally, correct `specs/core_architecture.md`'s existing claim so the doc matches whichever behavior is implemented.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

maleszka/librespot-dl#16

No description provided.

Rows
Columns