Introduce new PlayContentHandler to abstract Second Swipe

[pabera]

Replaces abandoned #2330

---

Until now, 3 functions existed to be registered to content: 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, igoring the other 2 functions all together.

• Refactor play_single, play_album or play_folder in PlayerMPD to become play_content
• Adapting UI to assign only play_content command
• Handle cards.yaml and rewrite commands to use play_content (Backwards compatibility)

---

Maybe to be considered from old PR

This PR aims at solving this problem and to prepare for hoffie@c4805ce

[pabera]

@AlvinSchiller @s-martin @damaev

I think this code gets closer to "Second Swipe". But I have a doubt. See the following Flow Chart.

It makes me think.. "Second Swipe" should only be considered if the action comes from RFID (or other reader), nothing else.

E.g. swiping a card triggers this command: player.ctrl.play_album "Bibi & Tina" "Jetzt in Echt - Soundtrack zum Kinofilm"

But when I navigate in the WebApp to the same album of the same artist, the command that would trigger is the same.

That would be considered a "Second Swipe", at least for now. And I don't seem to be able to find a distinguisher.

Thoughts?

flowchart TD
    Start(["External Call<br>(e.g., Web UI, RFID)"]) --> playContent["player.play_content()<br>content, type, recursive"]
    
    subgraph PlayerMPD
        playContent --> validateContent["Validate content and create<br>PlayContent object"]
        validateContent --> handlerPlay["play_content_handler.play_content()"]
    end

    subgraph PlayContentHandler
        handlerPlay --> checkLastContent{"Is last_played_content<br>stored?"}
        checkLastContent -- "No" --> FirstSwipe["First Swipe:<br>- Run firstSwipe callbacks<br>- Play content<br>- Store as last_played_content"]
        
        checkLastContent -- "Yes" --> compareContent{"Is current content<br>same as last_played_content?"}
        compareContent -- "No" --> FirstSwipe
        compareContent -- "Yes" --> checkAction{"Is second_swipe_action<br>configured?"}
        
        checkAction -- "No" --> FirstSwipe
        checkAction -- "Yes" --> SecondSwipe["Second Swipe:<br>- Run secondSwipe callbacks<br>- Execute second_swipe_action"]
    end

    FirstSwipe --> End(["Content Playing"])
    SecondSwipe --> End

Loading

[s-martin]

I agree with your observations. Right now I don’t see a use case for second swipe from the web UI (or maybe MQTT?).

Looks like the simple (but maybe not so pretty) approach could be to pass an argument, if the call comes from an rfid reader.

[AlvinSchiller]

I like the idea so far. But i also think, triggering the "second swipe" from the ui, is not really a usecase, and could cause more confusion. So there needs to be a parameter, or a different function, to opt-in second swipe.

Also there are other features, that are mainly build for card swipes, like the syncing (triggered through play_card_callbacks).
These should not trigger from the WebUI.

[coveralls]

Pull Request Test Coverage Report for Build 11878660465

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 38.14%

---

Totals
Change from base Build 11768279903:	0.0%
Covered Lines:	492
Relevant Lines:	1290

---

💛 - Coveralls