What do you expect to happen when you use a next/prev action?

What do you expect to happen when you use a next/prev action?

Depends on the content / personal preferences.

Music / audio books with multiple files:

• Next: Next track, if available, stop when no more tracks available
• Prev: If within the first 3 seconds of a track, skip to previous, otherwise skip to the beginning of a track

Files with chapters (audio books, podcasts):

• Next: Next chapter, if available, stop when no more chapters available
• Prev: If within the first 3 seconds of a chapter, skip to previous, otherwise skip to the beginning of a chapter

However, there are some minor tweaks I would love to see in the settings, although they would take a lot of effort to implement:

• Instead of next / prev track or chapter, I would configure next/prev to fast forward / rewind 5 minutes on files with chapters
  • Reason: Chapters are unpredictable - some books have 3 minute chapters, some have 15 minute chapters

For play/pause i would like to see an increasing amount of rewind seconds, that resets after 3 seconds of no action, example:

• First Pause: Rewind 10 seconds and pause
• Play again
• Pause again (within 3 seconds): Rewind 20 seconds and pause
• Play again
• Pause again (within 3 seconds): Rewind 30 seconds and pause
• Play again
• Pause again (within 3 seconds): Rewind 60 seconds and pause
• Play again (more than 3 seconds) => reset the increasing timer
• Pause again: rewind 10 seconds

Same of course applies to step back and step forward on the player and lockscreen controls. You could also increase that to 2 times per time step (increase timer after 2 rounds of rewinding). I think in most cases you pause multiple times you want to rewind the book just a few seconds, because you missed something. But the more you do it the more you want to go back.

So possible settings could be:

• Play / Pause: Rewind [ ] seconds where
  • A single value would be a fixed one
  • A comma separated value would behave like described above (10,10,20,20,30,30,60,60)
• Next/Prev: Default behaviour / Skip fixed amount of time: [ ] seconds
  • Default behaviour: Next or Previous
  • Fixed amount of time: Just fast forward or rewind.

Just weighing in on how I use headphone buttons: I'd never want my headphone buttons to do next or previous track/chapter. That's way too long in an audio book, and way too easy to mess up with no way to get back to where you just were. The only button I would personally use from my headphones is a short rewind 30-60s. When I'm out running or walking, sometimes I need to skip back because I got distracted and missed something.

Ok, I played around with the click handler in a fork and think I found a pretty neat solution for the click detection. Unfortunately I'm not a kotlin native and can't get it translate to the player actions - so I could use some help.

So here is the diff:
master...sandreas:audiobookshelf-app:master

how does this work:

• every keyDown and keyUp triggers a scheduled handler (!)
• the handler takes clickCount:int and clickPressed:bool (if held down)
• another keyDown or keyUp cancels the active scheduled handler and re-triggers it
• keyCodes increase the number of clicks (PlayPause+=1, Next+=2, Prev+=3)
• depending on the number of clicks, the playerNotificationService handles the configured action

problems:

• the logs show pretty accurate click / hold detection, but it does not really translate well in the player
• since the trigger is scheduled, it does run in a different thread
• this leads to strange behaviour - probably easy to fix, but I'm no kotlin native (Coroutines)
• probably after some actions the thread of the player is no longer accessible...

missing things:

• FastForward and Rewind are not implemented in the player
• Next (Chapter) and Previous (Chapter) are not implemented either

@advplyr
What do you think of this? Would you be able to help me a little bit? ;)

@advplyr
As said in matrix chat, I would suggest the following settings and actions as default:

whereas the second column is a select box with the following options:

• increase / decrease speed refers to playback speed
• reset sleep timer refers to the auto sleep timer
• time announcement would try to synthesize speech to read the current time over headphones
• metadata announcement would try to synthesize speech to read the current track name over headphones

Additionally, the click-timeout could be a setting:

• Click timeout: 600 ms

Since some of the actions would need additional implementation steps, the items below the ======== are just ideas for future improvements. Starting with the existing actions would be totally fine.

@advplyr
UPDATE: I think I got it working with Coroutines. It works flawlessly on my testing device, but I did not have the time to check for side effects (regression issues with other player features).

I think this would be a GREAT addition to Audiobookshelf, maybe we should start with a configuration less default setting (like described above).

I think the most important part missing is the fastForward, rewind, next, previous steps in the player notification service.

UPDATE: Setting enableExperimentalHeadsetControls is now integrated. It is not persisted yet, but you CAN test the behaviour, if you start a track and let it play, then go to the settings and enable the setting.

Using a headset now uses the following experimental click-codes by default:

I would love to get some feedback on this. Fastest way to check it out is probably cloning my repo and just build it:

git clone https://github.com/sandreas/audiobookshelf-app.git
cd audiobookshelf-app
npm install
npm run generate
npx cap sync
npx cap open android

Then start the Android session of your liking