AndroidHDMI for Channels (ah4c): A virtual channel tuner using HDMI Encoder(s) + streaming stick(s)

New bnhf/ah4c:latest (aka bnhf/ah4c:2026.09.28) pushed this afternoon with support for the container's hostname to be used in the topline menu of the WebUI, and in browser tabs. This means, if you have multiple containers, that hostname will help distinguish between the two.

Typical hostnames are ah4c when you have a single container, and ah4c2 for a second. This is also the way multiple containers are handled when deploying them using Project One-Click. The value of AH4C_CONTAINER in Project One-Click is appended to ah4c.

2 Likes

My recordings have been going great the first two days. Closed captions are the final piece in the WAF puzzle. I'm finding 4 seconds behind with Cohere is significantly different from the broadcast channels with embedded captions. I'm lowering it to 2 seconds to see if that's better.

I've been having good success with Purfview Faster Whisper XXL model largev2 using Subtitle Edit on Windows. My Channels VM doesn't have access to the iGPU, but my media VM (where ah4c sits) does. I'm thinking of installing something there to generate captions after recording. My two biggest issues are what to install and how to run it automatically after Channels commercial detection is complete. We almost never watch live TV, and captioning after the fact would be much more synchronized. I know this is going outside the subject of the thread and can take it elsewhere.

I feel like every few threads it's important to thank the developers for writing this and making it so easy to implement. I like to say "it's just TV," but when TV dies a lot of voices are suddenly clamoring for the TV they lost. It's nice to be able to bring it back.

You should probably take a look at this project:

Last I looked at it, it seemed a bit challenging to get started, but that may have changed.

Will do. I'm recording one with a 2-second delay right now. If that passes the wife test I won't need to look any further.

2 Likes

I have an iGPU and NVIDIA card on my Proxmox server. The NVIDIA card is passed to one of my VMs and the iGPU to my media VM because it was recommended for Plex/Jellyfin transcoding. I have ah4c on the media (iGPU) VM right now. According to ah4c it ran Cohere 4 second delay at 4x or higher; it's currently running Cohere 2 second delay at 2.9x. I'll try Parakeet real time and Nemotron real time to see if those are any better if Cohere 2 seconds doesn't work for us.

Proxmox is a subject that's very near-and-dear to my heart. I run almost nothing bare metal anymore, everything is virtualized on Proxmox, and it works incredibly well for me. There's really nothing better for the tinkerer. :slight_smile:

One suggestion I would make. VMs are great for something like Windows, but LXCs are the answer for just about everything else. It keeps virtualizations lightweight, and allows for the sharing of resources like an iGPU across those virtualizations.

In fact, Channels DVR itself makes an excellent LXC:

Then you can run Docker in another LXC, with ah4c and other projects. Moving LXCs like this from one Proxmox host to another is super easy with a Proxmox Backup Server, to balance loads or to take a host down for an upgrade or other maintenance.

64GB

I'm still new at Proxmox and built my system based on the best recommendations I could find during my preparations. I have a dedicated Channels VM and a separate Media VM that has Plex, Jellyfin, ah4c and anything else I want to access the iGPU while also seamlessly accessing each other.

I'm looking at spinning up a 2nd CDVR server to be my Mom's (using the main CDVR as the channel source) because she seemed surprisingly open to switching how she watches TV. If I do, I'll make that one an LXC and see how I like it. If that works maybe I'll spin up an LXC for my main server and migrate the settings there. One thing at a time, as she absolutely requires stable captions as opposed to my wife who just prefers watching that way.

Those are the old remote control emulation scripts we used before the deeplinks were uncovered. There's another set of scripts that use deeplinks.

1 Like

Experiment away! We have two relevant sets of scripts firetv/dtvdeeplinks and firetv/dtvstreamdeeplinks. We needed two back before the "merge" of DTV and DTV Stream. Not really necessary now. I'd suggest working with firetv/dtvstreamdeeplinks as a starting point.

On a grander scale, I think a number of scripts could transition from device specific to a device of all. The differences are so minimal anymore that I believe we could move most to all/<provider>, since other than package name, most scripts are close to identical.

