ADBTuner: A "channel tuning" application for networked Google TV / Android TV devices

Interesting idea. In the past, @turtletank has expressed reluctance to add full scripting to ADBTuner. Although, as one looks at the evolution of ADBTuner over the last three years, it's come closer and closer to ah4c in terms of power-user features.

I'm one of the developers of ah4c, but I use both ah4c and ADBTuner, as they've been fairly well differentiated in terms of which is better suited for various tasks. Though I'd be happy to see ADBTuner expanded to include scripting and arbitrary ADB commands, and would no doubt use any expanded feature set, I find myself wondering about the future of ah4c in such a scenario.

I have total confidence and trust in @turtletank, but at the same time, I'm an open source guy at heart. Even though Channels itself is not open source, the developers have done an excellent job of providing hooks for community projects. With very few exceptions, those community projects have been open source, with each of us having the option to review and/or expand the project.

ADBTuner has been an exception, and is not open source. I know many of us have wished this were not the case, but every developer has the 100% right to decide for themselves whether they want their project to be in the public domain (though subject to licensing) or not.

There have been requests in the past for ADBTuner to become open source, and I'd like to renew that request -- especially in light of the idea of ADBTuner adding full scripting. If that happens, and I hope it does :slight_smile:, it seems like that would be an appropriate moment to deprecate ah4c. Probably the only reason to continue maintaining it at that point would be to have an open source alternative to ADBTuner.

3 Likes

I love ADBTuner so much. I think it's such a great piece of software. I think it's so carefully and thoughtfully designed.

I really think it's probably the best tool for tuning deep links on Android. I generally stick to ah4c because I prefer open source. This is not out of like some personal moral conviction or something like that. This is simply because I can actually contribute to a project and give back to the community, which with ADB Tuner, I am completely locked out unless I want to violate a license. It's really, again, as I say, for the love of the game and nothing more, I want to build things around the community projects here, even though I don't really have one of my own except for my little Docker container for Unraid.

So ultimately, it's up to @turtletank what he wants to do, but I again would like to renew and agree with @bnhf that open sourcing ADBTuner should be considered. Even if it was like a Polyform strict license or something where it couldn't be redistributed or anything like that, but the community could see the source code and help implement features and have them considered. Obviously, Channels is a commercial product, but the things around it aren't. And I think ADBTuner is the odd duck out that's closed source in a sea of open source.

I also want to add I know in the past people were a little rude to @turtletank about implementing features when it was briefly open source. I think if that were to happen again, those of us in the community that are actually supportive would be more than happy to put a stop to that and make sure those people are properly put in their place where they belong.

2 Likes

Please don't do that. I would start ah4c-ng LOL.

I know ADB Tuner is better in some ways, but there are certain things that I like about ah4c that I would want to maintain myself. It does work a little bit better with the Ospreys also. It tunes a little bit quicker.

Oh, not to mention managing things through environment variables is really nice.

1 Like

Even if ADBTuner didn't go open source, but at least provided the ability to call external scripts or nest native ADB commands within the config files would be super powerful.

Within ADBTuner there's already a concept for publicly hosted config files... though I've not found any repository. I like that idea immensely where given a piece of hardware (i.e. Firestick) and provider (i.e. Spectrum) a library of scripts for tuning would be shared. With the expansion of direct ADB commands and/or scripting, the flexibility and capability of what the user community could post would be immense.

I find the utility of AH4C and the polished front end of ADBTuner to be a great combination for managing external apps and tuners. I appreciate both and would love to see the best of each merged...thus the suggestion.

Ouch! :face_with_head_bandage:

1 Like

I pushed a new :development build today (20260903-1). It adds a new tuner feature that attempts to automatically enable ADB on connected devices by using remote commands and OCR. The purpose of this feature is to add back some support for the ~3 Google branded devices that reset ADB settings on every reboot.

