🚀 | Add resume option

[votti]

Feature Description

What functionality would you like to see in your phoniebox?

Also in future3 the resume functionality should be provided.
Eg some folders (audiobook) should be set to always resume from the previous position.

How do you envision the feature to work from a users perspective?

Set in the configuration of a card to resume it and the next time switching from another card to this card, the playback should resume from the old position.

[plimptm]

With a month or two of real-life-with-kids experience after building, I've been thinking about this issue and related functionality 'tweaks' that stem from the dual use cases of 1) jukebox (music) and 2) audiobook player. Resume functionality is pretty critical for a manageable audiobook solution, and I've addressed that by installing votti:future3/feature/resume.

As @votti mentioned when opening this issue, it would be great if audiobook folders could be set to automatically enable this function. It would also be great if other existing functions could have their behavior tweaked by the same logic. E.g. perhaps mapping the 'next track' and 'previous track' buttons on a bluetooth device to seek forwards/backwards a certain (but configurable) number of seconds.

Novice question - does the way the application current reads metadata about the contents of each folder help it to 'know' the difference between music and an audiobook? How difficult/trivial would it be to implement something that made that distinction simpler?

While the use of m4b files could help (similar to the podcast/URL stream implementation), many audiobooks have historically come as tracks of MP3 files, similar to an album of music. Perhaps in those cases it's just a matter of the user setting a flag somewhere to inform the jukebox app that the currently-playing content should be treated as an audiobook.

[votti]

@seeking backwards and forward: Actually that is also a behaviour I wanted:
For the seek forward I found this already existed in the form of a seek function.
For seek backwards I implemented something to work both nicely for large and small audios:
votti@c746000
Seeing that I am not the only one that likes this kind of behavior, I am opening a new issue.

[plimptm]

Very nice, thanks for sharing that commit.

Reading through your issue, I see that file length might have as much to do with the desired behavior than just media type.

How did you go about mapping your custom RPC call to a physical action? Did you use a custom control card, a physical switch, or something else?

[votti]

I mapped the custom RPC to a physical buttons (forward/backwards buttons on the box for the kids to smash).