As you probably know, OliveTin is passing through the exact JSON response from ADBTuner, so I'd imagine there is at least a temporary disconnection or other issue.
Could these be Wi-Fi dropouts? Or, is it possible that device is actively being used for a capture and is being falsely reported as not connected?
At the time when the disconnect was reported, it seems that there was some sort of operation happening on that tuner. All tuners show this same series of entries in the log. Though, I have no idea what these entries mean.
2025-07-11 16:09:30.520 - lib.adb - ADB: Connected.
2025-07-11 16:09:30.520 - lib.adb - ADB: 192.168.1.214 - settings list global
2025-07-11 16:09:30.595 - root - adb_allowed_connection_time=0, adb_enabled=1, adb_wifi_enabled=0
2025-07-11 16:09:30.595 - lib.adb - ADB: 192.168.1.214 - dumpsys display
2025-07-11 16:09:30.662 - lib.adb - ADB: 192.168.1.214 - getprop ro.build.version.release
2025-07-11 16:09:30.719 - lib.adb - ADB: Android Version: 12.0.
2025-07-11 16:09:30.737 - httpx - HTTP Request: GET http://192.168.1.161/live/stream3 "HTTP/1.1 301 Moved Permanently"
2025-07-11 16:09:30.739 - lib.adb - ADB: Connecting to device (attempt 1).
2025-07-11 16:09:30.829 - lib.adb - ADB: Connected.
Something else which is odd to me is that the timestamps from the ADBTuner log are off by 12 hours. This error happened at 4:09 AM. The log shows 16:09, which is 4:09 PM, a time we haven't even reached currently.
Since it's been a few months with no major issues, I have merged the experimental branch and pushed new docker images. As of today, :latest, :stable, and :experimental are all the same image.
Please let me know if you run into any issues. The major changes are a more reliable way to detect when playback devices disconnect and the new (optional) /configurations section.
When the status page (/up) is loaded, ADBTuner opens a connection to each device and gets the Android version to confirm the connection is working. This is what you are seeing in the log output.
I added a "[Health Check]" prefix to these log entries in the current version so it's more obvious that these commands are running as part of a health check. It should look similar to this now:
adbtuner-1 | 2025-07-12 12:15:51.118 - server - Device 1: Starting health check.
adbtuner-1 | 2025-07-12 12:15:51.121 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - Connecting to device (attempt 1).
adbtuner-1 | 2025-07-12 12:15:51.268 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - Connected.
adbtuner-1 | 2025-07-12 12:15:51.268 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - settings list global
adbtuner-1 | 2025-07-12 12:15:51.327 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - adb_allowed_connection_time=0, adb_enabled=1, adb_wifi_enabled=0
adbtuner-1 | 2025-07-12 12:15:51.327 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - dumpsys display
adbtuner-1 | 2025-07-12 12:15:51.373 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - getprop ro.build.version.release
adbtuner-1 | 2025-07-12 12:15:51.406 - lib.adb - [Health Check] ADB: 192.168.xx.xxx - Android Version: 12.0.
adbtuner-1 | 2025-07-12 12:15:51.421 - httpx - HTTP Request: GET http://192.168.xx/xxx/ "HTTP/1.1 301 Moved Permanently"
adbtuner-1 | 2025-07-12 12:15:51.421 - server - Device 1: Health check complete.
It should not be a problem if a health check, keep alive command, and/or video playback occurs simultaneously.
During tuning operations, ADBTuner will try to connect to the Android device up to 5 times which might hide an intermittent networking issue. The status page does not do this. I may change the behavior to match in the future, but for now I'm going to leave it as-is. If you run into this issue again, perhaps you can DM me a full log file and I will look into it further.
Docker containers use UTC time by default. You can change this by setting the TZ environment variable.
For example, if you are using Docker Compose you can add the following to your configuration file:
environment:
- TZ=America/New_York
A list of valid timezones is available here:
https://manpages.ubuntu.com/manpages/focal/en/man3/DateTime::TimeZone::Catalog.3pm.html
Are you still running into this issue? Last I checked, Fubo didn't need "Compatibility Mode." I don't know that it will fix your issue, but you might want to try disabling that.
@turtletank Thank you very much! I appreciate your detailed explanations, and continued work and support on this amazing project. I plan to update my ADBTuner image today. If I run into any issues, or have a recurrence of my previous concern. I can let you know and send you log files. Fortunately, in spite of the occasional notifications of disconnects, I have not had any failed recordings.
@turtletank thanks for the update , now the stream closes much faster after stop , great work.
I have been testing Stream Master with adbtuner and Tvheadend and it works even better now with the last update. Channel zap in Kodi from TVh is now down to 5-6 s
I updated to the newly released version today and found none of my channels worked.
Everything worked fine on the previous 'latest' docker image.
The error message is Tuner: Channel configuration not found for channel ID X. Exiting.
(X is the 1 digit sequential channel number for each of the 8 ADBTuner channels.)
I 'fixed' the issue by switching each channel to Compatibility Mode.
My setup is 2 versions of Firesticks - Android 9 and 11 on YoutubeTV.
I just did the update and now channels are failing to tune with 404 Not Found. I'm trying to roll back but couldn't find prior version so using legacy-testing which seems to be working.
Thank you for reporting this.
I think you might both be dealing with the same issue. A database migration should have automatically run during the upgrade to add configurations to each channel, but it seems in your cases it did not.
I need to figure out why this happened, but in the meantime this can be fixed by editing and saving all of the channels in the web interface, choosing "Deep Links" or "Compatibility Mode" in the configuration section as needed. It's important that you save each channel even if you made no changes.
I pushed a small update just now that will attempt to fail safely if a configuration is not set for a specific channel. It won't update your channel configuration, but it will use "Compatibility Mode" if you had previously used that setting on a specific channel, otherwise it will use "Deep Links."
If you run into any more issues please DM me a full log file so I can look into it further. Thanks!
I did notice that when I edited a channel and then saved it the channel would start working. Problem is I have probably around 150 channels and I had family members breathing down my neck. So I thought maybe if I exported the channels then did an import with DELETE that would fix it but it did not. So I switched to legacy-testing container and that seems to have helped but I have not validated everything. So much for the idea of sneaking in an update between family viewings. I will do some further testing early tomorrow morning before anyone starts watching. I did also notice some of the YTTV base channels that I have using for a long time did not have an issue. But recently I have added more YTTV channels for MGM+ and StarZ which were definitely not working. Something to look at when I am having my early morning coffee tomorrow.
When looking through the ADB Tuner interface, i noticed that the default setting under configurati9on was set to deep link recommended. If you have channels that use compatibility mode, you have to go in and make the change and hit save.
I use the setting when using the Fubo app.
If you use YTTV, all should be good as long as a valid subscription exists.
I updated early this morning and had all of my channels failing as others had reported. I pulled the latest image and re-deployed this evening. I have tested previews on both YTTV and Peacock channels, and all seems to be working now. There are a couple recordings scheduled overnight. Hopefully, they'll record without any issues.
I am back running on latest successfully. I had a channel export from the 8th since I do an export anytime I make channel changes and save with timestamp. I decided to stop and delete the container them removed everything from the config directory except the adbkey's. Then installed with latest, added the tuners back manually and imported the channel export from the 8th. Everything was good except I needed to set a few channels to compatibility mode. Tested and all working except my 2 paramount showtime channels which have been a separate issue. I exported my channels again then did the same process on a 2nd server but this time imported the new channel export. Everything came in correct including the channels that were set to compatibly mode. It was relatively painless process so I chose to start with a clean install. Thanks for such a great piece of software. It is the cornerstone to my CDVR setups.
As a follow on, I still have a problem tuning my 2 Paramount+ Showtime channels using deeplinks in compatibility mode with the Paramount app. I don't get past the user selection screen. The logs show detecting text edit and profile but it does not send an enter to get past this. I'm thinking maybe this text sequence may be something you are not catching. @turtletank Is this something you could look at?
Here are the logs;
2025-07-13 14:17:55.480 - server - Tuner: Cleanup complete. onn4k01 (Showtime East)
2025-07-13 14:17:55.549 - lib.adb - ADB: 10.1.3.42 - pidof com.cbs.ott
2025-07-13 14:17:55.609 - root - Using https://www.paramountplus.com/live-tv/stream/showtime-east/ to load channel.
2025-07-13 14:17:55.610 - lib.adb - ADB: 10.1.3.42 - input keyevent KEYCODE_MEDIA_STOP
2025-07-13 14:17:55.685 - lib.adb - ADB: 10.1.3.42 - am force-stop 'com.cbs.ott'
2025-07-13 14:17:55.794 - lib.adb - ADB: 10.1.3.42 - sleep 2
2025-07-13 14:17:57.843 - lib.adb - ADB: 10.1.3.42 - am start -W -a android.intent.action.VIEW -d 'https://www.paramountplus.com/live-tv/stream/showtime-east/' 'com.cbs.ott'
2025-07-13 14:18:03.205 - lib.adb - Checking for profile screen
2025-07-13 14:18:03.721 - lib.adb - H264 video with a short GOP (1-3 seconds) is highly recommended. Other configurations will result in tuning delays.
2025-07-13 14:18:04.896 - lib.adb - Checking for profile screen
2025-07-13 14:18:05.424 - lib.adb - H264 video with a short GOP (1-3 seconds) is highly recommended. Other configurations will result in tuning delays.
2025-07-13 14:18:06.625 - lib.adb - Checking for profile screen
2025-07-13 14:18:08.293 - lib.adb - Checking for profile screen
2025-07-13 14:18:09.135 - lib.adb - On screen text: "[nate iatetel a edit, profiles".
2025-07-13 14:18:10.138 - lib.adb - Checking for profile screen
2025-07-13 14:18:10.821 - lib.adb - On screen text: "edit, profiles".
2025-07-13 14:18:11.824 - lib.adb - Checking for profile screen
2025-07-13 14:18:12.585 - lib.adb - On screen text: "a edit, profiles".
2025-07-13 14:18:13.587 - server - Tuner: Stream released after 18.3 seconds. Display was on, application (com.cbs.ott) was running.
2025-07-13 14:18:13.587 - lib.adb - ADB: Closing connection - 10.1.3.42
No I do not have any guide offsets. I do set the gracenote ID on all my channels. Takes awhile to find them sometimes. I am in eastern timezone.
Do your Gracenote ID's persist through the export/import process? I have been matching mine up through the Channels DVR source "Manage Lineup" interface. Perhaps including those ID's in the ADBTuner setup might be better...
Yes my gracenote id's did persist on the import and they are included in the export files.
Thanks for the logs and other information. I pushed an update just now that adds some logging around database schema and a one-time fix for this specific issue. Can you please update and let me know if your issue has been resolved? If it isn't fixed, if you could share the logs from when ADBTuner starts up that would he helpful.
Thank you for pushing through this. You shouldn't have had to do all of that, but it was helpful in determining what the actual issue was. I will take a look at Paramount+ when I have a moment.
I changed all the channels from compatibility to default to replicate my system and then I did the update. No issues opening channels.
Some more testing. It does not release tuners not in use which was an issue I saw before. Nothing obvious in the logs, but I'll send you what I have. Switching back to compatibility and restarting seems to cure tuner release issue for me.
