In the Nav Bar widget, playback controls are as follows from left to right:
[Jump Back] [Pause/Play] [Jump Forward]
Actual behaviour
In the main window and in the nav bar, playback controls are inconsistent. I have seen a number of layouts in the main window, but I remember the following two in particular:
The control arrangement seems to be tied to something specific to the individual book. The control layout seems to be always the same for each book. I can't figure out what is driving the change, though.
Environment data
Audiobookshelf Version: 2.2.1
Android App?
iOS App?
Android Issue
Android version: 13
Device model: Pixel 4a
Stock or customized system: Stock
Originally created by @dchawisher on GitHub (Nov 3, 2022).
### Steps to reproduce
1. Open audiobookshelf in android auto
2. Play a book; observe the playback controls in the main window
3. (Optional) Switch to another app and observe the controls in the audiobookshelf nav bar widget
4. Play a different book; observe the playback controls in the main window
5. (Optional) Switch to another app and observe the controls in the audiobookshelf nav bar widget
6. Repeat steps 4 and 5 until something frustrating happens
### Expected behaviour
- In the main window, playback controls are as follows from left to right:
- [Previous Chapter] [Jump Back] [Pause/Play] [Jump Forward] [Next Chapter]
- In the Nav Bar widget, playback controls are as follows from left to right:
- [Jump Back] [Pause/Play] [Jump Forward]
### Actual behaviour
- In the main window and in the nav bar, playback controls are inconsistent. I have seen a number of layouts in the main window, but I remember the following two in particular:
- [Jump **Forward**] [Previous Chapter] [Pause/Play] [Next Chapter] [Jump **Back**]
- [Previous Chapter] [Jump Back] [Pause/Play] [Next Chapter]
- In the nav bar widget, I've seen the following:
- [Previous Chapter] [Pause/Play] [Next Chapter]
- [Previous Chapter] [Pause/Play] [Jump Forward]
- The control arrangement seems to be tied to something specific to the individual book. The control layout seems to be always the same for each book. I can't figure out what is driving the change, though.
### Environment data
Audiobookshelf Version: 2.2.1
- [X] Android App?
- [ ] iOS App?
#### Android Issue
Android version: 13
Device model: Pixel 4a
Stock or customized system: Stock
adam
added the bug label 2026-04-24 23:16:50 +02:00
At the moment the chapter buttons will only be available if you are using multi-file audiobooks. So single-file m4b audiobooks don't have the chapter buttons yet.
I'll have to go through this again next time I open the app again to be sure what I said is correct, but maybe that could help explain some of what you are seeing?
@advplyr commented on GitHub (Nov 3, 2022):
At the moment the chapter buttons will only be available if you are using multi-file audiobooks. So single-file m4b audiobooks don't have the chapter buttons yet.
I'll have to go through this again next time I open the app again to be sure what I said is correct, but maybe that could help explain some of what you are seeing?
That could account for some but not all of it. E.g. I can't think of why the order would differ or why I would have a control like this: ⏩⏮⏯⏭⏪ (jump forward/back are on the outside and are on the wrong sides) or this: ⏮⏯⏩ (prev chapter, play, jump forward). I will see if I can gather more info about which files yield which configurations.
@dchawisher commented on GitHub (Nov 4, 2022):
That could account for some but not all of it. E.g. I can't think of why the order would differ or why I would have a control like this:
⏩⏮⏯⏭⏪ (jump forward/back are on the outside and are on the wrong sides) or this: ⏮⏯⏩ (prev chapter, play, jump forward). I will see if I can gather more info about which files yield which configurations.
On further investigation, you're right: The inconsistency in control layout from book to book appears entirely due to single-file vs. multi-file support. That leaves the problem of the layouts being, in my view, suboptimal in a few ways.
First, in the main view, the jumpforward / jumpback buttons are on different sides depending on whether the book is a multifile or singlefile audiobook. Images of same book before and after m4b conversion. The jump buttons are on the wrong side with multifile audiobooks.
Second, in my opinion it makes more sense to have the jumpforward/jumpback buttons adjacent to the pause/play button rather than on the outside. There are two reasons for this:
Conceptually it makes sense: the buttons will be ordered from most back (prevfile) to most forward (nextfile)
From an ease-of-use standpoint it also makes sense.
The jumpback, pause/play, and jumpforward buttons are "safe" operations. If you press the wrong button (e.g., jumpforward when you meant to press pause), the worst-case scenario is tolerable (you're 10 to 30 seconds from where you want to be) and it is easy to return to your previous position—not just because you are still close to that position but also because the position has changed by a fixed amount.
Prevfile and nextfile are not "safe" in that sense. (Nor, for that matter, are prevchap and nextchap once those are implemented.) You can easily lose your position entirely by pressing prevfile when you meant to press jumpback. Because Android Auto controls will very often be used without looking, in my opinion it makes sense to have a "safe" area at the middle of the screen where the user can be confident that s/he is not going to mess something up.
Third, for similar reasons I think the navbar widget should have jumpback/jumpforward rather than prevfile/nextfile.
This makes the entire navbar widget "safe," which is especially desirable because the navbar controls are more compact than the main window controls, which increases the risk of pressing the wrong button.
It seems to me that most users are more likely to want regular access to the jump buttons than the prevfile/nextfile buttons. Maybe I am an outlier, but I find myself using the jumpback button all the time, usually because I got distracted or just didn't hear something and want to play it again. I find myself using the prevchap and nextchap buttons infrequently, even in the regular app interface. For me (and I suspect for most), the jump buttons are important "listening" tools, while the prevchap and nextchap buttons are important "navigation" or "setup" tools. Put differently, I use prevchap and nextchap to pick what I want to listen to. While I'm listening, I no longer need easy access to those buttons but I do need access to the jump buttons.
If you agree with my reasoning about how the controls should be laid out, I can try to implement the change myself and submit a pull request.
@dchawisher commented on GitHub (Nov 5, 2022):
On further investigation, you're right: The inconsistency in control layout from book to book appears entirely due to single-file vs. multi-file support. That leaves the problem of the layouts being, in my view, suboptimal in a few ways.
First, in the main view, the jumpforward / jumpback buttons are on different sides depending on whether the book is a multifile or singlefile audiobook. [Images of same book before and after m4b conversion.](https://imgur.com/a/1JwC0JP) The jump buttons are on the wrong side with multifile audiobooks.
Second, in my opinion it makes more sense to have the jumpforward/jumpback buttons adjacent to the pause/play button rather than on the outside. There are two reasons for this:
- Conceptually it makes sense: the buttons will be ordered from most back (prevfile) to most forward (nextfile)
- From an ease-of-use standpoint it also makes sense.
- The jumpback, pause/play, and jumpforward buttons are "safe" operations. If you press the wrong button (e.g., jumpforward when you meant to press pause), the worst-case scenario is tolerable (you're 10 to 30 seconds from where you want to be) and it is easy to return to your previous position—not just because you are still close to that position but also because the position has changed by a fixed amount.
- Prevfile and nextfile are not "safe" in that sense. (Nor, for that matter, are prevchap and nextchap once those are implemented.) You can easily lose your position entirely by pressing prevfile when you meant to press jumpback. Because Android Auto controls will very often be used without looking, in my opinion it makes sense to have a "safe" area at the middle of the screen where the user can be confident that s/he is not going to mess something up.
Third, for similar reasons I think the navbar widget should have jumpback/jumpforward rather than prevfile/nextfile.
- This makes the entire navbar widget "safe," which is especially desirable because the navbar controls are more compact than the main window controls, which increases the risk of pressing the wrong button.
- It seems to me that most users are more likely to want regular access to the jump buttons than the prevfile/nextfile buttons. Maybe I am an outlier, but I find myself using the jumpback button all the time, usually because I got distracted or just didn't hear something and want to play it again. I find myself using the prevchap and nextchap buttons infrequently, even in the regular app interface. For me (and I suspect for most), the jump buttons are important "listening" tools, while the prevchap and nextchap buttons are important "navigation" or "setup" tools. Put differently, I use prevchap and nextchap to pick what I want to listen to. While I'm listening, I no longer need easy access to those buttons but I do need access to the jump buttons.
If you agree with my reasoning about how the controls should be laid out, I can try to implement the change myself and submit a pull request.
@advplyr commented on GitHub (Nov 5, 2022):
I completely forgot a contributor cleaned a lot of this up already and their update came right after the last release.
I just tested and it looks like what you are describing already.
https://github.com/advplyr/audiobookshelf-app/pull/365
I'll try to get this release out this weekend
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @dchawisher on GitHub (Nov 3, 2022).
Steps to reproduce
Expected behaviour
Actual behaviour
Environment data
Audiobookshelf Version: 2.2.1
Android Issue
Android version: 13
Device model: Pixel 4a
Stock or customized system: Stock
@advplyr commented on GitHub (Nov 3, 2022):
At the moment the chapter buttons will only be available if you are using multi-file audiobooks. So single-file m4b audiobooks don't have the chapter buttons yet.
I'll have to go through this again next time I open the app again to be sure what I said is correct, but maybe that could help explain some of what you are seeing?
@dchawisher commented on GitHub (Nov 4, 2022):
That could account for some but not all of it. E.g. I can't think of why the order would differ or why I would have a control like this:
⏩⏮⏯⏭⏪ (jump forward/back are on the outside and are on the wrong sides) or this: ⏮⏯⏩ (prev chapter, play, jump forward). I will see if I can gather more info about which files yield which configurations.
@dchawisher commented on GitHub (Nov 5, 2022):
On further investigation, you're right: The inconsistency in control layout from book to book appears entirely due to single-file vs. multi-file support. That leaves the problem of the layouts being, in my view, suboptimal in a few ways.
First, in the main view, the jumpforward / jumpback buttons are on different sides depending on whether the book is a multifile or singlefile audiobook. Images of same book before and after m4b conversion. The jump buttons are on the wrong side with multifile audiobooks.
Second, in my opinion it makes more sense to have the jumpforward/jumpback buttons adjacent to the pause/play button rather than on the outside. There are two reasons for this:
Third, for similar reasons I think the navbar widget should have jumpback/jumpforward rather than prevfile/nextfile.
If you agree with my reasoning about how the controls should be laid out, I can try to implement the change myself and submit a pull request.
@advplyr commented on GitHub (Nov 5, 2022):
I completely forgot a contributor cleaned a lot of this up already and their update came right after the last release.
I just tested and it looks like what you are describing already.
https://github.com/advplyr/audiobookshelf-app/pull/365
I'll try to get this release out this weekend
@dchawisher commented on GitHub (Nov 11, 2022):
Works great. Thanks!