So all fixed now, one tuner stays live for the block?
an update from a bit back
yes
I thought wrong or got lost in changes without letting everything settle. actually I think it was from fighting with an inferior encoder and trying too many things to fix a hardware problem. linkpi ftw!
1 channel = 1 tuner if padding overlaps
finally looked through the log and verified the padding fixed.
is ah4c/bmitune managing this or is channels? I wonder if a few lines could be added to handle stop time=start time the same way padding is handled. all the error handling works as it should, but perhaps the retries and recording started late flags would only happen when back-to-back recordings are on different channels. then you'd know you might want another tuner.
1 Like
Mostly tuning to my network. I like to play with tuning that is as fast as possible, while hiding the automation from the stream. I settled on a 12 second delay in my custom config, which was enough to allow the app to finish loading. I also like my devices to sleep after tuning, which is the extra commands at the end. If the Compatibility Mode works for you, use it!
Some things I've learned. If you leave the app running, the next deep link is very fast, especially on the Onn 4K Plus. But as you found out, a bad or delayed link makes the app puke. This is why I add the -S to the AM Start, to force fresh start of app each time. Been pretty reliable as my backup source.
On the topic of deep links opening quickly if app running in background. This is why the Osprey is pretty quick. The DirecTV app is (essentially) the launcher, so it's always ready. Not saying rush out and buy an Osprey from eBay as it won't run apps well like the Onn, but when tasked with turning channels, they work really well.
The only notable challenge I had with the Onn boxes was one of them wanting to sleep all the time. I fixed it somehow, in one of these threads. Other than that, they are great little boxes for $30.
Keep testing, send questions my way, happy to help.
Awesome! I too timed with my phone, and got around 10-12 second tuning speed, last I checked. Pretty darn good.
One thing I remembered. With the Onn 4K Plus boxes (and the regular Onn 4K) I had to boost the audio gain +6 dB to get the audio close to what my Osprey's were doing. Setting in the LinkPi encoder. It may be fine on your setup.
I am having an issue when I hit the streaming limit on my YouTube TV account. When the streaming limit screen is displayed, I either need to use the remote to get the ONN TV Pro to exit the screen, or I remotely power cycle the device.
Could an option be added when clicking the In-Use - click to release lock button, to send a ADB command to exit this screen or go to the Home screen?
Thanks for the amazing work on this project!
1 Like
Be happy to try. I have time tomorrow, I will throw it on my test setup and see what happens. You're using Onn 4K Plus, no?
I have added this to my ever expanding list of ADBT configurations. Is this an improvement over your previously posted version "0"? I'd like to try testing this and prefer to not test an older, less effective version.
I'll give it a try today. My tuners are the older onn 4k boxes. (not plus or pro) We have really struggled to find a way to get them to handle DTV tuning properly.
Is there any point to testing your version "0" config? That version looks to have some syntax issues somewhere.
It was me. I missed the closing bracket when copying...
1 Like
I just added the new Directv script posted and it seems to work really well.
my ONN 4k seems to be handing it with no problem.
Directv seems like a great solid solution.
1 Like
Yeah, I just added @anon38303228 's config to a few channels and tested. It works for me too! Compared to my Roku Bridge Tuner app which was tuning in about 10 seconds, ADBT is tuning the same DTV channels in closer to 6 seconds. 
It looks like I may have to pull the extra onn 4k's back out of storage and put them back into the LinkPi side of my system.
EDIT: Now, the question of the day is: Will we come up against the dreaded "Are you still watching?" prompt when recording back to back programs over several hours?
That was one of the main reasons I had jumped over to the Roku tuners...we needed to send a "keep alive" command every so often.
1 Like
IIRC, the "still watching" prompts are default to 4 hours in the DirecTV app for Android. For comparison, the Osprey boxes don't have this "feature".
Yup. I edited my previous celebratory comment regarding this concern. On the Roku Tuner we are sending a keypress "Enter" just short of every 4 hours. I don't think that we ever managed to get around this on ADBTuner.
I'll give it a try by adding this config to one of my DTV channels and scheduling some back to back recordings which exceed 4 hours total...
Just a general note: It's somewhat important to keep in mind that there is no guarantee that all the commands specified in a tuning configuration will execute. I don't even know if you can execute a script that way on the device via ADB, but if that does work, I wouldn't leave a script running with no guarantee that something will run to clean up.
I don't think you can send key commands that way from the CLI anyway and ADB usage from the local Android device is blocked for security reasons in newer Android versions.
I'm going to push the current beta build of ADBTuner to stable this weekend. Afterwards I will look into adding a configuration option to send a timed command (or set of commands) while a channel is currently being watched. I think that will be helpful with what you all are doing.
3 Likes
Considering this, I may not be too eager to jump into testing this configuration right now. Perhaps it is better to wait until the idea is more refined. Besides, my wife and I have some health concerns which I currently need to focus upon.
That's a clever solution. Watch out though, if ADBTuner restarts, crashes, etc. while streaming there will be nothing to stop that background process from running on the android device.
2 Likes
Hello everyone. As was previously announced, it's time for a new stable release.
For lack of a better name I'm going to call this ADBTuner 2.0.
A new 2.0 tag was added this morning and the stable tag was updated to point to this release.
This is now the recommended version for day-to-day usage.
There are some significant backend changes in this build however everything should be automatically updated as needed on first load. There may be some issues for users that might have jumped back and forth between stable and other builds over the past couple of years. If you run into any please let me know.
Changes since the last stable release:
Switched to a dedicated proxy server that is always running instead of bringing one up for each stream and tearing it down afterwards. This enabled the following:
- Significantly improved control over tuner locking.
- Streams are now kept active for short while after a disconnect so clients can reconnect and continue watching without having to start over. This fixes issues with dodgy network connections and with client apps that retry if the stream doesn't start immediately (Kodi).
- Tuners will now be shared if more than one client app is streaming the same thing. Shared tuners will be locked until the last client disconnects.
Added experimental support for custom tuning configurations. These configurations can be used to define a set of custom ADB commands for applications that don't work with the default standard or compatibility mode options. A web interface for this is provided at /configurations. This feature is still experimental and may change in the future.
Added health check / status page at /up.
Improved playback detection.
Improved profile screen detection clearing (who's watching).
Added more detailed logging. Specifcally around locked tuners.
Added preview window with remote control buttons for each streaming endpoint in the web UI.
Enabled admin preview windows on mobile devices and tablets.
Improved keep alive functionality. This should now work with most applications.
Apps kept awake with the keep alive feature will no longer sit in the foreground. This is preferred as some apps always stream video when they are in the foreground.
By default, all video streams will now start after 20 seconds regardless of if the requested content has started playing. This allows for slow loading content that previously failed if the client connection timed out. The old behavior can be restored by selecting "Terminate Connection" for the "Slow / Failed Tuning Behavior" setting in the admin interface.
Added support for obtaining a deeplink url from a remote endpoint. This can be used by including "dynamic_url_json_key" parameter in the URL. The value should match the key that contains the URL in the json response. This is being used by ESPN+ with Custom Channels via ADBTuner.
Admin UI cleanup, improved navigation, dark mode support, improved mobile device support.
New REST API. Docs at /api/docs.
And finally, there have been many bug fixes since the last release. This version of ADBTuner should provide a better experience overall.
Thank you everyone for testing these builds and for all of your valuable feedback.
10 Likes
Along with ALL the other great improvements...I am very interested in the keep tuners alive for a short time part.
I am wondering if you could make this use a variable so we can SET the amount of time to keep the channel alive. I like to be able to jump back and forth between channels and don't want to have to tell channels to record the channels to keep them alive.
I currently keep my ah4c:appletv channels alive for 15 minutes using some custom scripts. I would love for this to work on my adbtuner/onn/philo channels also.
There is an environment variable (KNOWN_STREAM_DEFAULT_TIMEOUT) if you want to play around with that. The default (measured in seconds) is 3. Edit: There may be a hardcoded max of 40 seconds.