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

Should that colon be there

TAG=development
DOMAIN=local
HOST_PORT=5592
HOST_VOLUME=adbtuner_config
KNOWN_STREAM_TIMEOUT_DEFAULT:=10

Sorry, yes that's an alternate syntax for yaml files, but OliveTin uses equal signs. So, to match the way we do it in Project One-Click, create an environment block in the yaml (between ports: and volumes: to stay consistent with other P1C yamls):

    environment:
      - KNOWN_STREAM_DEFAULT_TIMEOUT=${KNOWN_STREAM_DEFAULT_TIMEOUT}

And this to the env vars section:

KNOWN_STREAM_DEFAULT_TIMEOUT=10

Once I hear from a few more people that this is the solution, I'll modify Project One-Click to include a field for this variable from the start.

EDIT: Fixed incorrect env var name.

I think it might be accidentally flipped in a few posts in this thread, but it’s KNOWN_STREAM_DEFAULT_TIMEOUT.

This is how long a long a tuner stays locked and available to continuing watching after data stops streaming though the proxy for that channel.

The issue at hand here is that it seems that some players and DVRs temporarily stop streaming data for multiple streams when one is disconnected which releases the tuners related to those streams.

This will default to 8 seconds in the next version of ADBTuner. 5 seconds is probably ok in most situations, 10 might be a bit overkill, but if someone has enough tuners that the wait isn’t an issue it can’t hurt.

Every second counts around here lol so I was hesitant to increase that by default if it isn’t necessary for everyone.

1 Like

Thanks. I copied that from a previous post by someone else, so I'll adjust mine just above.

The current development build (20260423-1) adds support some new configuration command types.

"tune_commands": [
  "adbtuner_open_app '||TARGET_PACKAGE_NAME||'",
  {
      "ADB_LOOP": {
          "iterations": 10,
          "commands": [
              "input keyevent KEYCODE_DPAD_DOWN",
              "sleep 2"
          ]
      }
  }
]

"adbtuner_open_app '||TARGET_PACKAGE_NAME||'" does what you probably think it would do. It opens the target app.

When I added the keep alive feature I found that adb shell monkey -p didn't work for every app. So I added a helper function to ADBTuner that dumps the target package to figure out which action to use. This change makes this functionality available to configurations.

The ADB_LOOP command type provides a simple syntax for repeating a set of commands multiple times. I find this syntax is cleaner than sending a full shell command to the device for this purpose. More importantly, using this feature allows ADBTuner to intercept any sleep commands and process them on the ADBTuner side as that provides more accurate timing. It's also necessary to make adbtuner_open_app work in a loop if needed.

The example configuration above will open the target app and then press down 10 times (waiting 2 seconds between each key press).

I ran most of the day yesterday with KNOWN_STREAM_DEFAULT_TIMEOUT set to 10. Pressed my system harder than normal and did not experience any times where the stream closed unexpectedly and drop to the Firestick Home Screen. So, this appears promising.

Based on turtle tank's feedback I've dropped the timeout from 10 to 5 for today and will test further.

I appreciate you taking the time to test this out. Thanks.

Open Box Onn 4K, $38, few back in stock if anyone needs one. 13 available at time of this post.

Edit: showing 106 now in stock.

Made those changes and so far it's good. I'll know more tonight as I’ve set a couple of things to record. If those games record all. I'll probably leave it at 10 secs for today and tomorrow then drop to 8 secs for the weekend games. Tuner availability isn’t really an issue at this point.

1 Like

The awesomeness of ws-scrcpy is now available for ADBTuner -- in the form of a companion container. More here:

1 Like

That is possibly the best feature of ah4c so thank you so much for implementing this. That is really cool.

No issues so far with using a value of 5.

I pushed an update to the development version (20260425-1) this morning. It's mostly just some cleanup and refactoring.

Notable changes:

  1. Configurations that use fixed delays now work correctly when MPEG_NULL_PACKETS is enabled.
  2. Configurations are now cached to improve performance when users have many configurations.
  3. Imported configurations are no longer displayed under User Configurations at /configurations.
  4. Removed support for the legacy configuration option check_for_and_clear_whos_watching_prompts. This is now defined via tune_match_text_commands.

Please let me know if you run into any issues.

2 Likes

Hi all. I have this set up and works great when I click the PREVIEW link inside of ADBTuner on a channel. I have it set up with YTTV. However, when I insert the M3U url into Channels DVR, I always get this error.

Does anyone have any idea why this happens and how to fix? I have read it happens when there are too many channels, but I literally have 3 as I am still testing it out.

HELP! (please!)

1 Like

Are you using the URL as shown in the ADBTuner WebUI? For example, here's mine (note the .m3u8):

I tried both .m3u and .m3u8

Are you running Channels and ADBT as containers? Sometimes the default bridge network doesn’t allow containers to talk to each other.

Channels DVR is running natively on a Windows PC and ADBTuner is in a container on a Synology NAS. Would that still cause this issue?

On your Win PC, make sure your PC & Synology can see & communicate with each other.

In that case you should be fine. Since Windows is your Channels host, and I assume you were browsing the ADBT web interface, the Synology ADBT container is accessible to the network.

But to test, on your Windows Channel Host, open a browser and navigate to your M3U8 link:

If it's working, it should download a file. If it does download, ADBT of hosting correctly and Channels should be able to see the link. If it does not, there is more to troubleshoot, starting with the Windows firewall.