Development build 20251228-2 includes some bug fixes and some better logging around text matches.
Example:
stream - [Tune xxx] Text match result: Text to match: ["who's watching", 'choose an account', 'edit profiles']. Matches found: ["who's watching", 'edit profiles'].
lib.adb - [Tune xxxt] ADB: input keyevent KEYCODE_DPAD_CENTER
stream - [Tune xxx] Text match result: Text to match: ['watch live']. Matches found: ['watch live'].
lib.adb - [Tune xxx] ADB: input keyevent KEYCODE_DPAD_CENTER
To provide some extra clarification, these matches aren't necessarily processed in sequence and may be processed more than once. For example. if the "who's watching" text is detected multiple times it will be matched each time and the linked commands will be executed (ex. KEYCODE_DPAD_CENTER).
As a result, if the commands to be executed are always the same (ex. KEYCODE_DPAD_CENTER) one could just add extra text strings to match in one list.
For example, this alone might be sufficient for this specific use case:
"tune_match_text_commands": [
{
"match_text": [
"who's watching",
"choose an account",
"edit profiles",
"watch live"
],
"commands": [
"input keyevent KEYCODE_DPAD_CENTER"
],
"start_checking_after_seconds": 5
}
]
It will trigger when "who's watching" appears and then trigger again when "watch live" appears.
Let me know if this implementation causes any issues. It made sense yesterday morning at 6am, it most certainly might not be the best way to handle this.
I'm thinking about adding a way to optionally specify that all of the supplied strings should match. If we can match multiple UI elements it could help avoid false positives.
