AndroidHDMI for Channels (ah4c): A virtual channel tuner using HDMI Encoder(s) + streaming stick(s)

ok, i didn't sleep at motel6 so I don't really know. :sleeping:
just logically in my head it threw flags.. hope it works for you.

so far my extra home command seems to be working for me, but would be much quicker if I set my ospreys to just stay on home at wake instead of tuning the last channel. (I'll play more this weekend)

I am going to try to add maybe like a timeout or something.

You do make a valid point. It would retry forever.

@Shaggylive I added a 15-second timeout so it doesn't retry forever. I'm building the Docker container and testing right now to confirm that everything is solid. But that is a good point. Thank you so much for bringing that up. I really appreciate it. That made the PR a lot safer.

Edit: confirmed that the fix I wrote still works with the timeout added. If the encoder hasn't produced any real bytes for 15 seconds straight, the reader gives up and closes so Channels DVR sees EOF and can react normally.

Edit 1: I tested the timeout by starting a stream and immediately cutting the HDMI input on my encoder, and it did work. It attempted to stream 3 times and then gracefully closed the connection after 18 seconds. If anyone's running into this issue, feel free to pull my image and let me know if it's helpful at all. I really hope this benefits others. :slightly_smiling_face:

I noticed a surprising number of people for a test build pulled my Docker image. Has anyone here tried it? I'm just curious if it's working well for people. Obviously it's a test image and not meant to replace anything or step on anyone's toes. It's just to see if my potential fix worked.

For me it's been working like really well. I've been tuning very quickly and not having any unintended side effects from what I could tell.

so I do have an issue without the sleep 1
here's two clips showing the difference.

I'm still making sure I fix my favorites wizard and adb auth issues, so my ospreys are set to launch to home while i verify this. It does make the skip 1 issue plain as day, but I think I actually only needed the delayed retry's with dozens of adb auth windows hiding on the home screen (background)

@mackid1993
I have not been able to recreate your issue on linkpi reboots, but I've been focused on my other issues. something that I've mentioned, but not specifically with your issue is on the fac.php I have my EDID set to 1080. and I've set my ospreys to match my input settings hdmi=1080p60 usb=1080p50 (I was happy to see 1080p50 as an option in osprey)
the issue you've described seems to be a hdmi handshake delay so matching starting points should speed it up.
sorry if you've covered this, but my memory's kinda shot, celebrated early :v:

Where are you adding the sleep 1?

only sleep in what you posted :crazy_face: is not in bnhf/ah4c:latest

1 Like

Unfortunately it didn't fix anything for me.
The only thing that helped was the patch I opened now as a PR which will hopefully get merged if I'm lucky. :crossed_fingers:

@ChannelSam

I just installed the Spectrum app on an Android TV device and attempted to configure it with ADBTuner. I tried several deep link formats for individual channels based on the Apple TV implementation, but I haven't been able to get the app to launch at all. Have you had any luck finding the correct deep link structure?

worth trying these (i dont have spectrum creds to test myself)

adb shell am start -n com.TWCableTV/com.twc.android.ui.login.SplashScreen
am start -n com.TWCableTV/com.twc.android.ui.livetv.phone.LiveTvPhoneActivity --ei channelNumber 7 --ez initialLaunch true

What device did you install on? Because the actual app is not available as far as I know on Android TV devices so some people installed the mobile app and it doesn't work in the past at least.

Supposedly I think on April 18th it became available for the fire TV devices but I haven't checked into it yet.
Quick way to see if they have deep links available is to go to the spectrum website and see if you can't "cast" a channel directly to your device.

If I get a chance I'll try to look at a fire TV stick this weekend.

The Spectrum TV app is available for current FireTV devices. However, new Fire TV devices will not be Android-based,

It appears to be available for all Android TV devices; I have successfully installed and tested it on a Sony TV and two Nvidia Shields.

1 Like

That is great news about Android now.
I posted a link to Cordcutters earlier in the thread on Mar 31 about firetv support starting in April but they had no information about whether it would be made available on Android at the time.
@Pasker17 I just loaded the spectrum app on my onn google tv dongle and using my desktop i told it to cast a channel I was watching and it went directly to that channel stream on onn tv. So that means it does have deeplinking to the individual channels. Have you had a chance to look at the suggested format from @KineticMan ?
I will try and spend some time on this in the next few days.

It was merged. Thank you @bnhf! Not sure if Scott Ullrich is on the community but thank you as well! The trust in my work is greatly appreciated and I'm very happy to contribute a feature! :slightly_smiling_face:

Once the docker is up; to enable TS Null Packets (for hopefully better stream reliability) set NULL_FRAME_INSERTION=TRUE. TRUE must be all caps. I found this to solve the issue whereby on a fresh encoder (LinkPi) boot, the stream fails to load. I can now reliably tune my Ospreys from sleep in around 5 seconds.

Great news about deeplinking; I should have time to play with it over the weekend.

What's the best way to give feedback or contribute? Started playing around with this, and using the osprey scripts as a starting point, but the included example scripts do things that don't seem to make sense. For example, the prebmitune script runs an adbConnect function and then an adbWake function, but the adbConnect function already tries three times to do the wake. The bmitune script declares variables that it doesn't use, and runs methods that don't do anything as their result is also never used.

I've updated the Osprey Deeplinks Scripts to support keep watching (so the ospreys can sleep but also not time out during a long session). I also contributed a new feature. I suggest opening a PR!

1 Like

I suggested you start with scripts/osprey/dtvosprey primarily because they use the same remote control emulation of number presses you were talking about.

Over a number of years, people have adapted various previous scripts, and not always taken the time to remove unneeded functions or variables. You should create your own set of three scripts in a directory called scripts/<streaming device>/<streaming service>.

There's another set of scripts that may be a better model for what I suspect is the simplicity of your requirements. Check out scripts/allente/livetv. I helped someone create those a couple years ago, and they're some pretty basic scripts for sending number keycodes to tune -- which might be a better match for you.

And yes, please contribute back in the form mentioned above, and include your <streaming service>.m3u file as well.

4 Likes

Apologies if I've missed it in this thread or the documentation, but when are the prebmitune.sh and stopbmitune.sh scripts run? I assume the pre script runs when Channels tunes to an ah4c-managed channel from a non-ah4c managed channel? Then the tune script runs when Channels switches between different ah4c-managed channels? And then the stop script runs when Channels tunes away from an ah4c-managed channel to a non-ah4c-managed channel? Or is it more about timeouts, idle times, etc? Thanks.

It's nothing too complicated:
The value of $STREAMER_APP defines which set of scripts is run.
Each script must exist and be written in Bash.
All 3 scripts are run on each virtual tuning cycle.

Generally:
Use prebmitune.sh to confirm adb connectivity and wake your device (if needed).
Use bmitune.sh to do the virtual tuning.
Use stopbmitune.sh to stop the streaming and put your device to sleep (if needed).

Each script is passed the value of $TUNERx_IP and whatever the value is after the last slash in the URL for that virtual channel in the M3U. Note that for historical reasons those arguments switch order in bmitune.sh.

Super simple, but also very flexible, as you'll see if you explore the various scripts in the repo. As I understand your requirements, something like those that were done for scripts/allente/livetv may be about all you'll need. There's always an M3U file as well, for each set of scripts, so have a look at allente.m3u to model that.

1 Like