Inconsistent time adjustment in player progress bar #434

New Issue

2026-04-24T23:22:56+02:00

adam commented

2026-04-24 23:22:56 +02:00

Originally created by @lkiesow on GitHub (Feb 4, 2023).

In the player, the chapter progress bar's time values are inconsistent:

The elapsed time is the time passed based in a normal playback speed
The remaining time is adjusted by the playback speed factor

This is quite confusing since e.g. if the progress bar shows a progress of about 50%, the elapsed and remaining time values differ. That is hard to understand if you don't already know what is happening.

I would expect the values to be consistent. Either both or none should be adjusted.

App version 0.9.61-beta

Originally created by @lkiesow on GitHub (Feb 4, 2023). In the player, the chapter progress bar's time values are inconsistent: - The elapsed time is the time passed based in a normal playback speed - The remaining time is adjusted by the playback speed factor This is quite confusing since e.g. if the progress bar shows a progress of about 50%, the elapsed and remaining time values differ. That is hard to understand if you don't already know what is happening. I would expect the values to be consistent. Either both or none should be adjusted. <img width="400" src="https://user-images.githubusercontent.com/1008395/216732709-19e3cd5e-c271-4b6d-a50b-28d2beaa4481.jpg" /> App version 0.9.61-beta

adam added the bug label 2026-04-24 23:22:56 +02:00

adam closed this issue

2026-04-24 23:22:56 +02:00

adam commented

2026-04-24 23:22:57 +02:00

@advplyr commented on GitHub (Feb 4, 2023):

I did this intentionally because I thought it was more useful to get the absolute position in the audiobook. We had a conversation about this a few days ago in Discord.
I think in the end it makes more sense to adjust to the current time with the playback speed even though it isn't as functionally useful.

@advplyr commented on GitHub (Feb 4, 2023): I did this intentionally because I thought it was more useful to get the absolute position in the audiobook. We had a conversation about this a few days ago in Discord. I think in the end it makes more sense to adjust to the current time with the playback speed even though it isn't as functionally useful.

adam commented

2026-04-24 23:22:58 +02:00

@hobesman commented on GitHub (Feb 4, 2023):

Or have a third time. Elapsed, total, and remaining. Elapsed and total can be 1x measurements, and the remaining time can be based on playback speed.

@hobesman commented on GitHub (Feb 4, 2023): Or have a third time. Elapsed, total, and remaining. Elapsed and total can be 1x measurements, and the remaining time can be based on playback speed.

adam commented

2026-04-24 23:22:58 +02:00

@JakobTischler commented on GitHub (Feb 7, 2023):

I think in the end it makes more sense to adjust to the current time with the playback speed even though it isn't as functionally useful.

This has actually bothered me for a long time, but apparently not enough to open an issue :) I think it's more important to have consistency, so I agree both time values should be based on the same on the same speed value.

Or have a third time. Elapsed, total, and remaining. Elapsed and total can be 1x measurements, and the remaining time can be based on playback speed.

This can get messy very quickly, from a UI point of view. Too much data means visual overload and increasing difficulty to quickly get the information you want. Personally I'm already not a fan of two track / seek bars, especially that close together. But they are toggleable, so there's that. I kinda like what Audible does:

All time time values are speed adjusted, and the center book value even shows you that it's specifically based on your speed setting. It's also very helpful that (1) the "book time left" value is formatted as readable text, and (2) has different font settings. Both help quickly separating it from the other two time values.

Also, concerning my dislike for the book seek bar: the important information for the book time is, in my opinion, only the time left, not the time passed. That's why I like Audible's "time left" solution even better: it gets rid of (again, in my opinion) unnecessary information and keeps the layout cleaner.

@JakobTischler commented on GitHub (Feb 7, 2023): > I think in the end it makes more sense to adjust to the current time with the playback speed even though it isn't as functionally useful. This has actually bothered me for a long time, but apparently not enough to open an issue :) I think it's more important to have consistency, so I agree both time values should be based on the same on the same speed value. > Or have a third time. Elapsed, total, and remaining. Elapsed and total can be 1x measurements, and the remaining time can be based on playback speed. This can get messy very quickly, from a UI point of view. Too much data means visual overload and increasing difficulty to quickly get the information you want. Personally I'm already not a fan of two track / seek bars, especially that close together. But they are toggleable, so there's that. I kinda like what Audible does: ![image](https://user-images.githubusercontent.com/748857/217343414-2f25aad7-1fee-4ca7-8fe4-67c2683acf4a.png) All time time values are speed adjusted, and the center book value even shows you that it's specifically based on your speed setting. It's also very helpful that (1) the "book time left" value is formatted as readable text, and (2) has different font settings. Both help quickly separating it from the other two time values. Also, concerning my dislike for the book seek bar: the important information for the _book time_ is, in my opinion, only the time left, not the time passed. That's why I like Audible's "time left" solution even better: it gets rid of (again, in my opinion) unnecessary information and keeps the layout cleaner.

adam commented

2026-04-24 23:22:58 +02:00

@lkiesow commented on GitHub (Feb 7, 2023):

I fully agree with @JakobTischler. Both with the “be consistent” as well as the “keep the ui simple and clutter-free”.

@lkiesow commented on GitHub (Feb 7, 2023): I fully agree with @JakobTischler. Both with the “be consistent” as well as the “keep the ui simple and clutter-free”.

adam commented

2026-04-24 23:22:58 +02:00

@advplyr commented on GitHub (Feb 23, 2023):

Updated in v0.9.62-beta

@advplyr commented on GitHub (Feb 23, 2023): Updated in [v0.9.62-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.62-beta)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#434