Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚀 | "next_song" performing no action when no next song is available #2327

Closed
IgorWalton opened this issue Apr 8, 2024 · 8 comments · Fixed by #2326
Closed

🚀 | "next_song" performing no action when no next song is available #2327

IgorWalton opened this issue Apr 8, 2024 · 8 comments · Fixed by #2326
Labels
enhancement future3 Relates to future3 development
Milestone

Comments

@IgorWalton
Copy link

Feature

I would like the next_song GPIO button to do nothing, when there is no next song available (last track of a folder or single track without any folder). Currently this will stop the playback.

User perspective

I imagine my (very young) child will pretty randomly press all of the available buttons, so this behaviour would be better suited.

Further information

using Jukebox Core Version 3.5.2

@IgorWalton IgorWalton added enhancement future3 Relates to future3 development labels Apr 8, 2024
@Lippsson
Copy link

Lippsson commented Apr 8, 2024

Good feature request. It would be great if that above is the standard behavior

@pabera
Copy link
Collaborator

pabera commented Apr 8, 2024

I think this is what the following PR is trying to solve?!

@pabera pabera added this to the v3.6 milestone Apr 8, 2024
@pabera pabera linked a pull request Apr 8, 2024 that will close this issue
@hoffie
Copy link
Contributor

hoffie commented Apr 11, 2024

Hrm, the linked PR will behave in the following way:

  1. When the last song of a playlist is being played and next() is called, the default will be to stop playing (this is configurable).
  2. When the player is stopped (e.g. because the last song of a playlist finished) and the next() is called, the player will rewind the playlist (i.e. it will start playing the first song of the playlist again).

@IgorWalton Is that what you're after? If not, we would have to make (2) configurable as well.

@IgorWalton
Copy link
Author

IgorWalton commented Apr 11, 2024

  1. I personally would prefer if the default is "no action" in this situation
  2. The way I think would make the most sense is during a stop in the middle of a track "next" jumps to the next track in the current playlist, and at the end of a playlist it there's either "no action" or "start playing the first song of the playlist"
    I don't have the developer perspective (yet), so just 2 Cents from a User's POV...

@hoffie
Copy link
Contributor

hoffie commented Apr 11, 2024

Edit: I'm updating #2326 to add the no action behavior for (1).
Regarding (2), this can certainly be implemented as well. I was a bit hesitant to make this configurable, because every option adds code and config complexity, but I guess it's worth it if there are people who want to use it like that. :)

@s-martin
Copy link
Collaborator

You can still add it, if you want

hoffie added a commit to hoffie/RPi-Jukebox-RFID that referenced this issue Apr 11, 2024
* Avoid MPD-related crashes during all prev/next() calls.
* Explicitly handle prev() in stopped state, configurable via
  `playermpd.stopped_prev_action`.
* Explicitly handle next() in stopped state, configurable via
  `playermpd.stopped_next_action`.
* Explicitly handle next() when reaching the end of the playlist:
  jukebox-daemon will now stop playing by default (similar to v2).
  It can also be configured to restart the playlist instead by setting
  the new config option `playermpd.end_of_playlist_next_action: rewind`
  or to ignore the action completely.

Fixes MiczFlor#2294
Fixes MiczFlor#2327

Co-authored-by: pabera <[email protected]>
hoffie added a commit to hoffie/RPi-Jukebox-RFID that referenced this issue Apr 11, 2024
* Avoid MPD-related crashes during all prev/next() calls.
* Explicitly handle prev() in stopped state, configurable via
  `playermpd.stopped_prev_action`.
* Explicitly handle next() in stopped state, configurable via
  `playermpd.stopped_next_action`.
* Explicitly handle next() when reaching the end of the playlist:
  jukebox-daemon will now ignore the action by default (similar to v2).
  It can also be configured to rewind the playlist instead by setting
  the new config option `playermpd.end_of_playlist_next_action: rewind`
  or to stop playing.

Fixes MiczFlor#2294
Fixes MiczFlor#2327

Co-authored-by: pabera <[email protected]>
@hoffie
Copy link
Contributor

hoffie commented Apr 11, 2024

I personally would prefer if the default is "no action" in this situation

#2326 should now technically cover this.

The way I think would make the most sense is during a stop in the middle of a track "next" jumps to the next track in the current playlist

Done.

at the end of a playlist it there's either "no action" or "start playing the first song of the playlist"

This should now behave similar to the case when running next() while playling the last song of the playlist (= it's configurable).

hoffie added a commit to hoffie/RPi-Jukebox-RFID that referenced this issue Apr 12, 2024
* Avoid MPD-related crashes during all prev/next() calls.
* Explicitly handle prev() in stopped state, configurable via
  `playermpd.stopped_prev_action`.
* Explicitly handle next() in stopped state, configurable via
  `playermpd.stopped_next_action`.
* Explicitly handle next() when reaching the end of the playlist:
  jukebox-daemon will now ignore the action by default (similar to v2).
  It can also be configured to rewind the playlist instead by setting
  the new config option `playermpd.end_of_playlist_next_action: rewind`
  or to stop playing.

Fixes MiczFlor#2294
Fixes MiczFlor#2327

Co-authored-by: pabera <[email protected]>
hoffie added a commit to hoffie/RPi-Jukebox-RFID that referenced this issue Apr 12, 2024
* Avoid MPD-related crashes during all prev/next() calls.
* Explicitly handle prev() in stopped state, configurable via
  `playermpd.stopped_prev_action`.
* Explicitly handle next() in stopped state, configurable via
  `playermpd.stopped_next_action`.
* Explicitly handle next() when reaching the end of the playlist:
  jukebox-daemon will now ignore the action by default (similar to v2).
  It can also be configured to rewind the playlist instead by setting
  the new config option `playermpd.end_of_playlist_next_action: rewind`
  or to stop playing.

Fixes MiczFlor#2294
Fixes MiczFlor#2327

Co-authored-by: pabera <[email protected]>
pabera added a commit that referenced this issue Apr 12, 2024
* utils: Add get_config_action

This abstracts away the functionality to resolve a given config option
to an action in a pre-defined dict.

Co-authored-by: Christian Hoffmann <[email protected]>

* Fix PlayerMPD.prev/next() when stopped

* Avoid MPD-related crashes during all prev/next() calls.
* Explicitly handle prev() in stopped state, configurable via
  `playermpd.stopped_prev_action`.
* Explicitly handle next() in stopped state, configurable via
  `playermpd.stopped_next_action`.
* Explicitly handle next() when reaching the end of the playlist:
  jukebox-daemon will now ignore the action by default (similar to v2).
  It can also be configured to rewind the playlist instead by setting
  the new config option `playermpd.end_of_playlist_next_action: rewind`
  or to stop playing.

Fixes #2294
Fixes #2327

Co-authored-by: pabera <[email protected]>

---------

Co-authored-by: pabera <[email protected]>
@s-martin
Copy link
Collaborator

#2326 has been merged to future3/develop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement future3 Relates to future3 development
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants