It seems like DirecTV pushed an update that broke tuning, at least for me from sleep. Cold tunes from sleep just would not work. They'd freeze. I don't know if it's a bug or a permanent change, but based on the APK analysis I had Claude do, it seems like it might be an intentional change to the way they negotiate HDMI on the Osprey boxes.
What resolved it was adding a sleep 2 to prebmitune.sh.
main() {
adbConnect
adbWake
sleep 3
}
if anyone else sees this behavior, let me know and I can open a PR for this one line change. @bnhf please let me know if this is a good candidate for a pull request or if you wanna just update the script at some point. This was actually pretty reproducible for me on the latest Osprey update that seems to just get pushed down at random by DirecTV and just adding the sleep seemed to fix it, although I'm not sure if sleep 2 is long enough. A longer interval might be better, but I also wanted to prioritize fast tuning, so I was kind of pushing it a little bit close to the edge. I think with the initialization that ah4c has to do, sleep 2 should be enough though, from what I can tell.
Edit: I changed the ordering of the sleep command and it's working a little bit better now.
Edit 1: this is tested with osprey/dtvospreydeeplinks but I'm not sure if it affects channel # tuning as well.
Edit: seems sleep 3 is more reliable so far.
Finally okay claude made something more intelligent, ensure the box is awake and alive (streaming) before firing a tune. That way it always tunes.
main() {
adbConnect
adbWake
$adbTarget shell 'for i in $(seq 1 80); do dumpsys audio 2>/dev/null | grep -E "pack: com.att.tv.openvideo.*gain: GAIN " >/dev/null && break; dumpsys media_session 2>/dev/null | grep "PlaybackState {state=3" >/dev/null && break; sleep 0.1; done'
}
Using standard android frameworks (two of them whichever fires first) to detect rediness.