This is a pretty slow process, it sometimes fails a couple of times because the device might be sluggish after booting up, but it will retry until it gets it right. Expect the device to be back online 2-3 minutes after a reboot. I still recommend using devices that don't have this issue and not rebooting unless necessary, but at least it can recover now.

On a side note, I went through all of the steps to make it possible to just use Wireless Debugging instead of switching the device back to adb over tcpip thinking it would help hedge against future restrictions, but bailed on the idea because the entire wireless debugging stack resets on every Wifi disconnect (such as those caused by routers doing band steering and such). It's just going to be too fragile.

As for additional power user features and an open source release, I have some things in progress, I just need some more time to cook!

5 Likes

Have you tried this project?

Thank you for considering an open source release.

Using the latest build with this feature and my Google Chromecast HD (Android 14) is back online with ADBTuner. I was guilty of trying to intervene with remote keypresses until I realized the recovery was still ongoing. Once I stopped trying to "fix it" and just observed the process, things worked as designed.
Thanks for your continued work on this project!!

@babsonnexus, Okay, I'm a dork...sorry for missing that and thanks for pointing it out. I've read through the HDMI Encoder apps wiki, but it never specifically indicated the library path to use for the import... so it didn't register that it was the same GIT repository. I put in the repository path //github.com/babsonnexus/hdmi-encoder-native-apps and it worked/imported.

Aren't the various configurations dependent upon the specific app (i.e. Spectrum) and the platform on which they run (i.e. Firestick)? If so, don't the configuration need to be specific for each environment. I guess I'm trying to get my head around how these station specific apps actually work with varying apps and hardware... how does that work?

Also, after a little more attention I noticed the looping function, which is helpful, but is there also a function that could step character by character through a field value (channel number) and send the ADB mapped keypad digits. For example on my ADBTuner config file, I send 3 values that create the channel selection for Spectrum. Can that be made generic so that the identifier field or other could be used and the same config file could apply to all Spectrum channels? This was actually the root of my request for ADB commands and/or scripting.

Thanks for the response and guidance.

If you don't already have OliveTin-for-Channels installed, you may want to install it, as there's a Project One-Click Action that takes care of everything for you related to setting up HDMI Encoder Native Apps virtual channels for a given streaming stick app. There's also an option to add ALL supported channels in one shot.

The Action adds the virtual channels to ADBTuner, configured to support both generic Android and FireOS devices. It also adds the appropriate Custom Channels Source to your Channels DVR. In addition, it supports a remove function, that can be used as a straight remove -- or if updating, it'll remove previous virtual channels for a given app before adding the updated set of channels.

The above is actually pretty trivial in ah4c, and has been done for several providers. For example here's the core tuning script (bmitune.sh) for scripts/allente/livetv:

#!/bin/bash
#bmitune.sh for allente/livetv
#2024.03.22

#Debug on if uncommented
set -x

#Global
channelID="$1"
streamerIP="$2"
adbTarget="adb -s $streamerIP"

#Trap end of script run
finish() {
  echo "bmitune.sh is exiting for $streamerIP with exit code $?"
}

trap finish EXIT

