I'm on latest created 6/10/26 on Synology NAS- Deeplinks with Osprey's. I haven't seen this issue.
Super weird. Are you on the latest CDVR update?
2026.06.29.0212
I would think if cdvr was doing it, it would show up in the support logs.
It may have had something to do with having 10 ospreys and running CH4C on 3 encoders. I just reset my DirecTV password and re-logged into all my boxes and while they still stall if I immediately tune without a pause after waking, which I kind of expect at this point, so far I haven't had that splash screen come up and interrupt yet. 
I think they only allow 2 streams via browser
edit; I just tested, had a stream running in firefox, chrome, and edge. I was thinking of this
so with ch4c it's possible the multiple sandboxed chromes are causing a hickup
1 Like
I honestly think CH4C got my account sort of in a weird state where it maybe got flagged internally.
From what I could tell from looking at ADB on the boxes with Claude, it appears that Widevine L1 kept getting torn down very early into the stream at random intervals. Since resetting the password, it seems like it's slowly improving, although not perfect, but it's super duper weird. Honestly, it was fun playing with CH4C, but given I have 10 Ospreys and two ENC5 V2s, I really don't need to use it. Especially if there's a risk of it causing issues with my account because I have so many devices attached. It is a fantastic tool though. I really do like it.
I only think it's that because I noticed CH4C wasn't working, so I went in and reauthorized it, and like a day or so later, I noticed things were acting weird.
I really don't know what was going on here, but I looked into it a whole lot more. The delay on tuning is definitely 100% needed because there is a feature flag that seems to be pushed out server side. I thought for a second it wasn't, but it absolutely is. It's really confusing and opaque what DirecTV is doing on their end, and it might be sort of an A/B test.
The other thing I noticed were my sessions were being torn down. I was able to resolve, and I posted the findings for that in the Osprey thread to keep it in the correct location. So super weird stuff. I don't know what kind of went down with my account or my boxes. The fact that it was all of them, but I do have a working solution.
Thank you @boukmandutty and @bnhf. Nine months later and I'm finally getting around to setting up AH4C PyATV and a Magewell card "made into" an encoder using GitHub - jpoet/Magewell2TS: Reads audio and video from a Magewell PRO capture card and muxes them into a Transport Stream. · GitHub and GitHub - mackandall/BroadCastHub: Broadcast Hub is a self-hosted web application for managing video capture hardware · GitHub.
Nice explanation here: BroadcastHub For Magewell and Decklink.
The more I think of it, I should be able to run AH4C Apple TV version in a docker container and run everything else to use the Magewell card as an encoder as native. Also, I don't think I need to pass my Intel Quick Sync driver through to the container either then. Am I thinking about this correctly? As long as I'm not using ffmpeg commands within the .env files of AH4C, and instead letting Magewell2TS and BroadCastHub work together to do the encoding, this should work to have just AH4C PyATV in the container?
Sounds about right. The Broadcast Hub essentially operates the way a link pi box would. So for example one of my inputs from my magewell card broadcasts over the network as
http://192.168.1.188:6502/stream/0-1
This means that any program can see what is being streamed. The channels changing control goes to either adbtuner or ah4c. This means that the docker would work as easily as running it in non-docker mode.
1 Like
Great, thank you! Time to roll up sleeves and try it out. I'm going to start with a new box and load all from scratch as my original CDVR Ubuntu is pretty out of date. I know @boukmandutty tested Broadcast Hub with Ubuntu, but I'm thinking of trying it with latest Debian instead. Since I'm setting this up for Spectrum and using Apple TVs as my streamers, I'll be following some good input I found in the following thread: Advice Needed - ADBTuner or AH4C?. Just thought I would link that here for anyone trying to do the same. So, just for clarity, here is what I'll be setting up. I'm not completely literate with all these steps but will be reading and trying it out. I think I have a general direction now:
- will leave existing CDVR on existing box (eventually may also move it over to repurpose existing box)
- new Intel box (I think I have a 9th or 10th gen Xeon) to be used for AH4C:AppleTV / Magewell cards using Magewell2TS and Broadcast Hub
- install Debian 13.5 or Ubuntu (may experiment with Debian first)
- ensure driver is loaded for Intel Quick Sync (no need to pass through to docker) to handle video encoding
- install docker compose
- use one-click from @bnhf for portainer / olive tin
- install AppleTV version of AH4C (running as docker)
- install 2 Magewell Pro Capture dual HDMI cards (fanless) to have a total of 4 streams at once (will probably never use that many at once)
- install Magewell2TS (native, no docker)
- Install Broadcast Hub (native, no docker)
- configure everything and cross fingers
Thank you all!
Quick question. Curious for some feedback on this, and I can probably implement it when I have some time. How hard do you guys think it would be, sort of like the way ADB tuner does it, to implement a wait for playback detection environment variable?
You know, something that is built into ah4c that holds back the video stream until video is confirmed playing. Just something to kind of cover up the tuning process and make things look cleaner. It's just a thought I had and maybe something I want to make a PR for if I could find a way to build it.
I'm curious what people think about this idea. Obviously it would be opt-in with an environment variable.
You can already do that (more-or-less) using "CMDx" and ffmpeg. There have been posts about it in the past, and I've used it myself. You're basically just letting ffmpeg deliver a black screen for x seconds to absorb whatever part of the typical tuning process you'd prefer to not see.
So, the issue with that is that replicates ADB tuners fixed delay feature. That actually does work, and I've used it in the past, but it's a fixed delay. Sometimes the tuning process varies depending on if a box has been in a deeper sleep or something like that. What this setting in ADB tuner does is it actively gates on something, which I'm trying to hopefully figure out, and only spins up the stream once that gate has been met. So, video is definitely playing if something has gotten a little slow. It basically, completely hides the tuning process even if that six or eight second window has passed and it's still tuning. It's a dynamic gate rather than a static one.
The reason why I'm looking into doing this is because I've set up Channels DVR for my mom, and I kind of want it to look clean when she tunes the channel. I don't want her to see any DirectTV junk. So I was thinking maybe I'd try to find a way to build this.
If a fixed delay isn't to your liking, you can also use ffmpeg to test for active video. I've written functions to do that in the past for active audio, using ffmpeg -- and I'm fairly sure you can do that with active video as well.
The parameters might be a bit trickier, but I believe you could differentiate between menu navigation and fullscreen video using ffmpeg. If you can do it this way, using a "CMDx" tee, anyone using any set of scripts could take advantage of it.
Fire up your bots and set them to the task! 
1 Like
I was just thinking it might be more user friendly to have it sort of built in as a function inside main.go. Especially if I can find a way to keep the diff fairly small to avoid regression and gate it behind an environment variable.
That way, people aren't messing with CMDx, I've done that and with a lot of tuners it gets really tedious. I asked TurtleTank what he's gating on, if he'd be willing to share, just so I can have a point of reference to implement with my bots. My plan was to just implement on my own fork and then test and PR once I'm sure it is working. And of course, I know you guys like minimal diffs, minimal changes, not verbose comments or any sort of verbosity, so I always take that into account when I submit a PR.
I always instruct Claude to implement with the least amount of code possible. 
where did you land with the audio check? I like the idea of audio check since that will catch a froze tune or other lockup. i've found that most of the time when I have a failed tune, a new attempt from ah4c (2nd tune) usually works.
1 Like
Oh, that's already implemented in the new scripts for the Ospreys. It works really great.
The only problem is, I don't think that's what Turtle Tank is using. I think it's more like bitrate. I asked, so hopefully he'll be willing to share the gate he's using, and then I can kind of work around that.
That also brings up my point with this. The readiness gate I implemented shows a flash of the previous channel before it tunes the new channel, which is why I wanted to clean up the tuning process a little bit.
Once you have the ffmpeg command figured out, a bot can update your Docker Compose accordingly with the appropriate CMDx variants -- which should make it pretty simple.
so, wouldn't it make sense to use the audio to trigger that the channel has tuned so you don't see the channel changing splash screen
Okay, I was just kind of looking to build something to benefit more people not just me, but that's fine. I'll just, you know, focus on an FFmpeg command. Sorry.