I've seen this scenario with watching live tv as well. The timing you mentioned is the same in my experience. I haven't found a solution and have had the issue since I updated to the 2.0 releases back in Dec. timeframe. I was most likely on a 1.X build previously though I don't have any idea which one.
I am currently running today's Dev version but not long enough to say if the problem still occurs or not.
I've added this variable and will monitor to see if the behavior changes.
@turtletank The one thing I noticed that's different from my implementation, and I'm not sure if it's intentional, is when the encoder is warm and functioning and transmitting packets, it seems to take a second longer to tune than it normally would. Obviously I can't tell what's happening from the inside, but it almost seems like it's sending null frames unconditionally, instead of maybe waiting a few hundred milliseconds, checking for connectivity and then sending the frames. It's just a thought that might improve reliability to send them kind of conditionally if they're even needed. I don't know if that's how you have it architected, but that was how I kind of built out my implementation.
I'm wondering if maybe you're looking to do more with it, like using it for recovering a session, then that would make sense. But I just figured I'd mention it as something I noticed, just in case it's unintentional.
From my testing the flag doesn't seem to cause any adverse effects, and it makes the stream so much more resilient.
The experimental proxy server effectively has two modes. It is either passing data from the upstream device or sending null packets. It switches between these modes as needed (initial tuning, endpoint connection failures while streaming).
During tuning operations, null packets are sent by default until ADBTuner determines that tuning is complete (regardless of the upstream's status).
This is to support ADBTuner's default configurations which hide the tuning process from the viewer. This was previously done by delaying the initial HTTP response. This change allows for much longer (hidden) tuning operations as we are no longer trying to beat the clock before the video player gives up and times out. I wouldn't expect there to be a significant difference in timing with the default configurations.
At the moment, the configuration options "use_fixed_delay" and "fixed_delay_seconds" are bugged (basically ignored) when the experimental proxy is enabled (MPEG_NULL_PACKETS=True). Are you using a configuration with a fixed delay?
I'm hoping to keep every tuning operation on the same path (null packets first) because it's cleaner that way. But when finished it should trigger the switch sooner when the fixed delay is set to 0. This should hopefully eliminate most of that extra second.
The logging around this is currently very verbose. It should indicate exactly when the proxy switches between null packets and passing data normally.
Yes I was using a fixed delay of 0 seconds as the Osprey boxes wake and tune right away. That was the lag I was seeing. I guess because it was ignoring that delay I noticed more tuning time than usual.
Should that colon be there
TAG=development
DOMAIN=local
HOST_PORT=5592
HOST_VOLUME=adbtuner_config
KNOWN_STREAM_TIMEOUT_DEFAULT:=10
Sorry, yes that's an alternate syntax for yaml files, but OliveTin uses equal signs. So, to match the way we do it in Project One-Click, create an environment block in the yaml (between ports: and volumes: to stay consistent with other P1C yamls):
environment:
- KNOWN_STREAM_DEFAULT_TIMEOUT=${KNOWN_STREAM_DEFAULT_TIMEOUT}
And this to the env vars section:
KNOWN_STREAM_DEFAULT_TIMEOUT=10
Once I hear from a few more people that this is the solution, I'll modify Project One-Click to include a field for this variable from the start.
EDIT: Fixed incorrect env var name.
I think it might be accidentally flipped in a few posts in this thread, but itās KNOWN_STREAM_DEFAULT_TIMEOUT.
This is how long a long a tuner stays locked and available to continuing watching after data stops streaming though the proxy for that channel.
The issue at hand here is that it seems that some players and DVRs temporarily stop streaming data for multiple streams when one is disconnected which releases the tuners related to those streams.
This will default to 8 seconds in the next version of ADBTuner. 5 seconds is probably ok in most situations, 10 might be a bit overkill, but if someone has enough tuners that the wait isnāt an issue it canāt hurt.
Every second counts around here lol so I was hesitant to increase that by default if it isnāt necessary for everyone.
Thanks. I copied that from a previous post by someone else, so I'll adjust mine just above.
The current development build (20260423-1) adds support some new configuration command types.
"tune_commands": [
"adbtuner_open_app '||TARGET_PACKAGE_NAME||'",
{
"ADB_LOOP": {
"iterations": 10,
"commands": [
"input keyevent KEYCODE_DPAD_DOWN",
"sleep 2"
]
}
}
]
"adbtuner_open_app '||TARGET_PACKAGE_NAME||'" does what you probably think it would do. It opens the target app.
When I added the keep alive feature I found that adb shell monkey -p didn't work for every app. So I added a helper function to ADBTuner that dumps the target package to figure out which action to use. This change makes this functionality available to configurations.
The ADB_LOOP command type provides a simple syntax for repeating a set of commands multiple times. I find this syntax is cleaner than sending a full shell command to the device for this purpose. More importantly, using this feature allows ADBTuner to intercept any sleep commands and process them on the ADBTuner side as that provides more accurate timing. It's also necessary to make adbtuner_open_app work in a loop if needed.
The example configuration above will open the target app and then press down 10 times (waiting 2 seconds between each key press).
I ran most of the day yesterday with KNOWN_STREAM_DEFAULT_TIMEOUT set to 10. Pressed my system harder than normal and did not experience any times where the stream closed unexpectedly and drop to the Firestick Home Screen. So, this appears promising.
Based on turtle tank's feedback I've dropped the timeout from 10 to 5 for today and will test further.
I appreciate you taking the time to test this out. Thanks.
Open Box Onn 4K, $38, few back in stock if anyone needs one. 13 available at time of this post.
Edit: showing 106 now in stock.
Made those changes and so far it's good. I'll know more tonight as Iāve set a couple of things to record. If those games record all. I'll probably leave it at 10 secs for today and tomorrow then drop to 8 secs for the weekend games. Tuner availability isnāt really an issue at this point.
The awesomeness of ws-scrcpy is now available for ADBTuner -- in the form of a companion container. More here:
That is possibly the best feature of ah4c so thank you so much for implementing this. That is really cool.
No issues so far with using a value of 5.
I pushed an update to the development version (20260425-1) this morning. It's mostly just some cleanup and refactoring.
Notable changes:
check_for_and_clear_whos_watching_prompts. This is now defined via tune_match_text_commands.Please let me know if you run into any issues.
Hi all. I have this set up and works great when I click the PREVIEW link inside of ADBTuner on a channel. I have it set up with YTTV. However, when I insert the M3U url into Channels DVR, I always get this error.
Does anyone have any idea why this happens and how to fix? I have read it happens when there are too many channels, but I literally have 3 as I am still testing it out.
HELP! (please!)
