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 hoffie@c4805ce

• 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.