You can override that by setting the KNOWN_STREAM_DEFAULT_TIMEOUT environment variable.
1 Like
I just pushed a new development build (20250808-1) that adds a new post_playback_start_commands parameter to configurations.
It probably needs some more testing, but I used what you had previously posted and it seemed to work.
"post_playback_start_commands": [
"input keyevent KEYCODE_DPAD_CENTER",
"sleep 0.2",
"input keyevent KEYCODE_DPAD_UP",
"sleep 0.2",
"input keyevent KEYCODE_DPAD_CENTER",
"sleep 0.2",
"input keyevent KEYCODE_BACK",
"sleep 0.2",
"input keyevent KEYCODE_DPAD_CENTER"
],
2 Likes
I'm going to try this right now, and will test across all my devices this weekend. Excellent stuff, thank you!
So far my testing has been very positive. The delayed KeyInput timed right after the video starts is more reliable, and faster. I don't care so much about fast tuning as I don't watch too much live TV, but I have noticed the increased speed is less likely to make the Channel's Tuner to drop.
I will test more this weekend. The Onn 4K Plus is so much quicker and reliable than the standard Onn 4K, I may go grab a few more Plus models this weekend.
Thanks for the fantastic work!
I don’t know if i do it right but tested with 1 and 1000 and it’s still take about 3 seconds to close the stream
Wanted to share the results of my testing tonight. My goal has been reliable tuning on NBC App Channels, working around the Dim Video Challenge.
When Configurations were added to ADBT, I thought I may be able to emulate keypad events enough to clear up the video. Where I got the keyinput series to work, bringing up live guide then existing to restore normal screen brightness, I could never get the timing dialed in. The video buffer has to finish before you can bring up the guide and input keys, and the time to buffer depends on network conditions, streaming box performance and NBC availability. It was all within a few seconds, but too hard to standardize.
Yesterday, TurtleTank added a new option to the configuration: post_playback_start_commands. This allows the keyinput to happen after the video starts, regardless of how long the buffer takes. Big difference!
Here is my test setup:
- (2) Onn 4K, (1) Onn 4K Plus, both on Wireless, both Android 14
- ADBTuner Dev Build 20250808-1
- Newest NBC App from Google Play
- Custom Config (provided below).
Here is my test Config for the NBC App:
"global_options": {
"wait_for_video_playback_detection": true,
"use_fixed_delay": false,
"fixed_delay_seconds": 0,
"check_for_and_clear_whos_watching_prompts": false
},
"pre_tune_commands": [
"input keyevent 3"
],
"tune_commands": [
"am start -W -a android.intent.action.VIEW -d '||TARGET_URL_OR_IDENTIFIER||' '||TARGET_PACKAGE_NAME||'"
],
"post_playback_start_commands": [
"input keyevent KEYCODE_DPAD_UP",
"sleep 0.1",
"input keyevent KEYCODE_DPAD_UP",
"sleep 0.1",
"input keyevent KEYCODE_DPAD_CENTER",
"sleep 0.5",
"input keyevent KEYCODE_DPAD_CENTER"
],
"post_tune_commands": [
"input keyevent KEYCODE_POWER"
]
Result:
NBC App Starts, video buffer takes as long as it needs, then the Key Input above kicks in. Video is normal brightness.
On my Onn 4K Plus, I didn't have to do much. It's so much more responsive than the Onn 4K boxes, it just worked.
For the two standard Onn 4K boxes, I found I had to leave the NBC App open all the time. If you decide to close the NBC App in Post Tune Commands, like the standard Compatibility Mode does, the tuning will work in ADBT Preview, but not in Channels. Too slow, makes Channels time out on tune.
I've been playing with the setup for a few hours, trying to test all scenarios. Allowing devices to sleep worked fine. Turning all three at the same time did not cause a challenge.
The only issue I can see, so far, is if the NBC Apps closes or crashes, or there is a reboot, one of the older Onn 4K boxes may not tune until NBC App is open and resident again. Using Keep Device Awake option to re-open the NBC App works, but it just streams constant video. I'm so pleased by the Onn 4K Plus boxes I think I'm just going to buy a few more.
I will continue testing. Please share your results and we'll compare notes.
I pushed an update (20250810-2) to the development version this morning.
In this build I am trying out something new with tuner allocation. ADBTuner now maintains a list of installed apps for each of the connected Android devices and uses this to make decisions while allocating tuners.
This will help avoid tuning failures if an app is not installed on one of the connected devices, but I think the real benefit of this is that it could allow for some creative configurations in which specific devices are dedicated to specific apps. If an app is only installed on one device then that device will always be used (if available), otherwise the normal priority rules apply.
Note: The inventory of installed apps is updated when ADBTuner is restarted, tuners are edited in the admin interface, and as part of an hourly maintenance process. It would be nice to get an updated list before each tuning operation, but I didn't want to add any more delays there.
Please let me know if you run into any issues. Thanks!
3 Likes
Did you restart the container after making that change? That parameter is only loaded at startup.
Just a heads-up, there really isn't much range to play around with on this. ADBTuner checks the status of active streams every second, however the execution time of each check needs to be accommodated for. In my testing so far, we are looking at ~1.2 seconds between each status check, but this may vary for each environment. Setting this parameter lower than that will result in tuners being released that should still be locked. I probably wouldn't go below 2 seconds, I think 3 seconds is safer. On the high end, any tuner that sits idle for 40 seconds will be released.
There may be room for some small optimizations in the future, but for now I would like to make sure everything is stable before going down that road. Please share your experience with this though, any data you can provide will be helpful.
ok will test again, is the correct value "1" in seconds or 1000 in ms?.
Thanks again for your work. Adb tuner has never been better 
It’s in seconds. 3 is the default value. It’s currently limited to integers so no floats/decimals. I can change that if needed.
This is another great addition and one that has a practical use for me. I just replaced both my Onn 4K boxes with Plus models. Having the same hardware performances across the stack makes automation reliable. I was just thinking yesterday what a shame it was to retire the regular 4Ks as they work fine for other apps, but are less predictable if they get called for the NBC app. Now they can stay in rotation with just the apps that work!
1 Like
In my short test 1 did not work, but 2 seems fine so far 
1 Like
Got a chance to test today the new update. Isolated a single app to a set of Onn 4K boxes. Only that App tuned. I will keep you all posted.
Has anyone ever attempted to use ADBTuner with the Astound IPTV app? Just curious. The app seems to be built on the TiVo foundation if that makes a difference.
Why would you use ADBTuner for this app when you can just directly insert the streams into channels.
jjThe only reason we even use the boxes would be to strip DRM.
If DRM isn't be stripped, no reason to use. The use of Channels with a proper m3u manager will always do better.
I think Astound is a traditional cable provider. Used to be called RCN?
I'm not aware of anyone trying to figure out if their app supports deep links or can be automated in any way.
I'm new to this so maybe I'm being obtuse here, but as far as I know the Astound app doesn't use M3U playlists so how are you suggesting the streams be inserted into Channels?
If your service uses a domain with user password and domain, it could probably work if you have a tool like m3u-editor
Stream Link manager acts like the bridge between all my options including the dockers and ADB Tuner.
Have you tried creating Astound as a TVE source with your username and password credentials? I think that might be what he's getting at, not sure.
I have Hotwire which is an IPTV provider that has all the popular channels, and I can get most of them via TVE. The locals I have to get in a variety of different ways like with the NBC app, they're not available directly.
Their apps also use TiVo software as a base.
I have been using the FHD version of the Chromecast with Google TV (2 of them actually) for quite a while now (feels like well over a year for sure) with no issues. Just last weekend, they stopped responding to ADB over the network. no idea why. I had this set up in my office, so I brought them home and set up a VM to run channels and ADBTuner. Same issue, so started using a spare FireTV 4k stick and an older Nvidia Shield, which both worked, sorta.
After some time, usually hours, when I try to open a stream, it times out. When I use VLC to check the encoder, it is playing YouTube TV, which is a problem because I don't want to waste my limited bandwidth at home.
Is there anything I can do to troubleshoot this? Once I shut down YouTube TV, then everything starts working normally again until it sets for a while again.