#Tuning is based on channel number values from allente.m3u
tuneChannel() {
  for (( digit=0; digit<${#channelID}; digit++ )); do
    keypress=${channelID:$digit:1}
    $adbTarget shell input keyevent KEYCODE_$keypress
  done
}

main() {
  tuneChannel
}

main

And the companion m3u, that provides the tuning values (which in this case are channel numbers):

#EXTM3U

#EXTINF:-1 channel-id="1" tvc-guide-stationid="",SVT1
http://{{ .IPADDRESS }}/play/tuner/1

#EXTINF:-1 channel-id="10" tvc-guide-stationid="",Tv10
http://{{ .IPADDRESS }}/play/tuner/10

While ADBTuner has a great WebUI to interact with, ah4c is simple and powerful -- using a couple of dozen env vars to configure it, and three scripts per provider to drive tuning.

At least at this point in time, ah4c is the correct tool for what you're trying to do. That may change in the future, but if you're looking for the best current solution for what you're describing, it's readily available.

1 Like

To be very clear, there isn't a Spectrum or any other Cable/Satellite/OTT provider setup in this solution; they would require their own repositories, or at the very least station list. Assuming it would just be one configuration with that special station list, something like with DirecTV and Sling.

image

I'm not adverse to building one, but there's not a good way (yet) to use the field in that way. I could do it in Roku Bridge right now since that uses basic Python for Plugins, but not in ADBTuner. @turtletank, I guess, then, the request is for the ability to use the URL or Identifier field with a function that would parse it into individual keypresses and pass them on. Just something to keep in mind as you're cooking!

I always try to make it so you don't have to repeat this info again and again!

1 Like

@bnhf, All great tips... appreciate the guidance. The AH4C scripting is definitely a strong advantage/benefit to using that application. Thanks.

@babsonnexus, Appreciate pointing out the sections you'd already posted, sorry for missing those, it just wasn't clicking when I read through it. The request to add @turtletank is accurate... adding scripting or external script calls would allow external ADB commands to be designed, but including basic functions into the config files could handle most of the need too. Hopefully @turtletank will consider these ideas with the future builds. Thanks for the tips on using OliveTin and trying to make Channels setups smooth.

I pushed a new :development build this morning (20260808-1).

It adds two new features to custom channel configurations, conditional operations, and number input sequences. They are both represented in this example:

{
    "ADB_NUMBER_INPUT_SEQUENCE": {
        "number": "||TARGET_URL_OR_IDENTIFIER||",
        "input_delay_seconds": 0.25
    },
    "condition": {
        "check": "||TARGET_URL_OR_IDENTIFIER||",
        "cast": "number",
        "greater_than": "100"
    }
}

ADB_NUMBER_INPUT_SEQUENCE would generally be used with a channel number. This command will input each digit, in sequence, with the specified delay between each input.

Conditional operations, the condition block above, provide the ability to execute, or skip, a specific command based on the specified conditions.

Conditions can be applied to any command:

{
    "ADB": {"command": "input keyevent KEYCODE_DPAD_CENTER"},
    "condition": {
        "check": "||TARGET_URL_OR_IDENTIFIER||",
        "cast": "string",
        "equals": "banana",
        "not_equals": "cookie"
    }
}

The available operators are: equals, not_equals, greater_than, less_than, at_least, and at_most.

There is a small amount of documentation for this at /ui/configurations/documentation in the web interface.

I'm still working on some bigger things, but I took some time to add these features to address some limitations that configuration authors were running into. Please let me know if you run into any issues.

2 Likes

So there's some buggy native apps out there that will occasionally crap out video early on for whatever reason (I'm looking at you, NBC).

Am I right to assume that this is not the right project to have something that monitors video playback when running and restarts the app if it dies? I have my own custom monitor script that runs every so often when a recording is going on, but I'm looking to simplify.

@turtletank I sent you a PM with a bug I’m running into when using ADBTuner with channels dvr built in USB HDMI Capture method. Hopefully if you have time you can take a look at it. Thanks.

Thanks for this Xfinity custom configuration! Worked perfectly for me in my Xfinity on FireStick setup.

Would it be possible to add commands[] to this like with ADB_LOOP? After much trial and error, I was forced to do this to get two actions to run:

        {
            "ADB": {
                "command": "input keyevent KEYCODE_DPAD_DOWN"
            },
            "condition": {
                "check": "||TARGET_URL_OR_IDENTIFIER||",
                "cast": "string",
                "equals": "3"
            }
        },
        {
            "ADB": {
                "command": "sleep 1"
            },
            "condition": {
                "check": "||TARGET_URL_OR_IDENTIFIER||",
                "cast": "string",
                "equals": "3"
            }
        },