Open pabera opened 5 months ago
Regarding "second swipe": I found it strange that it's implemented in the player, and that it also is triggered for the UI playback (apart its name).
That's definitely another behaviour known from V2.
Nevertheless would it not make more sense that it is an option on the folder/card, then an overall state? So different cards could have different settings?
I found it strange that it's implemented in the player
I agree
.. and that it also is triggered for the UI playback (apart its name).
I don't think that's the case. See below explanation.
That's definitely another behaviour known from V2.
I haven't deep dived into the v2 implementation much.
Nevertheless would it not make more sense that it is an option on the folder/card, then an overall state? So different cards could have different settings?
I agree
Intuitively, we opted for the commands play_single
, play_album
, and play_folder
in the UI and for card assignments, rather than using the existing play_card
function. The latter served as a wrapper for a combination of a Second Swipe event and play_folder
.
Initially, I questioned the necessity of play_card
. It seemed feasible to integrate the second swipe functionality directly into play_single
, play_album
, and play_folder
. However, this approach doesn't align with our intentions. If the non-play_card
commands are executed from the UI, we aim to avoid triggering a Second Swipe event (as Alvin Schiller pointed out, if I understand correctly). Conversely, if the command is activated via the RFID reader, it should trigger a Second Swipe, depending on certain configurations. For the moment, let's set aside the discussion on configurations (though I concur that a default Second Swipe event should exist, with the possibility of being customized within individual card commands).
Nonetheless, combining the play_album
(Player event) with a second_swipe
(RFID event) could result in a next
(Player event), as illustrated below:
if(second_swipe): next() # Avoid triggering play_album()
This is likely the rationale behind the original implementation within the Player, as it was the only entity capable of managing this logic.
I am dissatisfied with the current implementation of the second swipe functionality and propose its removal, with the intention of reintroducing it in a separate PR.
as my current setup (v3/devlop, place_not_swipe=true) does not resume after replacing, but playing the track again, i finally found this thread. However, it looks like a lot of people already dug into this topic in enhancement calls etc.
from my point of view (not sure if its correct) the second swipe action is dealt with in the mpd_player. however, why isn't this put into the cards itself like: defining a general secondwipe behaviour for all cards . allowing a second wipe action for each card.
How do you think about it?
see d9d40bfd8ef771bcbcaeef0c2aa10ae2ab25cdaf for a card-wrapper and the updated mpdplayer-script
Until now, 3 functions existed to be registered to a card:
play_single
,play_album
andplay_folder
. None of these functions supported "Second Swipe". Instead, another function existed, calledplay_card
which had Second Swipe support, but it ended up to callplay_folder
, ingoring the other 2 functions all togetherThis PR aims at solving this problem and to prepare for https://github.com/hoffie/RPi-Jukebox-RFID/commit/c4805cebb848e8aaafd69c43f497b09436e67169
play_card
inPlayerMPD
play_card
command instead ofplay_single
,play_album
orplay_folder
play_card