Has anyone here set this up yet with more than one HDMI source? Asking because I did that today, and am almost there, but not quite successful, and am guessing it's another oversight right under my nose.
For clarity's sake, these are my assigned IP addresses, everything is connected.
10.0.1.171 = HDMI-IPTV stream box 2
connected to:
10.0.1.97 = Chromecast with Google TV (HD)
On the original setup with just 1 tuner, it would tune directly to the desired channel. Now, with the added code for two tuners, the new one listed first, when I choose a show on a channel to watch via the guide, I see it is streaming the proper HDMI output, it's just not launching YTTV. It's not streaming the desired channel. I'm left staring at the newer device's Google TV home screen.
I've screenshot the error message below:
adb: more than one device/emulator
Is that expected? Maybe I've set this up incorrectly or my expectations are wrong.
Here's what I've done so far, to review the basics. I've added a second IPTV→HDMI encoder of the same make/model, gave it its own IP address, and plugged in a second HDMI source. This one is a 4K Onn streamer. I set it up with the same apps and developer access as I did on the first device, and I also authorized adb control. I confirmed YTTV is logged in, and working.
I copied prebmitune.sh, bmitune.sh, and stopbmitune.sh. I am using those for tuner 1 and prebmituneb.sh, bmituneb.sh and stopbmituneb.sh are for tuner 2.
I edited prebmitune.sh to match the appropriate IP address. I added the 2nd "tuner" to the main.go file and rebuilt the executable. But it's still not handling the final step of launching YTTV to the correct channel. Maybe these screens will help explain:
I created one Custom Channels setup for all these channels, the only IP address referenced there is the CDVR server itself. Do I need to create a second Custom Channels setup?
Anyway, hopefully there's something simple I'm missing and my adventures will help teach others too. Or maybe I incorrectly assumed this configuration is supported, and we're expected to use a single encoder with multiple HDMI inputs instead?
Regardless, I'm still having lots of fun with this experiment, so any advice or feedback appreciated.
Need to read full post. Might have to edit response. But for now are you specifying your android devices when you send adb commands. You have to do this like so:
adb -s 10.0.1.172 shell " blah blah"
The relevant script for each android device has to specify it so that adb can know which one to send the command to.
So for your second device that would use bmituneb.sh, prebmituneb.sh and stopbmituneb.sh you need to check each to make sure that the ip address for you second devices is correct.
The original bmitune.sh didn't have any IP addresses in it, so I copied it to bmituneb.sh as an identical copy. You're saying I should customize each of these lines (on both files?) to include explicit IP addresses each time, for every channel change command?
Should I only be editing bmitune.sh and bmituneb.sh in order for these "dual encoders as tuners" to work? If so, how should this command, for example, be formatted instead?
#NBC
if [ $1 = "nbc" ];then
HOME="input keyevent KEYCODE_HOME; sleep 1"
adb shell am start -a android.intent.action.VIEW -d https://tv.youtube.com/watch/9iwfkw-dMAw?onboard=1 -n com.google.android.youtube.tvunplugged/com.google.android.apps.youtube.tvunplugged.activity.MainActivity
fi
Much of the variables laid out at the top are necessary only if we were tuning the the automation method and not with directly links. I just keep them here in case I ever have to revert back to using that google helper version.
You can change the links for the channels if they are different for you and use names instead of numbers like you seem to be doing. The variable to change is the IPADD variable at the top so that the adb program knows which android device to direct the command to.
Remember to do your "chmod +x bmitume.sh" on the file if you are creating a brand new one and discarding or moving the one you currently have.
You will then copy and exact replica of it when you have added all your channels
sudo cp bmitune.sh bmituneb.sh
You will then go into your newly created bmituneb.sh file and change the IPADD variable to the ip addres of your second device.
To test that you have them sending to the correct device in each case simply navigate to the folder containing them in your terminal and tune
./bmitune.sh 155
Or any channel number (or name) you have configured. You should see it tuned in vlc if that program directed to your encoder device ip.
Oh, and be sure to put the IPADD variable in your other two scripts for each device where you see it placed at the top in the example I have given
In this example I have chosen not to exit YTT for faster tuning in case I have something else to view or record.. The command just exits the live stream.
Thanks @boukmandutty and @tmm1, that was exactly the nudge I needed. All of that made total sense, and I appreciate the time you took to explain it all.
I now have both encoder/tuners online and operational. I was able to set up concurrent recordings, one on each AndroidTV dongle. Even just tuning from channel to channel from the Live Guide on my AppleTV client is working better than before. I'm not sure how to manually select a "tuner" or to prioritize one over the other — or even how to discern which one is being used — but CDVR seems to be figuring out which one to use, on-the-fly.
I will say, the Onn TV device's interface feels a tiny bit faster than the CCwGtv dongle, but not enough to care which one takes priority, since both will be mostly dedicated to YTTV channels anyway. And both of their streams are getting encoded to 1920x1080 regardless. The overall user experience with these HDMI sources feels noticeably improved with an additional tuner to serve up these otherwise "lost" channels to CDVR. I've noticed channel surfing between then still has some hiccups and I have to move a bit slower than I do when surfing "regular" channels, but overall it's certainly working better and faster than it was before.
This is great.
I'd been thinking about asking about such tweaks, hoping to minimize the time it takes to surf to another channel, and your instructions beat me to the punch. I'm trying that out now and it seems to be working pretty well! Certainly faster than it was with the original stopbmitune.sh. bringing me back to the home page with every exit. With this tweak, any speed difference in the tuning of the Onn device vs. the CCwGtv dongle via the prebmitune.sh script is pretty much imperceptible. This change shaves off 2-3 seconds from each channel change, Now they only take 1-2 seconds each.
Again, this is great.
One piece I also found useful was incorporating a cheap HDMI splitter with the Onn streamer, so I could feed its output direcly to the TV when I want to play around with an Android TV device, and not be restricted to HD output via the IPTV encoder and Channels.
The next project of course, is straightening up all the equipment involved
If anyone still reading is on the fence and scared to try this, don't be. I'm certainly no coder but here I am now with two IPTV>HDMI tuners feeding a bunch of desired live TV streams into Channels DVR. If the ingredients are within your budget and you want to maximize what your CDVR setup is able to work with, my advice is, don't be intimidated, the fantastic folks here are eager to help, and you may enjoy it as a fun and educational experiment too.
I typically just view the encoder using VLC - I have (4) VLC shortcuts on my desktop, one for each encoder input. I can have a small window open for each encoder on my PC and watch as I play around.
It'll be interesting to see what everyone's experiences will be regarding overall stability. I'm currently using (4) Xbox 360's to feed the encoder, and aside from a 5:10 AM automatic reboot of all four each day and that they can heat my entire basement, it's been fairly stable.
The apps that the streaming stick is using to play the television as well as the occasional upgrades to the sticks hopefully doesn't get too out of hand. I wonder if a specific streaming stick could be rooted to get better control of it, and most Channels users would then probably purchase that stick.
Nice work! I've got one android unit running only due to duplicating what you have done on this thread. Thanks. Once everything is running and stable is there any reason the pile of boxes and wires could be located to another room? I'd like to put all of this next to my Synology NAS downstairs. I'd also love to get the Go scripts and ADB install running on the Synology instead of my Mac since the androidhdmi-for-channels processes need to run 24/7 for the DVR. I have no clue if this is even possible.
Wondering if we can get a write up on this, can we use any app like Fubo tv Hulu tv or any app tying to use Plaenta tv that my in laws watch polish tv and they have are time with the app
Sure, so long as the hardware is on the same LAN as your CDVR server, it shouldn’t matter. I was considering that too. I may end up moving one of my tuners to another room if only to clear some space in that cabinet. The other I will leave in the living room but only because of the aforementioned HDMI splitter that shares its 4K output simultaneously with my TV’s input #2. If you don’t have that set up, then all of your gear can go to another room. It just needs network connectivity, and AC power.
This is new, so folks here are still experimenting, I haven't seen anyone try Fubo yet, but Hulu Live works, using different commands to launch to the correct channel, thanks to this awesome share by @jad3675:
I'm thinking Planeta TV's app would work too, you'd just need to figure that part out: how to launch the Planeta app, and more importantly, how to get it to start playing the livestream, if it doesn't automatically default to that.
Mmm interesting wonder if I can use n8n.io and a web hook to change the channel I’m gonna get the hardware and test might just try to emulate android on my pc and test you have woken the beast lol
Thanks for the suggestion of sending keyevent 86 (stop media) instead of closing the YouTube TV app. Not having to restart the YouTube TV app definitely helps in tuning speed.
I don't know if this is just with the devices I'm using, but this doesn't quite work with the first tuning attempt after the device wakes up from sleep. The YouTube TV app appears to open the correct channel, but the output is just a black screen.
As a compromise I added the following to prebmitune.sh to force a restart of the YouTube TV app, but only if the device was asleep.
prebmitune.sh
WAKE="input keyevent KEYCODE_WAKEUP"
CLOSE_YOUTUBE_TV="am force-stop com.google.android.youtube.tvunplugged"
# YouTube TV sometimes fails to load video if the app is already open when waking up from sleep.
IS_ASLEEP=`adb shell dumpsys display | grep mScreenState=OFF`
if [ $IS_ASLEEP ];
then
adb shell $CLOSE_YOUTUBE_TV; sleep 2
adb shell $WAKE; sleep 2
fi
There is probably a less aggressive fix, but this works for now to at least make sure the stream loads for a scheduled program.
Thanks for that too. Such a great improvement. I just reviewed this thread to track my progress and see these...
With all of the recent tweaks, these YTTV->HDMI source channels are changing very quickly now, taking less than a second each. Which is just as fast, if not faster, than any regular TVE stream. Sweet!
Was looking for a way to run the androidhdmi-for-channels.sh script as an app on my mac instead of having an open terminal window open and so I can put it into my startup items to launch on mac startup. This seems to do the trick.