Sounds like a good plan. Sorry, got you guys mixed up.
I will say that, on the unit with 4 HDMI inputs, I have disabled all substreams. I just don't want that unit having to deal with 16 streams simultaneously.
1 Like
Interesting. I didn't consider that. I've gone ahead and disabled them now too. Thanks for the advice.
A big shout-out to @cyoungers for helping @KompilerDJ and I do some serious "stress-testing" on both his repo and my Docker container tonight on Discord.
It's all too easy when you're developing something to avoid the potholes in the road when testing -- but with @cyoungers help we were able to identify and correct a few things.
The bnhf/androidhdmi-for-channels:alpha container has been updated already -- with a few more improvements to come later tomorrow. Nothing says fun like an "alpha" project in the Channels - Playground! 
3 Likes
A lot of features have landed in the last week. A few of them are:
Application based tuners (IE: hauppauge colossus 2)
E-Mail alerts on failures
Global logging to disk with rotation
Logging endpoint /logs for moments you do not have access to console with dynamic refresh!
Logging endpoint /logs/json for your scripts to consume
Webhook support on failure use $reason variable in URL.
2 Likes
For anyone looking for a ultra cheap HDMI encoder solution, check this out. Ludicrously cheap HDMI capture for Linux
Tempted to try it out...
I'm tempted too, but I just ordered a used FBE200 off ebay for $50. Those HDMI extenders seem to be available on ebay for under $50 for just the sender (wouldn't need the receiver). Search for LKV373A.
2 Likes
EDIT: the ebay item was refunded and noted out of stock.
1 Like
Let us know how it goes! I am curious about these types of hacks.
One of the interesting features of application based capture
is doing post processing of the video. For example I am capturing 720/50 and then upscaling to 1080p via ffmpeg. Also applying a few ffmpeg filters along the way.
This shows the difference between the cheap capture device and a black magic device (top is black magic) and applying a few filters. The network capture device seems washed out?
1 Like
In honor of the 200th download of the androidhdmi-for-channels container, I'm making some improvements to the organization of persistent data.
What this means for you as a user is that you'll want to stop your ah4channels container, relocate a few directories and make a couple of changes in your Portainer - Stack. This will result in a better grouping of your data, plus it'll allow me to make some needed changes inside the container.
I use /data2/androidhdmi-for-channels as the directory I bind to the container, so my examples will be based on that.
Your current ah4channels related data directories will look something like this on your host computer:
And under androidhdmi-for-channels like this:
So, what we're going to do is move the adb directory under /data2/androidhdmi-for-channels. In addition, we're going to create a scripts directory there, and move whatever streamer directories you have (onn and firetv, in this example) under that new scripts directory. The html directory can be deleted. When you're done, it should look like this under /data2/androidhdmi-for-channels (or whatever directories you use as "parents"):
That's it for the data, so on to the the changes to the docker compose in Portainer - Stacks. There are changes to the image you're pulling, the STREAMER_APP environment variable, and several changes to volumes.
Update these lines (images with this new structure will be tagged alpha2):
image: bnhf/androidhdmi-for-channels:alpha2
There are now 3 directories to bind (/scripts, /m3u and /adb) to whatever parent path you're using on your host:
volumes:
- /data2/androidhdmi-for-channels/scripts:/opt/scripts # pre/stop/bmitune.sh scripts will be stored in this bound host directory under streamer/app
- /data2/androidhdmi-for-channels/m3u:/opt/m3u # m3u files will be stored here and hosted at http://<hostname or ip>:7654/m3u for use in Channels DVR - Custom Channels settings
- /data2/androidhdmi-for-channels/adb:/root/.android # Persistent data directory for adb keys
And lastly, the STREAMER_APP env var needs to have "scripts/" added to it like so:
That's it. Update the stack, and use the "Re-pull image and redeploy" slider, and you should be in business! Check the Portainer log for the container to confirm.
1 Like
Thanks for sharing this info and the last firmware. My two encoders are both "HD IPTV Streaming Encoder FBE200-H.265-HLS" models. One is on "E265-20190624-HLS" firmware and the other is "E265-20190528-HLS."
Since "20201220-E265-FBE200-H" is newer, I tried updating, but it doesn't stick.
The upload completes successfully, but after rebooting (via the reboot button, or by physically unplugging and replugging the units) the devices are still on the previous firmware. For what it's worth, I tried both Safari as well as Chrome browsers...
Both encoders continue to work fine for me, so this isn't that big of a deal, but I'm mentioning it in case anyone else experiences the same, or has other ideas to share.
After hearing @KompilerDJ talk about the speed of the Fire Cube, I broke down and bought one yesterday when it was on sale. I'm trying to get it set up now (go through the whole ADB debug, rebuild the app, etc.), but I'm getting an error like this when trying to tune in Channels:
Error: Activity class {com.google.android.youtube.tvunplugged/com.google.android.apps.youtube.tvunplugged.activity.MainActivity} does not exist.
Any ideas? Is the command different on the Fire devices?
This is working for me:
adb -s $TUNERIP shell monkey -p com.google.android.youtube.tv -c android.intent.category.LAUNCHER 1
Thanks! Was just about to report back that this seems to work, but I've only tested it with one channel:
adb -s $IPADD shell am start -a android.intent.action.VIEW -d https://tv.youtube.com/watch/cQDDAyx_fWM
Let us know what you think of the Cube!
1 Like
For anybody who doesn't mind the price, wow! With the .onn 4k streaming stick, my load time from click to channel fully on was about 13 seconds. With the Cube, I'm between 6-8 seconds in testing two different channels. That's not scientific, but just me tapping the stopwatch on my iPhone with one hand, while I click the channel in the Channels guide on the Apple TV with the other.
If these speeds continue, I'll be keeping it. I had told myself that 8 seconds or less would be a "definite" keep, while 9 or so would be a "maybe," and 10 and up would be a "probably return it."
EDIT: Those times were when viewing via my oldest Apple TV. I just tuned a channel on my iPhone 14 Pro, and my less-than-scientific use of the stopwatch on my Mac had it tuning in 4.68 seconds.
2 Likes
After two months in this thread I took the knowledge gained and put it into an alternate application for tuning channels for HDMI encoder usage.
I think it came out great and is worth a look if you are still using dedicated Google TV devices with HDMI encoders.
The collaboration was fun and hopefully we can keep making this better across all of the different software tools.
7 Likes
With my Onn I go from click to channel in 5 seconds. But I also do not put a force-stop in my stopbmitune file. I also do not have to listen to that YouTube tone and logo with every channel change.
The only time that comes up and there is a delay (which is about 14 seconds) to channel tune is once daily right after my system does maintenance reboot of the device. I am assuming others are putting in that force-stop to maybe deal with av sync issues and what not. But I haven’t encountered those issues since I started the daily reboot.
1 Like
That's nice to hear. I copied the great work from others, but maybe I'll have to try some alternative tuning tuning scripts.
EDIT: Are your scripts in this thread anywhere? I'm not sure how to search it by user.
1 Like