For this connectivity testing purpose, sending KEYCODE_WAKEUP is reasonable. I don't know the precise android definition of what happens after KEYCODE_SLEEP, but it certainly turns the display off, and you need to make sure it comes back on at some point.
(I'm doing some experiments now to see if there is any need to wait for the screen to come on before doing any remote emulation. I had assumed there was, but maybe that's not so.)
I decided to see what the difference is between being asleep and being awake for my Android TV device. For me, it's a Chromecast HD with Google TV (not the 4K version).
When asleep, the device is consuming 0.9 W. When awake and idle (not streaming video), it varies between 1.1 W and 2.0 W. When actually streaming, it spikes as high as about 2.5 W but has a steady state that I eyeball between 1.5 W and 2.0 W.
I'm kind of surprised it's so low since the device feels a little warm. With numbers like that, I'm not worrying too much about keeping the device awake all the time. This doesn't include the power drawn by the HDMI encoder box, but I don't have any control over that anyhow.
A big part of the motivation to putting streaming devices to sleep, is not so much related to the device itself -- but rather to the encoder.
If your device doesn't sleep, and is displaying video constantly, that means your encoder is constantly encoding -- whether you're watching anything or not. Multiply that times 4 or 5 devices in the typical multi-port encoder, and your encoder is hard-at-it 24x7. There's power draw, heat generation, and un-needed encoder CPU utilization all associated with a no-sleep strategy.
I have the popular EXVIST single-channel encoder. When the dongle is sleeping, the encoder is using 1.3 W. When the dongle is awake but idle (not streaming video), the encoder draws 2.6 W. When the dongle is streaming video, the encoder draws 2.8 W.
I don't doubt that there are devices with higher loads, but I wouldn't worry about it without actual power measurements showing that it's worth the trouble.
Your numbers prove the point though don't they? Double the power usage when doing basically nothing, and that's for one single-port encoder. Personally, I have 5-port, 4-port and a 1-port encoders in everyday service.
The other observation I'd make, at least with the streaming sticks I have, is that putting them to sleep and waking them up both happen very quickly. Obviously these things vary with the type of equipment you have, but at least with the FireStick 4K Max and Max 2, there's very little motivation to not have them sleep.
Sure, but even that double is a pretty trivial amount. It's probably way less than the standby power for various devices in my house that have "soft off". Before I measured it, I thought the absolute difference was going to be a lot bigger.
The reason this is interesting to me is something that might be peculiar to the EXVIST device (and maybe some others). When the dongle is sleeping, it shows a static image "Video Lost". The codecs for that are funky in some way that Channels doesn't like.
2024/06/14 16:39:28.068367 [ENC] Starting encoder for ch28 in /shares/DVR/Streaming/ch28-dANY-ip192.168.1.33-1696669460/encoder-1-3963693481 at 1 (0.000000) (encoder=h264_v4l2m2m, codec=h264, acodec=copy, resolution=1080, deinterlacer=blend, bitrate=10000, segment_size=0.01)
2024/06/14 16:39:28.080797 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: [mpegts @ 0x1c5a7080] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
2024/06/14 16:39:28.080917 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: Consider increasing the value for the 'analyzeduration' and 'probesize' options
2024/06/14 16:39:28.080960 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: [mpegts @ 0x1c5a7080] Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp): unspecified sample rate
2024/06/14 16:39:28.081002 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: Consider increasing the value for the 'analyzeduration' and 'probesize' options
2024/06/14 16:39:28.083727 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: Cannot determine format of input stream 0:0 after EOF
2024/06/14 16:39:28.083886 [HLS] ffmpeg: ch28-dANY-ip192.168.1.33-1-h264-copy---10000-0-1080-0-0---false-false-0.01-0: Error marking filters as finished
2024/06/14 16:39:28.099973 [ENC] Encoder stopped for ch28 in /shares/DVR/Streaming/ch28-dANY-ip192.168.1.33-1696669460/encoder-1-3963693481 after starting from 1 without encoding any segments
2
Channels treats it as an error and retries a couple times. Not that it matters, but VLC closes the stream when the encoder switches from static to video or vice versa; VLC doesn't have any trouble displaying either thing, but it doesn't care for the transition.
It makes the timing to wake up kind of complicated. With enough effort, I could probably work it out. (I should say "with enough additional effort" because I've already spent quite a bit of time on it.) I'm taking the lazy man's easy way out.
I'm not criticizing, but I am curious if you have measured the power draw of any of those encoders in various states.
I haven't. Mostly I'm just trying to share what's worked well for me over the last year, and that includes the state devices begin and end in. If you have something that's working for you, with your mix of gear and streaming app, definitely go with it.
That's part of the reason I organized the scripts by device/app, which allows for this kind of variation. Timing can be a significant issue with remote control emulation, and that can be easily affected by your specific combination of stuff.
For anyone interested in the PBS app, my PR with scripts and sample m3u has been merged into the repo. The scripts use remote control emulation to navigate to the live stream. If you have more than one PBS affiliate in your area, the scripts know how to switch among them.
More info in the README.txt
And, now included in the multi-arch ah4c container! New bnhf/ah4c:latest (aka bnhf/ah4c:2024.06.21) with PBS app support courtesy of @wjcarpenter
I'm curious, why do we need controls for the PBS app when the docker container works great and allows you to tune as many different PBS channels as you want?
I believe @wjcarpenter's primary motivation was to have Closed Captions, which aren't available in the vlc-bridge-pbs project.
Thanks, forgot about CC.
If someone figured out how to turn on CC in that bridge, that would be fantastic. All my test wells have come up dry so far.
Curious why these android boxes lose ADB key connection? Happens once every couple weeks and I have to re-allow ADB with the prompts on the screen. Usually i have to update the stack and then the ADB prompts come up again so i can allow:
2024/05/22 17:42:35 [EXECUTE] Stderr: '+ streamerIP=10.10.10.163:5555
+ streamerNoPort=10.10.10.163
+ adbTarget='adb -s 10.10.10.163:5555'
+ mkdir -p 10.10.10.163
+ trap finish EXIT
+ main
+ adbConnect
+ adb connect 10.10.10.163:5555
+ local -i adbMaxRetries=3
+ local -i adbCounter=0
+ true
+ adb -s 10.10.10.163:5555 shell input keyevent KEYCODE_WAKEUP
adb: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
+ local adbEventSuccess=1
+ [[ 1 -eq 0 ]]
+ (( 0 > 3 ))
+ (( adbCounter++ ))
I have not seen this with ah4c, although I have with ADBTuner. You're using ah4c with Ospreys and the @spammedeeper scripts -- is that right?
I have only had to re-allow ABD on AH4C on the Osprey setup twice. First was when a major update to Android came through. Second was after my docker upgrade where I accidentally cleared the keys. Otherwise stable.
I’ve had to auth ABD many times on ADBTuner. But I’m using Chromecasts and they get more frequent updates.
Anybody working on an updated channel list for DTV Streaming channels? With the death of Paramount and the new 4000 series channels, I've been adding to my Osprey setup. It took some time to find the callsign / station-ids for the 4000 channels that I wanted.
BTW, this setup has been flawless for 2 months now. Thanks to @spammedeeper for all the work!
I plan on adding more Ospreys soon as I select another encoder...
Since you say you are looking at a new encoder, might I recommend you give LinkPi a look? I’m running the five port ENC5 V2 and it has been great.
Little lost here. Set up an Osprey, set up Portainer and I think I got the stacks running right. I am not sure how to enable developer mode on the Osprey, or what is needed to be changed on the Osprey. I did look up how to get into Developer Mode, but I think it's changed from what I had read on Reddit as that thread was over 2 years old and could not find much new on it.
I set everything up and go to scrpy and see this.
Not sure where the 5555 port is coming in.
Any help would be muich appreciated!
@krazijoe To enable Developer Options on the Osprey:
As to port 5555, that is the standard listening port for ADB server running on the Android device, once you turn on USB Debugging 