Advice Needed - ADBTuner or AH4C?

Playground
#41

Been running the Apple TV version for a year with great results, but... channel tuning takes 6 to 7 seconds before the app is started (Sling TV in my case). I see this error in the logs, reflecting the reason for that delay. I wonder if someone can point me in the right direction... (maybe @ChannelSam?). Thanks.

2026/06/06 15:00:47 [EXECUTE] Running [./scripts/atv/spectrum/bmitune.sh 1501 10.10.11.42]
2026/06/06 15:00:53 [EXECUTE] Stdout: '2026-06-06 15:00:52 ERROR [pyatv.protocols.companion]: Could not fetch SystemStatus, power_state will not work (Command FetchAttentionState failed)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/asyncio/tasks.py", line 490, in wait_for
return fut.result()
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/locks.py", line 213, in wait
await fut
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/api.py", line 163, in _send_command
resp = await self._protocol.exchange_opack(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/protocol.py", line 154, in exchange_opack
return await self._exchange_generic_opack(frame_type, data, identifier, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/protocol.py", line 167, in _exchange_generic_opack
unpacked_object = await self._queues[identifier].wait(timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyatv/support/collections.py", line 160, in wait
await asyncio.wait_for(self._event.wait(), timeout)
File "/usr/local/lib/python3.11/asyncio/tasks.py", line 492, in wait_for
raise exceptions.TimeoutError() from exc
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/__init__.py", line 211, in initialize
system_status = await self.api.fetch_attention_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/api.py", line 346, in fetch_attention_state
resp = await self._send_command("FetchAttentionState", {})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/companion/api.py", line 174, in _send_command
raise exceptions.ProtocolError(f"Command {identifier} failed") from ex
pyatv.exceptions.ProtocolError: Command FetchAttentionState failed
'
2026/06/06 15:00:53 [EXECUTE] Stderr: ''
2026/06/06 15:00:53 [EXECUTE] Finished running ./scripts/atv/spectrum/bmitune.sh in 5.74837329s
#42

Replying to myself in case it helps. All these errors come for FetchAttentionState command being dropped on most modern Apple TVs. Since bnhf/ah4c:appletv is using a very old pyatv version (0.14) upgrading t to the newest version (0.17 - and it has to be the master branch to include the latest fixes) inside the container solves all these issues.

Tuning is now instant and with no errors.

@bnhf Could these changes be made permanent on your bnhf/ah4c:appletv branch? Thanks.

#43

Could you give bnhf/ah4c:appletv.test a try and see if it works? It built OK with the latest pyatv, but I don't have a good way to test it.

#44

@uspino @bnhf
I will try and test the new version some this week when I get a chance.
I remember originally bnhf had to leave it on an older version of pyatv because the newer one at the time wouldn't build or something without errors.
My setup has slow tunes anyhow because I use it for a secondary location with slow some what unreliable internet. Either from the latest apple system update or spectrum app updates it suddenly wants to turn on closed captions every tune. I haven't been able to completely disable CC like before. For a quick fix I give it plenty of time to tune then send individual commands to open the CC menu and turn it on then off. This works until the next tuning.

#46

@bnhf Finally had time to try. I get this error in exec console, no chance to pair:

atvtuner:/opt# atvremote
Traceback (most recent call last):
  File "/usr/local/bin/atvremote", line 6, in <module>
    sys.exit(main())
             ~~~~^^
  File "/usr/local/lib/python3.14/site-packages/pyatv/scripts/atvremote.py", line 1022, in main
    loop = asyncio.get_event_loop()
  File "/usr/local/lib/python3.14/asyncio/events.py", line 715, in get_event_loop
    raise RuntimeError('There is no current event loop in thread %r.'
                       % threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'MainThread'.
atvtuner:/opt# python3 -c "import pyatv; print(pyatv.__version__)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import pyatv; print(pyatv.__version__)
                        ^^^^^^^^^^^^^^^^^
AttributeError: module 'pyatv' has no attribute '__version__'

Claude hints to maybe an outdated Python version...?

#47

Seems unlikely, since we're using the pyatv container as a base.

Let's approach this a different way. What exactly did you do to update pyatv in the previous ah4c:appletv build? If you give me the specific process you followed, I should be able to update the container in the same way.

#48

I know Apple recently broke pyatv on tvOS 26.5 and possibly 26.4. I'm not 100% sure if they fixed it. I there is a community-supported patch, and it's possible that the actual patch was merged into their master and possibly just not released yet. I'm personally waiting for it to get merged into Home Assistant.

#49

I had this same issue. Noticed that it only seemed to happen on the very first tune. I was killing the app after a period of time for a good reason that I don't remember now, but apperently that is no longer necessary. So I just stopped killing the app, and have not had the auto CC issue since. Downside is that on a system restart, I need to manually tune to a channel to stop the issue, but I think I can automate that. A "double" tune also worked, but this was easier.

Anyway, thought I would share.

#50

After a regular install (bnhf/ah4c:appletv) I did a simple

pip3 install --upgrade pyatv

from the exec console, and I re-paired, just in case. Truth be told (I'm very much ignorant in Docker inner working) it looks like the appletv.test branch is not even installing pyatv...?

#51

Thanks for pointing this out. I had been on TVOS 26.4 and using pyatv 0.14,5 with no issues. Im also on apple TV 4k 2nd gen and it looks like 3rd gen may be worse?

I guess TVOS 26.5 made some key changes, and the pyatv developer may be patching. Here is the bug list:

#52

Maybe wait for the dust to settle on 0.17 pyatv? Lots of issues

Happy to spin up another container @bnhf and test. I dont have a 3rd gen ATV4K though, but can test with ATV 4K second gen. I have a spare and can upgrade it to TVOS 26.5 as a testbed.

#53

Looks like all necessary fixes are already merged into 0.17 master branch. Let's see if @bnhf can give us another appletv.test version to try

#54

As I said, we're using the pyatv container as a base (ghcr.io/postlund/pyatv:master). But, what I'll do now is build off the older pyatv container we've used before, and then upgrade it like you did.

Makes one wonder if there isn't something wrong with the way he's building his containers now...

#55

New bnhf/ah4c:appletv.test built, using the previous Dockerfile -- but with a pyatv update added (pip3 install --upgrade pyatv). Give it a try, and let me know.

#56

I used portainer to make a clone of my working system, disabled my existing system, tested the clone with normal pull to verify operation.

Then did a pull from the test branch and am seeing pyatv version 0.17 in the container as expected. So far this deployment worked fine and the tuner seems to be working with the 0.17 pyatv codebase. The was tested on Apple TV 4K 2nd generation, and TVOS 26.4

I still need to create a sandboxed environment on a different Apple TV 4K 2nd gen that I dont usually use as my tuner. I will update that box to TVOS 26.5 and do more testing to confirm all the fixes with pyatv 0.17 were rolled in.

#57

@bnhf So I was still getting event loop and Command FetchAttentionState failed errors on your latest build, tried pip3 install --upgrade pyatv again in exec console once more just in case... Turns out some pyatv files get left behind, so a full reinstall is needed. I first did

apk update
apk add git

and then

pip3 install --upgrade --force-reinstall git+https://github.com/postlund/pyatv.git

With this full reinstall of latest 0.17 master I have to say tuning is pretty much instant now, with no errors. If you can see how to include that on your appletv.test I'll give it a try. Thanks.

#58

The container wouldn't build that way, so I thought we'd shift gears. I was originally using the pyatv container as a convenience, and it somehow became anything but that.

I've re-grouped, and taken our normal Dockerfile and added pyatv and its dependencies. So now, we're building our standard container -- just with pyatv added and our alternate startup script. Hopefully this will get us on track, and take whatever is up with the pyatv container out of the equation...

#59

Just wanted to flag this. I now have a test bed with one Apple TV on tvOS 26.5 and one on tvOS 26.4 running my tuning code.

I’m seeing the same slowdown on tvOS 26.5 that @upino reported. I pulled from the appletv.test branch using Portainer.

Before updating to 26.5, tuning was very fast on both Apple TVs while they were on 26.4.

After updating my sandboxed Apple TV to 26.5, I’m seeing an additional 4–5 second delay that appears to line up with what looks like the FetchAttentionState timeout behavior on tvOS 26.5 / pyatv 0.17.0.

Happy to test any future build that includes the pyatv developer fixes.

I’m leaving my working tuner Apple TV on tvOS 26.4 for now.
Issue #2845 seems to match what I’m seeing: FetchAttentionState silently dropped on Apple TV 4K gen 3 (AppleTV14,1) with tvOS 26.5 — pyatv 0.17.0 does not fix .

And thanks again to @upino and others for pointing this out.

#60

Apologies, I was failing to understand the pyatv version 0.17.0 that's being installed by pip doesn't match the GitHub commits for version 0.17.0. Which is why we're needing to jump through these extra hoops. And, of course we'll need to adjust the Dockerfile again once this is sorted out.

Anyway, I've built another bnhf/ah4c.appletv.test that upgrades the pip pyatv 0.17.0 to the GitHub pyatv 0.17.0. Hopefully this will do the trick...

1 Like
#61

Oh cool. Ill test tomorrow!

edit: I couldnt resist before calling it for the day.
I re-deployed from appletv.test and the tuners are both fast now with no errors. Yay!

However, Im seeing this in the container console. Rev 0.16.1 ?? Is this the correct build and version that you intended?

root@tuner-test:/opt# python3 -m pip show pyatv
Name: pyatv
Version: 0.16.1
Summary: A client library for Apple TV and AirPlay devices
Home-page: 
Author: 
Author-email: Pierre Ståhl <[email protected]>
License: 
Location: /usr/local/lib/python3.11/dist-packages
Requires: aiohttp, chacha20poly1305-reuseable, cryptography, ifaddr, miniaudio, protobuf, pydantic, requests, srptools, tabulate, tinytag, zeroconf