search

MiczFlor / RPi-Jukebox-RFID

A Raspberry Pi jukebox, playing local music, podcasts, web radio and streams triggered by RFID cards, web app or home automation. All plug and play via USB. GPIO scripts available.
http://phoniebox.de
MIT License
1.37k stars 398 forks source link

🚀 | Add resume option #1945

Open votti opened 1 year ago

votti commented 1 year ago

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 commented 2 months ago

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 commented 2 months ago

@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: https://github.com/votti/RPi-Jukebox-RFID/commit/c746000ec9d20172f93b96c867c4a3316f3c0592 Seeing that I am not the only one that likes this kind of behavior, I am opening a new issue.

plimptm commented 2 months ago

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 commented 2 months ago

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