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

Playground
,
#3501

I wonder if it could be related to using a different activity (com.xfinity.common.view.LaunchActivity)?

Here's a full tuning cycle debug from ah4c:

[EXECUTE] Stdout: 'Current PID for this script is 7182

Not a special channel (exit nor reboot)

Starting: Intent { act=android.intent.action.VIEW dat=https://www.xfinity.com/... cmp=com.xfinity.cloudtvr.tenfoot/com.xfinity.common.view.LaunchActivity }

bmitune.sh is exiting for 192.168.1.201:5555 with exit code 0

'

[EXECUTE] Stderr: '+ dvr=utheater-pc:8089

+ channelNameID=HCHD-7889068523651137105

++ echo HCHD-7889068523651137105

++ awk -F- '{print $2}'

+ channelID=7889068523651137105

++ echo HCHD-7889068523651137105

++ awk -F- '{print $1}'

+ channelName=HCHD

+ specialID=HCHD

+ streamerIP=192.168.1.201:5555

+ streamerNoPort=192.168.1.201

+ adbTarget='adb -s 192.168.1.201:5555'

+ packageName=com.xfinity.cloudtvr.tenfoot

+ packageAction=com.xfinity.common.view.LaunchActivity

+ m3uName=xfinity.m3u

++ grep -B1 /play/tuner/HCHD-7889068523651137105 /opt/m3u/xfinity.m3u

++ awk -F 'channel-id="' 'NF>1 {split($2, a, "\""); print a[1]}'

+ m3uChannelID=1458

++ curl -s http://utheater-pc:8089/api/v1/channels

++ jq -r '.[] | select(.id == "1458") | .number'

+ channelNumber=1458

+ [[ false == '' ]]

+ speedMode=false

+ read -a autoCropChannels

+ trap finish EXIT

+ main

+ updateReferenceFiles

+ mkdir -p 192.168.1.201

+ [[ -f 192.168.1.201/stream_stopped ]]

+ [[ -f 192.168.1.201/last_channel ]]

+ echo 7182

+ echo 'Current PID for this script is 7182'

+ matchEncoderURL

+ case "$streamerIP" in

+ encoderURL=http://192.168.1.52:8090/stream2

+ encoderStreamNumber=stream2

+ encoderIP=192.168.1.52:8090/stream2

+ encoderIP=192.168.1.52

+ specialChannels

+ '[' HCHD = exit ']'

+ '[' HCHD = reboot ']'

+ [[ -f 192.168.1.201/adbCommunicationFail ]]

+ echo 'Not a special channel (exit nor reboot)'

+ tuneChannel

+ adb -s 192.168.1.201:5555 shell am start -n com.xfinity.cloudtvr.tenfoot/com.xfinity.common.view.LaunchActivity https://www.xfinity.com/stream/live/HCHD/7889068523651137105/HCHD

+ echo -e '#!/bin/bash\n\nwhile true; do sleep 4h; adb -s 192.168.1.201:5555 shell input keyevent KEYCODE_DPAD_DOWN; done'

+ chmod +x ./192.168.1.201/keep_watching.sh

+ [[ -n 4h ]]

+ nohup ./192.168.1.201/keep_watching.sh

+ printf '%s\n' 1810 1812 1841 1842 1846 1848 1852 1862

+ grep -qx 1458

+ :

+ finish

+ echo 'bmitune.sh is exiting for 192.168.1.201:5555 with exit code 0'

Terminated

'

[EXECUTE] Finished running ./scripts/firetv/xfinity/bmitune.sh in 14m24.250505231s

[EXECUTE] Stdout: 'Streaming stopped for 192.168.1.201:5555

Sleep initiated for 192.168.1.201:5555

192.168.1.201/stream_stopped written with epoch stop time

'

[EXECUTE] Stderr: '+ dvr=utheater-pc:8089

+ streamerIP=192.168.1.201:5555

+ streamerNoPort=192.168.1.201

+ channelNameID=HCHD-7889068523651137105

+ adbTarget='adb -s 192.168.1.201:5555'

+ packageName=com.xfinity.cloudtvr.tenfoot

+ m3uName=xfinity.m3u

++ grep -B1 /play/tuner/HCHD-7889068523651137105 /opt/m3u/xfinity.m3u

++ awk -F 'channel-id="' 'NF>1 {split($2, a, "\""); print a[1]}'

+ m3uChannelID=1458

++ curl -s http://utheater-pc:8089/api/v1/channels

++ jq -r '.[] | select(.id == "1458") | .number'

+ channelNumber=1458

+ [[ false == '' ]]

+ speedMode=false

+ read -a autoCropChannels

+ printf '%s\n' 1810 1812 1841 1842 1846 1848 1852 1862

+ grep -qx 1458

+ main

+ [[ -n croppedChannel ]]

+ matchEncoderURL

+ case "$streamerIP" in

+ encoderURL=http://192.168.1.52:8090/stream2

+ encoderStreamNumber=stream2

+ encoderIP=192.168.1.52:8090/stream2

+ encoderIP=192.168.1.52

+ bmituneDone

+ bmitunePID=7182

++ pgrep -f 192.168.1.201/keep_watching.sh

+ keepWatchingPID=7202

++ pgrep -P 7202

+ keepWatchingCPID=7204

+ [[ -n '' ]]


+ ps -p 7182

+ [[ -n 4h ]]

+ kill 7202 7204

+ rm ./192.168.1.201/keep_watching.sh

+ [[ -n '' ]]

+ rm ./192.168.1.52/stream2.sh

rm: cannot remove './192.168.1.52/stream2.sh': No such file or directory



p

+ [[ false == \t\r\u\e ]]

+ stop='am force-stop com.xfinity.cloudtvr.tenfoot'

+ adb -s 192.168.1.201:5555 shell am force-stop com.xfinity.cloudtvr.tenfoot



2

+ echo 'Streaming stopped for 192.168.1.201:5555'

+ adbSleep

+ sleep='input keyevent KEYCODE_SLEEP'

+ adb -s 192.168.1.201:5555 shell input keyevent KEYCODE_SLEEP

+ echo 'Sleep initiated for 192.168.1.201:5555'

+ date +%s

+ echo '192.168.1.201/stream_stopped written with epoch stop time'

'

[EXECUTE] Finished running ./scripts/firetv/xfinity/stopbmitune.sh in 3.933105448s

[GIN-debug] Request: 100.xxx.xxx.xxx GET /play/tuner/HCHD-7889068523651137105, latency: 14m30.59648036s, status: 200
#3502

Thanks. This is helpful. Explicitly specifying the activity opens the app normally in the current version.
am start -n com.xfinity.cloudtvr.tenfoot/com.xfinity.common.view.LaunchActivity

A custom configuration that does this should solve the issue, but I'm going to see if I can't figure out how to avoid doing that.

#3503

Thank you both again for spending time on this.

An added datapoint is that I did have 2 of my firesticks displaying a failed update screen earlier in the week - probably around the time this all started. Guess I need to turn off auto updates.

Once I get back in front of my server I'll try the older version and see what version they're running.

#3504

Ok, so for all intents (no pun intended) and purposes, they disabled deep links in 8.15+. They straight up removed everything related to them from AndroidManifest.xml.

Screenshot 2026-06-28 at 7.03.37 PM
Screenshot 2026-06-28 at 7.03.37 PM1920×1751 193 KB

Specifying the activity still works because presumably they didn't remove the rest of the deep link processing code from the app.

A custom ADBTuner configuration is going to be the best workaround. Something like this:

{
    "name": "Deep Links Compatibility Mode - Xfinity New",
    "author": "",
    "version": "0",
    "description": "Load content via deep link URLs with workaround for newer app versions.",
    "uuid": "7c9e4faf-0f4e-43ae-aee7-b2653bf02149",
    "global_options": {
        "use_fixed_delay": false,
        "fixed_delay_seconds": 0,
        "wait_after_post_playback_start_commands_seconds": 0
    },
    "pre_tune_commands": [
        "input keyevent KEYCODE_MEDIA_STOP",
        "am force-stop '||TARGET_PACKAGE_NAME||'",
        "sleep 2"
    ],
    "tune_commands": [
        "am start -W -a android.intent.action.VIEW -d '||TARGET_URL_OR_IDENTIFIER||' '||TARGET_PACKAGE_NAME||/com.xfinity.common.view.LaunchActivity'"
    ],
    "tune_match_text_commands": [
        {
            "match_text": [
                "who's watching",
                "choose an account",
                "edit profiles"
            ],
            "commands": [
                "input keyevent KEYCODE_DPAD_CENTER"
            ],
            "start_checking_after_seconds": 5
        }
    ],
    "post_playback_start_commands": [],
    "post_tune_commands": [
        "am force-stop '||TARGET_PACKAGE_NAME||'",
        "input keyevent KEYCODE_HOME"
    ],
    "timed_keep_active_commands": []
}
#3505

Thank you.

Is there already a config file I can edit, like here:
volumes: - /mnt/disk/adbtuner:/app/.config
of should it be a new file somewhere else?
docker-compose is still fairly new to me.

#3506

You can add it via the web interface:

http://<ip.address.to.adbtuner>:5592/configurations/new
Paste it right in here (remove what is pre-populated first).

#3507

Bummer.

At least there's still something we can work with.

I don't believe Xfinity supports user profiles, so this section can be removed -- correct?

Also, @daveasmann is using some pretty old FireSticks, so I'm thinking a second may need to be added here. In addition, can you confirm there's no reason to use a Keep Alive package with compatiblity mode? I can't think where this would make sense.

#3508

Yes, the text match section can be removed. I just copied the default “compatibility mode” config and added the activity. I didn’t try to optimize it in any way. If you have any suggestions I’m sure they would be appreciated. I’m not a comcast customer so I can’t go beyond “did the app open” lol.

And yeah, using the same app for Keep Alive (tuner level) along with a compatibility mode type configuration is counterproductive. There is no reason to keep an app open if you are just going to close it anyway before using it.

1 Like
#3509

@daveasmann Please note the above couple of posts. Also, once you create your new ADBTuner Custom Config, be sure to modify each of your Xfinity channels to use it.

#3510

Excellent! Thank you both. Currently running on 2 firesticks via older versions. I'll get the custom config working on one of the other 2 and apply it to all 4.

Thanks again guys - this community is awesome!

#3511

A post was merged into an existing topic: ADBTuner: ws-scrcpy companion container. Interact with your encoder-connected streaming stick with mouse and keyboard

#3512

I've been running the past few days without keepalive. It worked for months so I didn't mess with it, but it looks like it's not needed.

#3513

All Xfinity Stream channels are changed to the custom config. I'll report back if there are any issues. Thanks again.

#3514

@turtletank I've been using ADBTuner for well over a year now and love it. Thank you for all of the time and effort that you've put into it.

I've been having a few issues since around the first of the year and have resolved all but one that I can't seem to narrow down.

What I see is that occasionally (3 out of 5 mornings) when I start the first stream of the day, or later in the day after a long idle time, ADBTuner presents the YoutubeTV main screen as opposed to the channel requested. I also get a 504 response back sometimes as well.

This behavior seems to have started around the end of last year or the beginning of this one. Around that same time I had other issues such as buffering and pixelating which I ultimately resolved by upgrading my network switch. At about that same time though I also went from the 1X branch of your code to the 2X branch, upgraded my URayEncoder to the latest firmware and of course keeping the Unifi stack up-to-date.

As I said above I've replaced my network switch which made a huge improvement on the other issues, upgraded the URayEncoder to latest firmware, current with ADBTuner, and also upgraded to the newest Onn 4K boxes. I have keep alive enabled on each tuner enabled as well.

Any idea of what may be causing the YouTubeTV main screen to appear rather than the channel? I've run the logs thru Claude and I don't really think it knows enough to understand what might be happening but it seems to feel that I need to raise the issue to you. I can provide logs from this morning if that helps.

#3515

If you can share some logs either here, or via PM, I’d be glad to take a look and see if we can figure out the issue.

#3516

So I just wanted to share, I've been dealing with some weird issues with my Osprey boxes for the past couple of weeks, and I finally found a different deep linking scheme that doesn't use https like we've all been using for ages with Osprey boxes. So far, and by so far, I mean I would have issues within five minutes exactly where my stream would restart, and I've been going steady for at least a half hour now without any issues. So it's still early, but a consistent five minutes versus a steady half hour, a couple of times actually, is not something I want to ignore. I've also tested both schemes back to back and have had a failure within five minutes and then a success for a half hour.

The scheme I'm testing now on my Ospreys is:

dtvnow://deeplink.directvnow.com/ott/tune/live/channel/CALLSIGN/RESOURCE_ID

Just so people don't have to dig, and I know there are a lot of Osprey users using ADBTuner, I figured I'd share this finding here just in case it becomes useful if other people start hitting weird issues with deep links. Since ADBTuner is completely reliant on deep links and ah4c can tune by channel numbers, I figured this is a good place to share this alternate scheme. :grin:

Edit: I'm pretty confident that this dtvnow:// scheme is the solution. So far using it, I have not had a single issue, whereas before I would have an issue within exactly five minutes to the clock. I'm still trying to figure out the why, but I have the what.

#3517

I've changed all my Osprey Deep Links to use your new format. So far, so good, will let you know.

1 Like
#3518

Let me know if you see any weirdness.
I'm still testing, but it's been stable.

What's annoying me is I can't figure out what broke. My best guess is something to do with the old scheme using https. I have a feeling some endpoint on DirecTV's end is either flaking out or being deprecated. I guess the regular app uses dtvnow://. So it would make sense that they would just maintain that scheme for everything internally rather than having an HTTPS scheme for their Gemini hardware, which also kind of makes sense because a new Gemini box is coming.

I also found another scheme that also fails it is https://stream.directv.com/ott/tune/live/channel/CALLSIGN/RESOURCE_ID

#3519

No problem. I added to the Osprey FAQ/WiKi - DirecTV Osprey/Gemini Boxes - #4 by spammedeeper

#3520

Thank you. I have a feeling it has something to do with the new Gemini boxes. I was looking and they cleared the FCC around early June.

I started having issues late June. So I'm wondering if maybe DirecTV is making backend changes. On one hand, this kind of bodes well for our boxes continuing to work. It just means we might have to adapt to whatever changes they make. Hopefully this is it.