[GH-ISSUE #125] Panic when switching to short track from long current progress in longer track #71

New issue

Closed

opened 2026-02-28 14:46:47 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 14:46:47 +03:00

Owner

Originally created by @sputnick1124 on GitHub (Nov 1, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/125

Reproduce

After playback on a long track has attained x seconds, switch to track with duration y where y < x

Symptom

Panic

thread '<unnamed>' panicked at 'Percentage should be between 0 and 100 inclusively.', /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.6.2/src/widgets/gauge.rs:47:9
stack backtrace:
...
   3: std::panicking::begin_panic
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:408
   4: tui::widgets::gauge::Gauge::percent
             at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.6.2/src/widgets/gauge.rs:47
   5: spt::ui::draw_playbar
             at src/ui/mod.rs:677
   6: spt::ui::draw_main_layout
             at src/ui/mod.rs:161z
...

The issue seems to be that the track duration and progress numbers are updated at different times/places, so the app tries to update the progress bar with previous track's duration over the new track's duration, resulting in a panic from tui-rs's Gauge widget.

Simply placing a bandage on the problem by limiting the percentage to 100% maximum elicits a panic in a different place for the same reason

            let perc = if app.song_progress_ms < track_item.duration_ms.into() {
                (app.song_progress_ms as f64 / f64::from(track_item.duration_ms)) * 100_f64
            } else {
                100.0
            };

thread '<unnamed>' panicked at 'attempt to subtract with overflow', src/ui/util.rs:52:39
stack backtrace:
...
   6: core::panicking::panic
             at src/libcore/panicking.rs:49
   7: spt::ui::util::display_track_progress
             at src/ui/util.rs:52
   8: spt::ui::draw_playbar
             at src/ui/mod.rs:690
...

where github.com/Rigellute/spotify-tui@06d7b91164/src/ui/util.rs (L52)
panics because of a negative unsigned result.

Originally created by @sputnick1124 on GitHub (Nov 1, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/125 # Reproduce After playback on a long track has attained `x` seconds, switch to track with duration `y` where `y < x` # Symptom Panic ``` thread '<unnamed>' panicked at 'Percentage should be between 0 and 100 inclusively.', /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.6.2/src/widgets/gauge.rs:47:9 stack backtrace: ... 3: std::panicking::begin_panic at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:408 4: tui::widgets::gauge::Gauge::percent at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.6.2/src/widgets/gauge.rs:47 5: spt::ui::draw_playbar at src/ui/mod.rs:677 6: spt::ui::draw_main_layout at src/ui/mod.rs:161z ... ``` The issue seems to be that the track duration and progress numbers are updated at different times/places, so the app tries to update the progress bar with previous track's duration over the new track's duration, resulting in a panic from tui-rs's `Gauge` widget. Simply placing a bandage on the problem by limiting the percentage to 100% maximum elicits a panic in a different place for the same reason ```rust let perc = if app.song_progress_ms < track_item.duration_ms.into() { (app.song_progress_ms as f64 / f64::from(track_item.duration_ms)) * 100_f64 } else { 100.0 }; ``` ``` thread '<unnamed>' panicked at 'attempt to subtract with overflow', src/ui/util.rs:52:39 stack backtrace: ... 6: core::panicking::panic at src/libcore/panicking.rs:49 7: spt::ui::util::display_track_progress at src/ui/util.rs:52 8: spt::ui::draw_playbar at src/ui/mod.rs:690 ... ``` where https://github.com/Rigellute/spotify-tui/blob/06d7b91164f0640dbdf770113f623ec8aea5f4f2/src/ui/util.rs#L52 panics because of a negative unsigned result.