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.
I think I'm going to mark my scripts ready for review. Does anyone have any objections? Sorry for the tag, but I'd really appreciate any input from @bnhf as a maintainer of ah4c.
Did an A/B test today with ADBTuner and confirmed that without the heartbeat, I get these reloads still. And it seems like this is going to hit more people, so it might be better to get the new ah4c scripts out there before it reaches a larger crowd.
I just tested out the deep linking script set, and it's working great. Right now, I'm playing around with the channel number scripts that I wrote that are completely refactored, and so far, they have been tuning reliably.
The scripts look good. The only change I'd request is to use keycode names (like KEYCODE_ZENKAKU_HANKAKU) rather than numbers (like 211). IMO, this keeps the scripts more human readable -- and avoids having to look them up. 
Thanks, I will update that.
I marked it ready for review and made that change. The only thing is, there's a match encoder URL function in the Deep Links script that I did not take out. I wasn't sure if that's needed. It doesn't seem to do anything.
That function is used in other scripts, but not this one -- so yes, you can remove it.
Also, a small style request:
Please put a blank line after the end of each function -- another thing that makes for improved readability.
After that, feel free to submit a PR.
Thanks. I also cleaned up some more Fire TV leftovers that don't really need to be there for the Osprey boxes. Just some more dead code. I added that white space as well and removed that function. So far, everything's tuning nicely!
I actually got a call yesterday from DirecTV's executive team, and supposedly I'm going to hear from some advanced technical support, so at least I'll be able to find out what is going on on their end that caused this. I decided to contact their social media support, and that got things escalated for me. So, I don't know if this is like something that's really going to roll out, but it's been affecting my 10 boxes for over a month now. So, I imagine it's going to hit more people soon. Or I'm just very, very, lucky!! 
Personally, I have to wonder how good of an idea it is to bring executive visibility to our niche usage. Unless I've misunderstood your latest posts, everything works fine when using the boxes connected directly to a TV and using a remote, no?
Somewhere in the Castle le Jean here in Miami, my firetv and onn puck is chugging along.
I still can't believe you got TEN Osprey boxes. 
My electric bill would bankrupt me...and also the electric in general would go out frequently in my unit
I wasn't intentionally bringing executive visibility.
I was actually having wedging issues when entering a channel number too quickly with my boxes connected to a TV as well. And actually, the executive department got contacted before I figured out the fix. I basically told them that I don't need help anymore.
If anyone else calls me, I'm probably just going to ignore it. What happened was, I contacted them on Twitter because I was at a complete loss and ready to cancel. Then the day after that, I figured out the problem with Opus 5. Then yesterday I got a call randomly from the executive department. I tried to tell the woman that I really don't need help anymore.
But yeah, they were pretty insistent on like looking into this, and I basically told them I don't want to anymore because I solved it, and I'm just going to ignore their calls at this point.
Edit: I just got the call with them and I told them that I don't need help anymore. So, no need to worry.
so the current scripts/osprey/dtvosprey is outdated and I have my own custom so I welcome a fully baked new one. I would request an env toggle for the 3min keystroke though, so we don't have to turn it on until needed.
It's actually baked into the script. So you can just change it to whatever value you want or remove the value. I didn't make it a toggle because eventually it seems that it's just going to be needed. People are going to wonder why their streams are reloading five minutes in. This one should tune better, particularly for channel numbers. I think it will also be a bit more reliable.
I agree with the env toggle. Iād prefer turning it on when itās required rather- might need it tomorrow or next year.
My deep links work so good now.
In all honesty, it's an invisible keystroke. It doesn't actually show anything on the screen. There's no computational power taken from it, really. It's negligibleāif at all. And it's nothing you'll see or even notice, so there's really no point in adding more complexity to it, in my opinion. I've been tackling this for the better part of a month, and this is just a flag that's likely to roll out fleet-wide to everyone. I don't know why they're trickling it so slowly. Hopefully, they roll it b ack if they had any sense. The advantage of leaving it alone is that when it does roll outāif it doesāyour DVR recordings won't suddenly break without you knowing.
New bnhf/ah4c:latest (aka bnhf/ah4c:2026.07.30) pushed this morning with the latest changes to scripts/osprey. @Shaggylive @jagrim I did add an env var $HEARTBEAT_INTERVAL, which when set to 0 can be used an opt-out for the heartbeat code added by @mackid1993. It's enabled at 180 second intervals by default though.
EDIT: Also, I've changed the ffmpeg package included in the container to the one from the CDVR repo. The CDVR version does not have MagicYUV enabled, which eliminates concerns related to the exploit that takes advantage of that feature.
Interesting thing, my Ospreys updated last night, and it seems like they might have reverted whatever was causing the need for the heartbeat interval. However, I'm not ripping it out of my script at least because it could easily come back. The feature flags are still there according to the decompiled APK. I think the environment variable that bnhf added is probably the best solution for this. And the readiness gate is honestly just correctness to begin with. This is all just a learning experience in the end that went on way too long. So in the end, we ended up with two reliability flags that may or may not be needed but are there in case they are.
This is the beauty of open source, collaboration and bash!
Sometimes, I think you pissed off the Directv Gods by running (10) Osprey's. I haven't seen any update on mine since I got up and running in July 2025. Boxes are all the 60164 model.