@uspino This was my first thought as well. If you're binding a different location for persistent data, you'll need to re-pair.
The new PLAYBACK_STATIC_TIMEOUT seems to be working quite well for the DTV app. The first two tunes I've tried, one on the WebUI and the other on an Android tablet, worked perfectly. No FireStick or DTV home screens visible -- tuning went directly to the stream.
I loaded your latest example YML and ENV with beta4 . The build path seems stable with the new yml and env and Im testing the added drop down options now on the parakeet model.
One thing we may want to clean up in the merged YML and env that's a bit confusing.
Should we specify a persistant data directory for the PYATV stuff?
Right now at least on my machine, its all stored in /root/.pyatv.conf and just like what happened to @uspino , rebuilding or updating with a fresh pull can blow that paring away if not careful.
The whole process of paring is also right now a manual process that looks something like this:
To add and pair a new Apple TV:
From within running container.1: Look at the config file that has credentials if new container this might have 0 bytes initially
cat /root/.android/.pyatv.conf2: Then go through the pairing process:
atvremote -s 192.168.1.xx --storage-filename /root/.android/.pyatv.conf --protocol companion pair
atvremote -s 192.168.1.xx --storage-filename /root/.android/.pyatv.conf --protocol airplay pairatvremote -s 192.168.1.yy --storage-filename /root/.android/.pyatv.conf --protocol companion pair
atvremote -s 192.168.1.yy --storage-filename /root/.android/.pyatv.conf --protocol airplay pair3: Then look at the config file that has credentials and verify changes:
cat /root/.android/.pyatv.conf4: to be safe stop and start container to verify persistent credentials
Ive always wanted a more user friendly for newbies way of doing this. Frankly - after 6 months goes by it is easy to forget this sequence and to forget about the credentials and its happened to me more than once.
Would it make sense to add this process to either olivetin, or preferably the new merged UI based on the PYATV=true flag ?
I know we are not focusing on the UI issues now and dont want to distract you or @mackid1993 from the main train of thought.
Im happy to lend a hand in coding this with some guidance from you and uncle Claude. It would be some PYATV=true code dependancies I guess, but it would be really useful and make the whole thing more mainstream for everyone,
@mackid1993 Ive tested with the latest changes, Ive only looked at parakeet unified while watching Sharknado this morning
Im still using the defaults and tried the new dropdown for realtime vs sentence at a time.
Im actually seeing more latency with the real time model. So for now Im just using the sentence at a time.
I haven't tried this with the other models yet.
You mean /root/.android/.pyatv.conf in the container, yes?
Since we're binding to /root/.android how would the pairing get blown away? The file should be safe on your host system in $HOST_DIR/ah4c/adb
Totally agree.
I'm still hitting the errors
2026/08/20 11:46:46 [EXECUTE] Stdout: '2026-08-20 11:46:46 ERROR [pyatv.scripts.atvremote]: Command 'launch_app' is not supported by device
etc., AH4C kept the pairing intact after upgrade (checked /root/.android/.pyatv.conf) so not sure where this is coming from.
1 Like
We tried to automate this early-on, but my recollection is that's it's an interactive pairing -- with a requirement to enter a code off the TV or the like?
This might actually be possible now in OliveTin, as I seem to recall I can do interactive scripts now -- though I haven't had the need yet.
My bad: all works after re-pairing ATV. /root/.android/.pyatv.conf was populated but clearly invalid. Sorry.
Do you happen to have an invalid version of that .conf that you can post? It's probably best not to post a current one. Is the version of pyatv in this unified version, the same as before?
Just deleted it, I can restore a backup and take a look if you need it
I'm curious what's in there, and what might cause it to become invalid. There might be nothing of value, or it might have the answer -- impossible to know without seeing it. If restoring from backup is a hassle, don't bother -- we'll look at it another time. You could also ask the pyatv people about it.
2 Likes
Yea its interactive
So, real time is going to be a little bit more hardware intensive, so it might actually have the opposite effect.
I'm really glad to hear that.
Yes, I just confirmed thats the persistant directory, but It may be confusing because it is shared by both android and PYATV. When you do the build, the adb credentials get filled in (which you can see in the Mac finder). The pyatv.conf gets filled in as well, but because of the leading period ( .pyatv.conf) , the Mac finder treats it as a hidden file.
At the very least how bout we change the description of the YML line something like this to avoid confusion?
- ${HOST_DIR}/adb:/root/.android # Persistent data directory for adb keys and ATV pairing info which is in the file .pyatv.conf (on Mac finder this is hidden. be careful)
Based on PYATV=true, do we even need to populate the adb keys there? Are those for pairing and control of the fire sticks?
That's why I was suggesting a possible separate persistant directory. Im happy either way, but Im know enough from experience to very careful with this, Ive accidentally wiped out that whole adb directory during development because the pyatv.conf appears to be hidden in finder.
Yes, as you get older like us, you will realize the universal truth of what you just said. 
They're the stored keys for being able to use ADB USB Debugging (a Developer Mode option) on FireSticks and other Android devices. But they are not populated by ah4c when in pyatv mode. Maybe they are there from some previous work you did using Android devices.
ah4c populates the m3u, scripts and now the captions directories -- but not the adb directory. Anything in there I'm fairly sure was generated by you at some point. To prove this, delete them and then stop and start the container's stack. They should not return. If they do, that's something I'd want to investigate.
If they do, it's probably my trash vibe code. /jk
Yes - Ive got another working ah4c based tuner stack that uses adb commands for my ONN box . Im planing on testing all the closed caption and other updated changes with PYATV=false in that different container - which it has a different persistent directory path on my host.
I figured there were more people using the android boxes for testing at the moment, so I haven't got around to updating my other ONN based tuner container yet.