Limited testing so far, but it does look good! It still takes a bit to load the app cold, but the warm tunes are nice and quick. I put the scripts in scripts/all/dtvstreamdeeplinks (and adjusted the comment block accordingly) on my local system, and I think that's where we should put these when merged.

Ive been playing with the adb ah4c now this morning with two android devices in the same container for the first time. I ran into more LinkPi issues, but I'll report that in the linkPi thread.

Now that Ive been playing around with this, is it conceivable to have different scripts assigned on a per tuner basis (in the same container)? At the moment Im not using this for DTV. Ive got a use case where one of my tuners is running paramount +, and Id like my second tuner to run the channel 4 UK app on a different stick

Instead of firing up a third container, which Im considering, I thought Id put this out there....

How about , as long as one is using adb control (not the PYATV) in their container, when a new tuner is added in the ah4c UI, you have the ability to load a different bmitune, prebmitune, and stopbmitune for each tuner as they are added (make this optional)

This way one of the tuners can have different VPNs set up to different locations

Then the tuning scripts wouldn't have to take the extra time and overhead to manage all that stuff for each tuning sequence. In my experience it can save 10s of seconds of tuning time.....

Not quite the way you're requesting. As I read your question, you're basically asking (again) for the tuner pool to not be interchangeable. This is not the way ah4c is written.

We do, however, have the ability now to run different sets scripts based on the provider. In other words, the tuner pool is still interchangeable -- but, the scripts can vary. This is done by creating an all.m3u, from two or more other M3Us, using the WebUI.

EDIT: I will amend this slightly, to say that it is possible to specify a single tuner to use in a tuning URL. This is done by adding the tuner number, like so: play/tuner0/ or play/tuner1/. If you're only looking to pin one tuner, and all tuning URLs in the M3U you are using specify either one tuner or the other (assuming two virtual tuners), this could work.

There are obvious downsides to this approach, but it is a possible method. You'd start by creating an all.m3u, and then editing it to assign a tuner to each tuning URL.

Yes - this is the way

I got hung up thinking that the limitation in the ah4c architecture with the tuner pool was due to the differences between PYATV and ADB flavors of containers and asked again for script per tuner granularity.

Now that Im in the (every tuner in this container is android based) - if I can pass the actual device from the all.M3U that looks great . I'll play around with this approach. Thank you!!

I forgot to re-edit the script after updating and lost my first recording that was on "E! HD" due to the space. Can the double- and single-quotes be added to the xfinity script permanently if you don't think it will break anything else @bnhf? Thanks!

Done. Pushed as bnhf/ah4c:latest (aka bnhf/ah4c:2026.09.30).

After playing MeTV for about 3 hours, I stopped the stream and waited for that tuner to be idle. Multiple subsequent tunes to different channels failed on that virtual tuner. One has to wonder if the DTV app will ever be reliable enough to be able to keep it warm.

Sorry to hear that. You will definitely be missed! Thanks for the work you've done on ah4c. Others will benefit from it for some time to come.

4 Likes

I've tried all of the closed captioning engines over the last few days. I think Cohere with Roll-up, 2 lines and a 2.0 sentence length is the best we've seen so far. I watched a show with my wife, being careful not to say "notice the subtitles," and she didn't have any complaints.

Ideally I'd like to run captioning after the show is complete, because the difference is noticeable. EDIT: this has already been solved here and I missed it! Synchronized Closed Captions for Channels

It doesn't look like there's a way to scan the file after it's finished and inject captions into the file's metadata the way ah4c is doing in real time. I tested a 30-minute show and captured an srt with Openwhisper-XXL and the large-v2 model in 8 minutes using the NVIDIA card on my Windows machine. The quality in terms of accuracy and appearing when the words are spoken instead of 2-3 seconds later is unmistakable. I didn't expect them to work, but neither an srt dropped next to the recording nor a muxed mp4+srt > mkv were recognized by Channels. I'm going to keep up not saying anything for a few days and see if the captions cause any complaints.

Thanks for your hard work, @anon38303228. Enjoy your rest!

Take care of yourself first and get back to doing what's best for you. Remember, it's only TV.

3 Likes