Okay, good to know because, previously I was using the in-menu reset, and I think that could have been why my boxes were acting sort of corrupted.
I do adb reboot, until the problem isn't fixed. lol then I get off my butt and push the button. 
also, just to circle back with linkpi stuff, have you tried changing the linkpi's edid on the fac.php page
I use 1080 since that's all it's encoding anyway.
1 Like
I have tried every single EDID, but I just factory reset every single box using the reset button on the side.
So far it's been good since I did that. I mean, it's still early. I just finished setting everything up. So now I just hold and hope that it continues to work.
I think my boxed had gotten into a corrupted state somehow.
I think ™️ I solved this!! Opus 5 cracked it in a handful of prompts!!! Heavy APK decompilation from the boxes helped.
What's actually causing it
It's not the network. It's not the encoders. It's the DirecTV client.
There's a UI inactivity timer in the app set to 5 minutes. If nothing touches the box for 5 minutes it fires an event that dismisses the UI, and on these boxes that event also tells the player to restart playback. That restart is the blue flash.
The important part is it's a debounce. Every button press resets the 5 minute countdown. So if anything sends input to the box, the timer starts over.
Why it only seems to happen to me
The big one is that we tune these over ADB instead of with a real remote. That's the whole difference.
When you fire an am start deeplink at the box, the app sees that as another app handing it an intent. It flags playback as terminated by a third party app launch and arms itself to resume playback when you come back. That's a normal feature, it's there so you can jump into Netflix and come back and your TV is still on. A remote never does this because a remote isn't another app. So every tune we do arms that resume path.
Then the second half. Nothing touches the box for 5 minutes. If you're using a remote you're hitting buttons constantly and the timer never gets there. We tune and walk away, so it counts all the way down and then "resumes" a stream that was already playing. That's the flash.
You need both. A regular person with a remote never arms the first one, so they can leave the TV on all day and never see this.
There's a third thing too. This whole feature sits behind a server side feature flag, and the flag system they use supports percentage rollouts and target groups. So it can be switched on for some boxes and off for others with the same app version. That's probably why it's only me and why it seems to come and go on its own.
This also explains something that drove me crazy for weeks. Any time I got into ws-scrcpy to watch a box and figure out what was happening, it wouldn't happen. Because I was pressing keys while I was watching. The act of looking at it prevented it.
The fix
Send a harmless keyevent every few minutes. That's it. For ADBT:
"timed_keep_active_commands": [
{
"run_every_minutes": 3,
"commands": [
"input keyevent 211"
]
}
]
Some notes on that:
It has to be under 5 minutes. I'm using 3 which gives some margin in case one gets missed.
Use keycode 211. That's KEYCODE_ZENKAKU_HANKAKU, a Japanese IME key that doesn't do anything on a US TV app.
One keyevent is not enough. I thought a single press after the tune would be enough and it isn't. All it does is restart the 5 minute countdown from whenever the key lands. So if you fire one at 60 seconds you've only pushed the flash out by 60 seconds, from 5:00 to 6:00. You didn't stop it, you moved it.
It has to be on a repeat under 5 minutes or it will always catch up with you eventually.
Other stuff that is NOT the problem
I burned a month on this so save anyone else the trouble. None of this had anything to do with it:
- router (I swapped to a completely different router, same exact 300 second behavior)
- public IP (unplugged my WAN for 2 hours to force a new one, no change)
- DNS (tried every provider. the boxes hardcode Google DNS anyway and ignore whatever you set)
- encoder firmware (tried 3 different LinkPi builds)
- switches, cables
- HDMI CEC and EDID
- factory resetting the boxes
- new DirecTV account
One more thing
This looks like it got introduced in an app update. I pulled apart a December 2025 APK I had sitting around and the code that restarts playback isn't in it. The 5 minute timer is there but it only dismissed the UI, it didn't touch playback. So something changed after that.
The keyevent workaround doesn't care about any of that. It just never lets the timer get to 5 minutes.
Edit / Correction
It's not the actual deep link that is the mechanism. It's the sleep and then the eventual wake and unattended tune that is the mechanism that causes the issue, combined with the server-side flag that gets set at random on a box. The box doesn't realize it's being watched actively by a person, and after five minutes of what it deems as inactivity, it retunes to the last channel that was being watched, which happens to be the channel you just tuned to, which is the whole issue.
ah4c with channel #'s uses input text $channelID so no new activity is started.
so I only learn android as i need to and now I know am start is activity manager starting an activity. 
I think I've 'fixed' my issue by doing many things, but there are a few key things I can test 1 at a time after I verify everything settled down.
Yeah, I actually tested with input text as well and ran into the same issue. So I think it's just going over ADB.
I noticed that discrepancy and now, just out of curiosity, I'm digging into the APK to figure out why input text behaves the same way as am start. The point is this is a feature flag that's currently rolling out server side at random to people, including myself, and eventually it's possible that it's going to affect others. So I found a very durable solution. It has to be scripted into ah4c at some point if it starts hitting more people, and I'd be happy to figure that out. I mean, I basically have it written with my keep_alive.sh that I wrote. It just has to be done a little bit more durably so it's mandatory for those scripts if this starts hitting more people.
Once I figure out why input text also causes it, I'll update
Okay, I did a bit more digging, and the explanation's a bit more pointed and makes a lot more sense.
The issue is the sleep at the end of the process, and the tune then arms the actual issue that occurs. So it's not actually the deep link or the input text that's causing it. It's the fact that it's being woken and tuned without user input. So it's hitting this code path that is causing the problem, and it requires a heartbeat every three to four minutes in order to stay alive, basically, without retuning itself.
It's not the fact that it's am start or input text, it's the fact that it's being tuned over ADB and the box doesn't, for some reason, realize that it's really being watched. So it re-tunes to its last watched channel, which happens to be the channel you just tuned after five minutes to the clock. That's the actual mechanism here.
The solution is there is then to send a heartbeat every three to four minutes like I'm doing, which just mitigates it and pushes it up another three to four minutes. So as long as that periodic heartbeat is being sent, the retune never happens.
The thing is, it's good to get this documented now because it's going to roll out to more people eventually. It's just a matter of time before others start seeing this, and it just happened to be me that got hit first, I guess. Maybe because I have so many boxes. Maybe because I'm unlucky. Maybe I was just meant to solve this problem. 
ok, so i've been thinking for a while that it would be sweet to have a adb-IR or adb-keyboard bridge (to emulate a usb or bluetooth keyboard)
one place i've been going to investigate was linkpi. I know they can be controlled with a remote, and I believe they can send IR commands, but that's about as far as i've got.
I think this would be better for like a raspberry pi.
Like with an IR blaster.
The ospreys do have IR receivers.
Oh, there is an issue with tuning by channel numbers that I discovered.
If you have a large DirectTV package that has overflow channels for like RSNs, it's impossible to tune those by channel number. You need deep linking.
via adb ? I assume the - on the remote does actually work. what about a keyboard?
Anything done via ADB will trigger this issue if you have the feature flags randomly rolled out to your boxes.
If you use an actual remote it does not trigger it I confirmed because I have another box that was provided by DirecTV on lease and I never encountered with the issue. Also when I interacted with my boxes that are plugged into the encoders with ws-scrcpy it seems to not really cause the issue probably because it was pushing it out each time I pressed a button.
This is all coming from decompiling the actual com.att.tv.openvideo APK that I pulled off a box. But the truth of the matter is the fix actually held. It's working. I haven't had a single issue since I implemented this last night. And this is something that would have happened already like I would have already run into the issue again very quickly. It went from happening every single tune five minutes to the clock to never happening at all.
no, i'm asking to know if it's worth it to pursue an adb bridge
I don't think so at all. I think the solution is very clean as just sending an invisible keystroke every three minutes. It's very easily scriptable and has been reliable.
I have it implemented an ah4c with a keep alive. I just have to kind of tweak it so it isn't a keep alive script anymore and it's just a mandatory make this problem go away script. Once I have some energy I'm going to test in ah4c and try to get it working there. I also did a ton of work on the channel number tuning scripts to kind of make them a little bit more reliable and resilient if you want I can share those with you so you can test them since I know you use those a lot.
Like I know I shared something a little while ago but I kind of redid them again because I was having failures with the ones I shared a a few days ago.
The idea though would just have a shell script run that sends the invisible keystroke every three minutes. It uses minimal resources and is really cleanest solution. With ADB Tuner it isn't even a question. It's already built into the config and I shared the actual configuration I'm using that gets around everything in the first post of this thread.
I understand what your saying. I have other reasons for possibly pursuing something like an adb bridge. I do not have any channels w/ sub channels. I'm curious if an average gemini user can enter the channels with the remote, or do you have to use the guide or voice command? if the remote can be used to enter the channel# , I'd then like to know if a usb or bluetooth keyboard can also.
So if you have overflow channels you can't enter them with a remote. You have to use the guide that's why deep linking is really good if you've got overflow channels because they work with Channels.
Like an average Gemini user has no way of accessing any sub channels or overflow channels without using like the actual guide to navigate to them manually.
ok thanks. 
silly me for thinking that since directv put a dash on the remote, that they would use it in their programming.. lol 
I would think they would but the dash really seems to do very little.
I tried so many ways to tune one of those channels and it was just impossible.
Regardless, I just wrote with Claude a couple of scripts that replicate what I did with ADB tuner. I'm going to hang on to them for a little while though and maybe open up PR once more people start seeing this issue.
Here's a subnumbering topic that came up a couple of years ago with a possible solution. I never tried it but maybe it gives you guys some ideas.
If anyone runs into this I don't want to open a PR because I'm kind of in love with the new ADBTuner development build until someone tells me these are good but here are scripts that should resolve this issue if anyone hits it which I expect others to hit soon because it is a server side flag 100 percent.
Edit: I tested everything and opened a draft PR until this rolls out to more people and becomes needed.
2 Likes