I recently upgraded to the latest stable release, and it seems like my endpoints are broken. I have encountered this issue with previous updates, but it's been a while, and rolling back usually resolved the problem. Unfortunately, this time rolling back doesn’t seem to help. Is anyone else experiencing this issue?
The URLs you have configured in the Streaming Endpoint field actually redirect to another URL. You should be able to just update the Streaming Endpoint field with the URL suggested in the error message. In your case it seems it's redirecting the https?
Hi guys!
There are sooo many posts and replies about fixes, adjustments and new developments here that I bet this post gets lost in the shuffle.
I’m not one who can participate in such discussions, but I am a user of ADB Tuner for about a year or so. I only have a single encoder, fed by a single Fire TV.
I just want to say thank you. That’s all.
5 Likes
I attempted the suggested fix, and the URL changed to HTTPS as a result. The second tuner reflects the original message I received before trying the fix. I also double-checked my endpoint URLs on the encoder, and there have been no changes.
@turtletank I see "timed_keep_active_commands": [] in the latest development build you just pushed!
Do these just run in sequence? ie.
"input keyevent 126",
"sleep 3600"
If so I'll update my config.
LOL I literally just pushed that. It's just a quick implementation, and I will document this more, but your DTV config converted for this is as follows.
I don't have DTV, and haven't really tested other than verifying that the commands are executed.
{
"name": "DirecTV",
"author": "David B.",
"version": "X.X.X",
"description": "Fast tuning for DirecTV. Prevent are you still there prompt from showing.",
"uuid": "3c7d5a19-6f2e-4b8a-9d3f-8e1c4b7a5f92",
"global_options": {
"wait_for_video_playback_detection": true,
"use_fixed_delay": false,
"fixed_delay_seconds": 0,
"check_for_and_clear_whos_watching_prompts": false,
"wait_after_post_playback_start_commands_seconds": 0
},
"pre_tune_commands": [
],
"tune_commands": [
"am start -W -n '||TARGET_PACKAGE_NAME||'/$(cmd package resolve-activity -a android.intent.action.MAIN '||TARGET_PACKAGE_NAME||' | awk -F= '/name=/{print $2; exit}') -a android.intent.action.VIEW -d '||TARGET_URL_OR_IDENTIFIER||'"
],
"post_playback_start_commands": [
],
"post_tune_commands": [
"input keyevent KEYCODE_MEDIA_STOP",
"input keyevent KEYCODE_HOME"
],
"timed_keep_active_commands": [
{
"run_every_minutes": 60,
"commands": [
"input keyevent KEYCODE_MEDIA_PLAY"
]
}
]
}
1 Like
Thank you so much. I'll see in my adb logcat right away if it worked and again in an hour if it hit the play button again. But I already know for sure that this does work for DirecTV.
More information on this, I tried all iterations that error tells me to try and once I switch the URL I get a complete connection failure which would make sense. The endpoints the program is telling me to use are not real endpoints. Thanks
Just set the run_every_minutes to 2 to test and it does indeed work!!
What encoding device(s) are you using?
Edit: if it's a single LinkPi device, can you try:
http://192.168.2.11:8090/FS1 and http://192.168.2.11:8090/FS2
I have 4 LinkPi Devices. They are all doing the same thing after this last update.... weird thing I spun up a new container since the suggested fix was not working I thought maybe I broke something. Intially this new container was doing the same thing. But I tried to add the fix that you stated along with the ADB tuner program suggesting and now its working all of a sudden. Not sure why thing change was needed all of a sudden and why in my orginal container the fix would not take. But it seems to be all good now I will try it on the rest of my tuners and let you know if I have any more trouble
Thanks for an awesome program!
1 Like
There are some firmware updates that reset config. Possible your play URLs for the LinkPi streams changes. One of the firmware updates changed all my bitrate and encoding settings too. Something to check. Glad it is working.
Woo hoo made it! Thank you for implementing this @turtletank!
You rock!!!
Edit: Still going!
Finally ended it after 7 hours, this is awesome!
@turtletank I will start by start by saying the challenge I'm having is so unique, it may only apply to me. I don't want to request development for such a small audience. But with the newly created ADBT Thread dedicated to DirecTV, figured I would open discussion.
I've been testing my Osprey Boxes with ADBT for a few months. It works rather well, but I have to use a work around. It seems ADBT needs to verify the declared Package Name is installed before continuing with the rest of the tuning process. The Osprey does not have an installed app. Instead it uses the System App com.att.tv.openvideo baked into the Osprey Firmware.
I bypass this challenge by selecting a random installed app during my Channel setup, then use a custom config to manually target the "openvideo" system app. Is there any way to use a System App as Package Name? Possible to skip this verification of installed, and just trust the declared (manual input) package name is good?
Again, this is not a show stopper for me. The bypass I'm using now works. Appreciate all you do.
1 Like
Are you on the stable branch or the development version. I think it was address in the threads.
a configuration is available to address the boxes.
Can you take a look at the current development version (20251208-1) and let me know if this issue is resolved? In this build the full list of packages is used when allocating tuners instead of the filtered third-party list.
Gave it a quick test on the new dev version before work. Did not seem to take. I will pull a log and see what's happening. Thank you so much for attention to this config!
Okay, so I checked the logs. The dev version in fact does allow me to manually enter the system package by typing it in, and attempts to tune, but then errors out saying "Application is not installed".
2025-12-08 20:08:10.057 - stream - [Tune (3hR7ibUCQDsDwXMvn9rjMH)] No active tuners found for CNNHD. Reserving a new tuner.
2025-12-08 20:08:10.058 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Attempting to reserve tuner for: ['com.att.tv.openvideo'].
2025-12-08 20:08:10.059 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Available Tuners:
2025-12-08 20:08:10.059 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Name: Opsrey1 Priority:
2025-12-08 20:08:10.059 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Name: Osprey2 Priority:
2025-12-08 20:08:10.059 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Name: Osprey0 Priority:
2025-12-08 20:08:10.059 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Selecting random tuner
2025-12-08 20:08:10.060 - tuner_management - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Reserved Tuner: Name: Opsrey1 Priority:
2025-12-08 20:08:10.060 - stream - [Tune (3hR7ibUCQDsDwXMvn9rjMH)] Tuning to CNNHD on Opsrey1
2025-12-08 20:08:10.063 - stream - [Tune (3hR7ibUCQDsDwXMvn9rjMH)] Using channel configuration: DTV: Osprey Deep Link (DODL) (870d0f68-6c1f-4358-b3c3-0c97fd0cb316)
2025-12-08 20:08:10.444 - lib.adb - [Tune (3hR7ibUCQDsDwXMvn9rjMH)] ADB: 192.168.xxx.xxx - input keyevent KEYCODE_WAKEUP
2025-12-08 20:08:11.757 - tuner_management - [Tune (3hR7ibUCQDsDwXMvn9rjMH)] Released tuner (1).
2025-12-08 20:08:11.757 - stream - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Application (None) is not installed. Exiting.
2025-12-08 20:08:11.764 - stream - [Tune 3hR7ibUCQDsDwXMvn9rjMH] Tuner (Opsrey1) is no longer available.
Would you be willing to expose a new variable for use in Custom Configurations along the lines of ||TARGET_DEVICE||? When I was experimenting with your codebase during your "hiatus" 
from ADBTuner, I recall it was fairly trivial, since that value is already available as an internal variable.
Armed with ||TARGET_DEVICE||, and what you've added for obtaining a deeplink from a remote endpoint, I believe I could revive the ability for ADBTuner to be able to capture CDVR Virtual Channels streams (from the CDVR client app running on an encoder-connected streaming stick).
CDVR Virtual Channels are typically only viewable on CDVR clients. This would make them viewable in other media centers, via the WebUI, and in CDVR Multiview. The GET to the remote endpoint would be to a webhook that would execute the curl command required to do channel changes on a CDVR client (via its API) on the "target device".
The only thing that's different from the typical ADBTuner flow, is that CDVR app channel changes can only be triggered by curl.
Yeah, of course. Are you looking for the "Device IP Address" associated with the allocated tuner? Or something else?