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

Playground
,
#1908

Ok, so I'm not on the latest version. I saw a date newer than my compose file and made an incorrect assumption. I'm in the middle of a recording now but will update to the new version after it's done. FWIW I manage with Dockge which is essentially just a frontend to docker compose commands.

As an aside, this reminds me a lot of the early days of MythTV. Smart people like yourselves programming their way through issues while untrained but persistent users like me keep testing and asking for help, rinse and repeat. I think we'll get there eventually and Channels DVR can fade back into the "just works" category :slight_smile:

#1909

I would suggest setting PYATV=true, even though you're not using pyatv, as that should skip some/most adb commands.

Other than that, as I understand the Osprey/Gemini, there's no app to launch. So, as long as you keep your devices awake, I don't see why you couldn't write a bmitune.sh script that would send a curl command based the $1 (channelNumber) and $2 (streamerIP) values passed to the script.

prebmitune.sh and stopbmitune.sh need to exist, but can be "no-op" scripts.

I believe a posted a sample M3U file for you earlier that would have your channel numbers in it, which would pass the channelNumber value.

You should plan on finding an AI agent you like to help you with this. Also, as @anon38303228 said you'd really be best off using ADB -- and all evidence we know of suggests the problem you're having with your Geminis is something you should be able to resolve.

So our #1 recommendation is to get adb enabled, however this alternative option should work (though you'll be ah4c feature limited). It's also worth noting that you'll be an outlier in terms of how everyone else uses this (and other similar) tools, which of course, makes it more challenging for others to help out.

#1911

Nevermind, part 2 I got ahead of myself -- the container didn't update when I changed the compose. I thought I ran a pull but forgot :grimacing:

#1912

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
#1914

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.

#1915

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.

#1917

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
#1920

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.

#1922

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.

#1923

64GB

#1924

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.

#1926

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
#1928

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.

#1930

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.

#1932

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.....

#1933

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.

#1934

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!!

#1935

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!

#1936

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

#1937

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.