Default stream timeout value configurable?

[GTFan]

Is there any way to change the default stream timeout value in the DVR? We have a new source program called Prismcast here that's a replacement for the Chrome capture for channels project (CC4C), and it's a little slow to deliver video to channels when either live or a recording starts. It's right on the edge of the stream time out for channels, so it randomly works sometimes and not others.

That's normally ok because channels will retry but I have those channels configured in a couple of sources, so if channels times out on the first source (Prismcast) it will switch to the backup. The problem is I don't really want to use that backup source much because of hardware stream limits. I only have a couple of provider STBs that I'm sourcing from via HDMI capture, but I could have up to 10 streams running in Prismcast if I can get them to reliably work with a little longer timeout value.

[chDVRuser]

Perhaps PrismCast can be modified to return a HTTP Status Code until the video is stabilized that will cause Channels DVR to retry the connection.

Not sure how Channels DVR reacts to these?

408 Request Timeout - The Server could not Respond in Time. The client should retry the request, properly following the time requirements specified by the Retry-After header field or a Retry-After response header or by a server specified elsewhere in the body of the response. If Retry-After header is omitted, the client can retry immediately, but no earlier than Retry-After time.

503 Service Unavailable – The server is temporarily unable to handle the request due to maintenance downtime, overloaded servers, or other reasons.

619 Request Time-out – An uncaught exception, timeout, or other technical problem occurred which prevented further processing of the request. The response message body will usually include more details about the problem.

[eric]

What timeout are you referring to? We have lots of different timeouts. In general, no, we can't adjust the timeouts beyond what we already have. They are tuned to make the entire system behave properly, within reasonable bounds, but I don't know exactly what it is that you're referring to based on your description so far.

[GTFan]

The 10 second or so time out when channels cannot get a video stream from the tuner source, when you either bring up a live channel from the guide or start a recording. When you hit that time out you switch to an alternate source for the channel if you have one.

If I could config this to 20 seconds I could work around the current prismcast issue.

[eric]

What is the actual error you're seeing? Do you have logs, diagnostics or a screenshot?

[GTFan]

It's not a real error Eric it's just a simple timeout where channels gives up because it's not getting a video feed from the tuner source. It then switches to the backup source which is fine, but I don't really want that.

Looks like the timeout is 14 seconds.

2026/02/05 06:00:00.178866 [DVR] Starting job 1770289200-122 Eyewitness News This Morning at 6:00am on ch=[7000 6002]

2026/02/05 06:00:14.180838 [ERR] Failed to start stream on channel 7000 via M3U-Prismcast: M3U: Could not fetch playlist from localhost:5589 (Timeout): Get "http://localhost:5589/hls/abc/stream.m3u8": net/http: timeout awaiting response headers

2026/02/05 06:00:14.193018 [TNR] Opened connection to M3U-LocalChannelStreamlinks for ch6002 ABC

And yeah I know the easy answer is just to remove those channels from the backup source so that channels will retry from prismcast but it's still a work in progress so I'm a little reluctant to do that right now.

[eric]

No, we will not increase the length of the timeout for web servers to respond to HLS requests beyond the 15 seconds it is currently at. These timeouts have been tuned to provide a good over-all experience and have interactions between various parts of the system.

Many client implementations (Safari, etc) have a hard timeout of 2 seconds for these responses. The server is going to need to come up with a strategy to be able to respond to those requests quicker including potentially sending some initial stock video data.

[GTFan]

I agree, thanks for your comments. Was just asking the question.