Maybe this is part of the issue? Perhaps this commit was meant to be tagged 0.17.1? It's what I intended, but it seems the version number is off.
It all works great now on latest appletv:test, though I'm also getting Version: 0.16.1.
What will be the upgrade path if and when pyatv 0.18 is released? (admin said this will happen soon)
Thanks!
Let me know when that happens, and I'll build a new container.
Sure.
Built as bnhf/ah4c.appletv.test2. I set this up to install whatever version is considered current by pip3 -- which should be 0.18. If you could confirm that the container functions, along with it containing this most recent version, I'd appreciate it.
If everything looks good I'll build this again as :appletv
Looks good so far.
Container has 0.18 and tuning with no errors on my end!
1 Like
I just started this up and seems to be working good so far...
root@atvtuner:/opt# atvremote --version
atvremote 0.18.0
root@atvtuner:/opt#
No issues for last few hours...
On another note, I think I had mentioned in an earlier msg that suddenly the ATVs were turning on captioning everytime now. I figured out what was happening for me. For a long time I sent commands that would actually completely shut down the spectrum app when exiting. Apparently with one of the lastest Spectrum versions it looks like they don't remember your captioning settings if you close the app completely out on the ATVs.
Tested with just using "home" for stopping and it remembers your last state. But it goes right back to captions if you loose power or shut the app completely off. 
1 Like
This is done. New bnhf/ah4c:appletv built this morning -- so, I'll be deleting :appletv.test and :appletv.test2 shortly.
Now that :appletv is using a Dockerfile that's very close to :latest, I'm leaning towards merging these two. They will always need different start scripts though, which we'll handle with an env var like PYATV=true with a default of false.
1 Like
Can you explain this further? Do you mean that deployment will look at the PYATV tag to build the container, Or do you mean we will need to adjust our tuning scripts?
The idea is no changes for you -- other than needing to set an env var. That env var will determine which start script the container uses. This is not any of your scripts, this is the script the container uses when it starts. My thinking is, a single ah4c container that works with both ADB and ATV targets, will be easier to maintain. For the :appletv crowd, this should mean more up-to-date builds.
This is what I thought, it sounds great, and makes sense for maintainability.
Happy to deploy ah4c:latest in a test container using the new environment variable to test the merged code. Just say the word....
As usual - thanks for all you do!
hey @bnhf wanted to flag a potential security issue that I stumbled into when reviewing another thread that @jkister pointed out:
It looks like MagicYUV is enabled when I looked inside my container, and ffmpeg in the container build is at a vulnerable old version
from my container:
Image: bnhf/ah4c:appletv
ffmpeg: 5.1.9-0+deb12u1
MagicYUV: VFS..D magicyuv — ACTIVE
I guess the fix requires an upgrade to ffmpeg ≥ 8.1.2 inside the image? Would you be able to trigger a rebuild of the :appletv tag when you get a chance? Or put the fix elsewhere if/when you decide to have everything merged and managed from ah4c:latest?
Happy to pull and test once updated.
Im actually not sure where ffmpeg is used in the container. tesseract OCR?
1 Like
ffmpeg is used by a number of scripts, as it can detect active audio, among other things. Also, ffmpeg can be used for post-processing to correct for HDR being removed, or to encode for capture cards like the Magewell.
I'll have to figure out what the best path forward is. ffmpeg 8.1.2 is not part of any stable repo yet -- in fact I think it's only a week or so old. I could potentially compile it at build time, though I don't love the extra time required. I'll see if I can get it as a stable binary from a trusted source...
1 Like
@mnwxman132 After contemplating this for a bit, I think the best path forward is to use the same custom version of ffmpeg and ffprobe that CDVR uses (no MagicYUV encoding enabled). This is what I do to get those binaries for OliveTin, so it makes sense to do the same here.
I've built a new bnhf/ah4c:appletv.test that grabs ffmpeg and ffprobe from where CDVR hosts its installation downloads. This change will make sense for the mainline version of ah4c as well, so once I get a thumbs-up from you on functionality, I'll proceed with building that one-size-fits-all version of ah4c that'll work with both adb and atv targets.
1 Like
Ok I deployed this and took a look.
PYATV is installed and at 0.18
MagicYUV is not installed - GREAT
However ffmpeg is reporting 4.2.4. My current Channels DVR install is running 6.1.2 (confirmed from latest/ffmpeg). Looks like the download endpoint may be pointing to an older CDVR release. The 4.2.4 matches the older CHDVR stale build directories I cleaned off my Mac yesterday. Can you verify which CDVR download URL you're pulling from?
hope this is helpful
Edit: i realized this morning another piece of info. I use the prerelease versions on my server, so at some point the update to ffmpeg must have come during a prerelease updates. Im not on the public release of CHDVR.
I used this curl command this morning to test the version of ffmpeg:
curl -fsSL "https://channels-dvr.s3.amazonaws.com/$(curl -s https://channels-dvr.s3.amazonaws.com/latest.txt | tr -d '\n')/ffmpeg-linux-x86_64" -o /tmp/ffmpeg && chmod +x /tmp/ffmpeg && /tmp/ffmpeg -version
This is more-or-less the same logic used in the Dockerfile. It returned:
ffmpeg version 6.0.2 Copyright (c) 2000-2023 the FFmpeg developers
I haven't changed anything, but I rebuilt bnhf/ah4c:appletv.test in case latest.txt hadn't been updated when I built the last version. Let me know if you see the same ffmpeg version. If not, I'd like to know what container architecture you're pulling, as that's the only remaining variable I can think of.
Did some further testing with my new best friend uncle Claude.
I updated my stack with pull and redeploy using appletv.test
With uncle Claudes help, I Confirmed that my new container image is correctly pulling ffmpeg/ffprobe from https://channels-dvr.s3.amazonaws.com/2026.06.29.0212/ and the container matches those exact binaries by hash. That release bundle itself contains ffmpeg 4.2.4 and ffprobe 4.2.4, with MagicYUV clean. So the build path is correct; the source artifact is just older than expected.
in portainer - first few lines of the YML are:
version: '3.9'
services:
ah4c:
image: bnhf/ah4c:${TAG}
container_name: container-test
hostname: tuner-container-test
dns_search: ${DOMAIN} # Specify the name of your LAN's domain, usually local or localdomain
ports:
And the first few env variables:
TAG=appletv.test
DOMAIN=localdomain
ADBS_PORT=
HOST_PORT=7654
WSCR_PORT=
IPADDRESS=192.168.1.52:7654
Now my tuner has been and still is working fine, with pyatv at 0.18, and the actual security issue is mitigated because MagicYUV is disabled.
Im not currently even using ffmpeg in my container. If others, however, using the merged ah4c:latest, are expecting one version, and getting an older version of ffmpeg installed when updating their containers - Im not sure whether that would have an impact in their tuning implementations.
I really do like your idea of standardizing the ffmpeg with what the channels developers have released - this makes perfect sense. But things can get a little confusing here.
For instance, on my host Mac mini I get this:
"~/Library/Application Support/ChannelsDVR/latest/ffmpeg" -version | head -1
ffmpeg version 6.1.2 Copyright (c) 2000-2024 the FFmpeg developers
And you got version 6.0.2
Im sorry to open a can of worms for you on this when I noticed the ffmpeg security issue.
I believe what I'm hearing from you here, is that the arm64 version of ah4c:appletv.test contains older versions of ffmpeg and ffprobe than what my testing showed would be included in the amd64 version of the container (which is 6.0.2)?
1 Like
Yes that's what Claude is telling me. It had me do a bunch of probes inside my container and also from the host, and looked at the binaries and compared the timestamps and hashes of your build this morning around 7:03am
Further output from Claude:
What this means
The image build is correct; the Channels DVR release artifact is the source of the older binaries. In other words, the build is doing exactly what bnhf intended — it’s just retrieving the version Channels published in that release, and that release’s binaries are still 4.2.4.
Why the extra confusion happened with you getting 6.1.2
The Mac mini’s ~/Library/Application Support/ChannelsDVR/latest/ffmpeg and the historical dated directories are a separate Channels DVR install tree on the host. Those directories can contain different ffmpeg versions over time, and the latest symlink points at the currently active server install, but that is not the same mechanism as the S3 release artifact the container is downloading. So the host version and the S3 release bundle can diverge.
edit: @bnhf to answer your question - Further from Claude regarding arm vs amd
in this case it is not the main reason you’re seeing 4.2.4. The key thing is that container-test is being built with TARGETARCH=arm64 , so on your Apple Silicon Mac it is pulling the arm64 Channels DVR release artifact, not the x86_64 one
@mnwxman132 New bnhf/ah4c:appletv.test built with what is hopefully updated arm64 versions of ffmpeg and ffprobe. Please confirm when you have a chance to test.