Is it possible to add an ADB Check to see if the package is running by checking the pidof ?... I am ok as I have 4 tuners but others with less will run into issues.
It's not a question of whether the package is running, it's a question of whether it's actively streaming or not. I also have an audio check function, which as I'm writing this occurs to me might work with Xfinity -- as I don't believe there's audio if there's no video stream. DirecTV on the other hand, plays last channel audio even it's not showing the video.
1 Like
Awesome work, glad my idea has helped but all credit has to go to you guys for coding all this for free, very generous.
One problem I am running into on my app atm is, I think, if a tuner hasn't been loaded for a while and I load the previous most channel, I think it thinks its already there in the app ready to go - but it had actually timed out and doesn't end up loading - but then the next tune usually works. Will do some more testing this arvo - I think going back to the input key event 4 21 23 3 instead of a simple input keyevent 3 would fix my issue as it gets rid of the current media session I believe - but it also is rather nice loading in a stream and not even getting any of the UI elements of the app (keeping the media session 'active').
When you have a moment, can you confirm there's no audio when the Xfinity Stream app is sitting on the guide? If so, I'll switch to an audio based tuning check -- which I can run every x seconds, and consider the tuning successful when audio is detected. That should result in a given tuner being released more quickly.
Was thinking with my previous reply, I may have to introduce a pre tune command to solve this problem.
I am loving adbtuner with its tuner management, UI and delaying the video being sent til media is playing.
Does your ah4c have similar features? As I'm not sure how easy it will be for me to put in a pre tune as a google-copy-paste coder 
I had a similar situation with DTV, and in that case it happened if the app hadn't been used in 4 hours -- it would always be reloaded. Whether active or not. Easy enough to script for once the pattern was known.
When you have a chance could you submit your M3U for the Foxtel app, and the deep link format. With that info, I'll add it to ah4c, so the next guy will be able to spin up Foxtel support with very little effort. One of the great things about ah4c, is once we have the "formula" and M3U for a given app, the only user configuration needed is getting your streaming sticks ready.
Oh okay nice one!
So would be able to keep input key event 3 in all cases except when its been 4hours (or whatever the number of hours it times out) the it'll trigger a force close of the app before the deep link is sent?
ADBTuner is a great project, and @turtletank has done a fantastic job with it. In all candor though, with what you're trying to do, ah4c is the correct project for you to be using. I understand about the WebUI and other features, but ah4c is designed to support easy user scripting using Bash.
Absolutely, I've written pretty much everything in Bash function form so that it's reusable and portable.
That means that it's waiting for the OCR scan to complete before running the stop script. The audio check is going to be the answer for Xfinity. I'll make the change soon, but it probably won't be until tomorrow.
Yeah sort of thinking the same with the apps that require abit more fiddling.
I’ll run some tests later if I have time but could it also be an option to run a few adb checks instead of a timer.
I might be wrong but I have a feeling if I can check the media state, if the app is open and it thinks there is paused media the deep link will open.
But if the media has timed out it won’t. (I have then opened the encoder in VLC to find a channel paused…)
Or it could be some other code in adbtuner that is causing the stream to pause and then never sending it. 
This is error ...
[EXECUTE] Stderr: '++ echo HBOSH-5232923399725817105
++ awk -F- '{print $2}'
+ channelID=5232923399725817105
++ echo HBOSH-5232923399725817105
++ awk -F- '{print $1}'
+ channelName=HBOSH
+ specialID=HBOSH
+ streamerIP=192.168.50.139
+ streamerNoPort=192.168.50.139
+ adbTarget='adb -s 192.168.50.139'
+ packageName=com.xfinity.cloudtvr.tenfoot
+ packageAction=com.xfinity.common.view.LaunchActivity
+ trap finish EXIT
+ main
+ updateReferenceFiles
+ mkdir -p 192.168.50.139
+ [[ -f 192.168.50.139/stream_stopped ]]
+ [[ -f 192.168.50.139/last_channel ]]
+ echo 1792
+ echo 'Current PID for this script is 1792'
+ matchEncoderURL
+ case "$streamerIP" in
+ encoderURL=http://192.168.50.242:8086/0.ts
+ specialChannels
+ '[' HBOSH = exit ']'
+ '[' HBOSH = reboot ']'
+ [[ -f 192.168.50.139/adbCommunicationFail ]]
+ echo 'Not a special channel (exit nor reboot)'
+ tuneChannel
+ adb -s 192.168.50.139 shell am start -n com.xfinity.cloudtvr.tenfoot/com.xfinity.common.view.LaunchActivity https://www.xfinity.com/stream/live/HBOSH/5232923399725817105/HBOSH
Warning: Activity not started, its current task has been brought to the front
+ tuneCheck
+ sleep 40
+ ffmpeg -i http://192.168.50.242:8086/0.ts -frames:v 1 -y 192.168.50.139/screencapture.jpg -loglevel quiet
+ tesseract 192.168.50.139/screencapture.jpg 192.168.50.139/screencapture
Tesseract Open Source OCR Engine v4.1.1 with Leptonica
Warning: Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 392
+ grep -q 'Filter\|Today' 192.168.50.139/screencapture.txt
+ '[' 0 == 0 ']'
+ echo 'Deeplink tuning appears to have failed. Killing app and re-tuning...'
+ adb -s 192.168.50.139 shell am force-stop com.xfinity.cloudtvr.tenfoot
+ tuneChannel
+ adb -s 192.168.50.139 shell am start -n com.xfinity.cloudtvr.tenfoot/com.xfinity.common.view.LaunchActivity https://www.xfinity.com/stream/live/HBOSH/5232923399725817105/HBOSH
+ finish
+ echo 'bmitune.sh is exiting for 192.168.50.139 with exit code 0'
ADBTuner's docker logs are quite verbose and it uses a few methods to try to detect video playback (as does ah4c). Reviewing the logs could help provide a clue as to what's happening. You can also add ?adb-debug=1 to the deep link URL in ADBTuner to watch what is happening on-screen.
Not going to post much about it here, but if you want some help in troubleshooting that I would be glad to help. I will however say from experience that some of these apps use homegrown media players that behave poorly. You might end up getting nowhere with consistently loading content without restarting the app. Many of us have tried before lol.
2 Likes
Yeah I had a feeling it would be the custom video player.
That’s for the offer, away over the weekend but when I get back will do some more testing and reach out via pm if I’ve got any queries for you.
Oh yep usually I just load up VLC with the encoder link but I’ll give that debug a shot!
But definitely agree with your approach to comparability mode if the default way doesn’t work - had a couple of failed tunes so just trying to work out why that’s happening, problem is if a tune fails, the next tune usually sorts itself out - would be nice to catch one of these failed tunes with my own eyes.
At first I thought it may have been a timeout but sometimes it happens within a fairly short time frame (never a back to back tune though)…anyway will report back if I figure it out just incase it helps out anyone.
I disabled this with the new changes ... tuning really became unreliable ... will re-enable and test new release. When available.
I've switched to the audio based streaming check for Xfinity, and it's definitely faster to complete the virtual tuning script (bmitune.sh). I'll see if I can break it over the next day or so, but if it stays solid for me I'll do a fresh build.
1 Like
I am available to help you break it or not no recordings scheduled.
I'll take you up on that. 
I just did 50+ test tunes with no problems. It still takes a bit to let go of the stream when you stop, but it's not because bmitune.sh is still running. Build is done, so re-pull :latest and see what you think.