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!
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.
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.
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.
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.
I feel a bit foolish now. I just checked my firmware, and it still shows the 2017 one. I tried again, it says it succeeded, and tells me to reboot. I do, and it shows the old one. So I'm a bit embarrassed to say that the firmware doesn't seem to be sticking for me, either.
Well one thing I have done on all my devices (I have 1 Onn and 2 Chromecast) is run a onetime pre-configuration script to squeeze out some more speed. I found it way way back in this thread. I use Windows batch files, but basically it looks like this. They aren't exactly pretty, but you can probably figure out the train on thought.
pre-configure
set device=192.168.1.194:5555
adb connect %device%
adb -s %device% shell settings put global window_animation_scale 0
adb -s %device% shell settings put global transition_animation_scale 0
adb -s %device% shell settings put global animator_duration_scale 0
adb -s %device% shell settings put secure sleep_timeout 0
adb -s %device% shell settings put system screen_off_timeout 2147460000
For my stopbmitunes I use just this. The 3 force-stops are just for additional apps I use too. You can see I have rem-ed out the youtube, but kept it just incase I need it sometime down the road. Always include the KEYCODE_HOME to stop the internet streaming.
stopbmitunes.bat
@echo off
set IP=192.168.1.135:5555
rem c:\platform-tools\adb -s %ip% shell am force-stop com.google.android.youtube.tvunplugged
c:\platform-tools\adb -s %ip% shell am force-stop com.weathergroup.twc
c:\platform-tools\adb -s %ip% shell am force-stop com.cbs.ott
c:\platform-tools\adb -s %ip% shell am force-stop com.haystack.android
sleep 2
c:\platform-tools\adb -s %ip% shell input keyevent KEYCODE_HOME
I have a nightly task that runs at a set time to do the maintenance. The force-stops here are probably unnecessary since the reboot does that... but I keep them because it doesn't hurt. Here is the basic script.
devicemaintenance.bat
@echo off
c:\platform-tools\adb connect 192.168.1.137:5555
c:\platform-tools\adb -s 192.168.1.137:5555 shell input keyevent KEYCODE_WAKEUP
c:\platform-tools\adb -s 192.168.1.137:5555 shell am force-stop com.google.android.youtube.tvunplugged
c:\platform-tools\adb -s 192.168.1.137:5555 shell am force-stop com.weathergroup.twc
c:\platform-tools\adb -s 192.168.1.137:5555 shell am force-stop com.cbs.ott
c:\platform-tools\adb -s 192.168.1.137:5555 shell am force-stop com.haystack.android
c:\platform-tools\adb -s 192.168.1.137:5555 shell input keyevent KEYCODE_HOME
c:\platform-tools\adb -s 192.168.1.137:5555 reboot
c:\platform-tools\adb kill-server
sleep 60
c:\platform-tools\adb connect 192.168.1.137:5555
c:\platform-tools\adb -s 192.168.1.137:5555 shell input keyevent KEYCODE_WAKEUP
rem c:\platform-tools\adb -s 192.168.1.137:5555 shell input keyevent KEYCODE_SLEEP
Thanks for all this. I'll have to see if I can modify this to work on the Mac. For the "pre-configure", I modified it to this:
$DEVICE="192.168.1.167:5555"
adb connect $DEVICE
adb -s $DEVICE shell settings put global window_animation_scale 0
adb -s $DEVICE shell settings put global transition_animation_scale 0
adb -s $DEVICE shell settings put global animator_duration_scale 0
adb -s $DEVICE shell settings put secure sleep_timeout 0
adb -s $DEVICE shell settings put system screen_off_timeout 2147460000
But I get this error for each "settings" command: adb: unknown command settings
Remove the $ from $DEVICE
it should be
DEVICE="192.168.1.167:5555"
@KompilerDJ is correct.
And do not forget, that pre-configure script is really a one time deal. You shouldn't need to run it again unless you do something significant to your android device (like a factory reset).
Thanks, guys. I'm not getting an error, but now it is sitting for a while. Not sure how long this is supposed to take. I called the file (I named it onn1.sh) by running sh [path and name to file]
Update: I missed once instance of $DEVICE, but now I get a device "DEVICE" not found
It's only the first $ that should have been removed, not the rest:
DEVICE="192.168.1.167:5555"
adb connect $DEVICE
adb -s $DEVICE shell settings put global window_animation_scale 0
adb -s $DEVICE shell settings put global transition_animation_scale 0
adb -s $DEVICE shell settings put global animator_duration_scale 0
adb -s $DEVICE shell settings put secure sleep_timeout 0
adb -s $DEVICE shell settings put system screen_off_timeout 2147460000
Thanks, everyone. I'm now trying this maintenance script on a Fire Cube. I'm now able to run the script, but get an "already connected to 192.168.7.157:5555"
If I take out the second line of the script (adb connect $DEVICE), I get "permission denied (path to the script on my Mac"
The already connected message is fine and can be ignored. When I ran it on my NAS, I got the already connected message and no other messages so I assumed that the other commands worked.
I wonder if you could eliminate the post-reboot delay by using one of those apps that launches an app when the device boots up. That way it’s already ready to go when you tune the channel.
That is what I use on XFINITY Stream ... the Initial startup takes a long time.
I use on my FireTV AutoStart - No root_2.2_Apkpure.apk
I know this is a bit of an older comment now, but I have to say - I totally get it. Many of us have to pay for these stations as a package in any event as we are beyond OTA range, and now we're having to spend hundreds of dollars to roughly simulate the capability we have enjoyed for free* in those packages to which we already subscribe.