Timer option to stop at end of chapter and persist

[danielb2]

Description:
I’d like timer options, including “End of chapter”, to remain enabled after they trigger instead of automatically disabling.

Use case:
I listen during the day and use the timer to stop playback at clean boundaries. One of the timer options is “End of chapter”. Currently, once the timer triggers, it disables itself. For books with short chapters, this means constantly re-enabling the timer every few minutes, which breaks the listening flow. I want the selected timer option to persist so it applies repeatedly without manual reactivation.

Proposed behavior:
Add an option to make timers persistent. When enabled, selecting “End of chapter” stops playback at the end of each chapter and remains active for future playback. Time-based options like 5 or 10 minutes would also re-arm after triggering.

Benefit:
Improves usability for chapter-based listening. Makes short chapters practical. Reduces repetitive interaction with the timer UI.

[GrakovNe]

Seems like the time of the timer advanced settings has come :-)

Will come after New Year

[danielb2]

sounds like you knew it was just a matter of time 😂

I don't think it's too advanced. just stop play reset the timer? unless you want to make it an option too

[GrakovNe]

@danielb2 What do you think—would it be better to have “End after the next N chapters” as a timer option?

[danielb2]

Thanks for considering the input.

'End after N chapters' is definitely more flexible and would be handy. I've certainly listened to books with chapters short enough to warrant that.

For the timer use case, the main goal is just to avoid the repetitive manual re-arming. If it’s easier to implement a simple 'Persistent End of Chapter' first, that solves the friction for me. But if building 'N chapters' is the same level of effort, it definitely covers more use cases, though I don't know if it sacrifices simplicity for the end user.

Smart AudioBook Player has the best implementation of this I’ve seen if you’re looking for a reference.

As a developer myself, my philosophy is usually: get the easiest implementation out first, but if the effort is equal, go for the one that covers the most ground.