fix: play_card function with second_swipe support

[pabera]

Until now, 3 functions existed to be registered to a card: play_single, play_album and play_folder. None of these functions supported "Second Swipe". Instead, another function existed, called play_card which had Second Swipe support, but it ended up to call play_folder, ingoring the other 2 functions all together

This PR aims at solving this problem and to prepare for https://github.com/hoffie/RPi-Jukebox-RFID/commit/c4805cebb848e8aaafd69c43f497b09436e67169

• [x] Refactor play_card in PlayerMPD
• [ ] Adapting UI to assign only play_card command instead of play_single, play_album or play_folder
• [ ] Handle cards.yaml and rewrite commands to use play_card

[AlvinSchiller]

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?

[pabera]

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.

[s-martin]

#1698 is related and probably needs to be considered.

[damaev]

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?

[damaev]

see d9d40bfd8ef771bcbcaeef0c2aa10ae2ab25cdaf for a card-wrapper and the updated mpdplayer-script