Increase timeout when tuning IPTV mux

Chris M

Wondering if this is a configurable setting, or possibly a bug.

For context, I have an IPTV stream that takes a very long time (30-60 seconds) to begin sending data. I'm currently using Streamlink with the pipe:// function in TVheadend to pipe the stream into TVHeadend. I have configured the Network to have a maximum timeout of 120 seconds.

When I initiate a scan of the mux, everything works as expected - Streamlink takes between 30 and 60 seconds to begin sending data and TVHeadend successfully creates a service, however, whenever I try and play the service or mapped channel, TVHeadend kills the stream after roughly seconds. In the logs I can see the following:

2023-06-20 18:19:13.042 webui: Stop streaming /stream/service/dfdf9b625b2637e57eb3b16479e14076?ticket=cf043d04d0aea33811d20c5107d107e181ada2f9, timeout waiting for packets

2023-06-20 18:19:13.042 subscription: 00F5: "HTTP" unsubscribing, hostname="::ffff:158.51.112.20", username="admin", client="libmpv"

1. Is this the expected behavior?
2. If this behavior is expected, is there any way to increase this timeout?

John Woznack

I believe the setting you want is: Configuration > BVB Inputs > Networks > Edit Network > Advanced Settings > Maximum timeout (seconds)
Past that, I'm not sure there's a configuration parameter for the timeout for "waiting for packets". (At least I haven't noticed one anywhere.)

Chris M

Thanks for the suggestion, indeed that is the setting I set to 120 seconds. After I did that I was able to successfully scan the mux, but when trying to tune the service I hit the "timeout waiting for packets" after about 20 seconds.

davep

There is a hard-coded 20 second timeout in src/webui/webui.c line 342 which you may be hitting.

Chris M

Dave Pickles wrote:

> There is a hard-coded 20 second timeout in src/webui/webui.c line 342 which you may be hitting.

Ahh crap, that pretty much lines up with that I'm seeing.

So basically, yes - this is expected behavior then and no way to override it.

Thanks for pointing me to the line in the code, I might try building my own binary to work around this.

Chris M

100% that was it, bumped that number to 120 seconds, compiled my own version and I'm now able to stream the 'problematic' sources.

To me it makes sense to align this number to the number defined in the MUX config. If that makes sense to anyone else I might try to put together a PR

Jonas Lang

If you feel it may help others at some stage it would make sense to to put in a PR. The 20 second limit may have just been an arbitrary figure decided on at coding stage. If not I’m sure someone will explain why it was chosen.

lbschenkel

Apologies for the late bump, but I have been frustrated by this as well and I have created a PR: tvheadend/tvheadend1736

You can test it by using the Docker image at: users/lbschenkelpackages/container/package/tvheadend

There's a new streaming profile setting that controls the start timeout separately from the "regular" timeout.
In this way you could have a low-ish timeout at the network level, and a profile start timeout large enough to allow cycling through all the services before giving up.

Any feedback is appreciated.