Recordings ending early fix by adjusting “delay_max” setting

[iiiJoe 55]

Emby team, I’m trying to understand the thinking behind the adjustment for the “delay_max” setting on the upcoming 4.8 release. Per @Lukethe new setting will be “4” (apparently the “delay_max” setting has never been used in Emby) which will cause Emby (ffmpeg) to try reconnecting a failed recording stream 3 times for a total of 4 seconds. While, as stated in the article, the recommended setting is “127” which will cause Emby to try reconnecting 8 times for a total of 4 minutes 11 seconds. Which is my official request. If my math is off please correct me. Why would we limit Emby to 4 seconds of retries when it could be over 4 minutes?!? This would GREATLY increase the reliability of recordings, which up to now has been completely reliant on a stream that HAS to be literally perfect. Hats off to @BoomerGamer62for sleuthing this article in Intrasonics outlining this much needed fix: https://medium.com/intrasonics/robust-continuous-audio-recording-c1948895bb49
If anyone is interested in the history behind this issue:

https://emby.media/community/index.php?/topic/114486-recording-ended-early/
 

https://emby.media/community/index.php?/topic/115240-recordings-ending-early/

[Luke 37119]

Hi, yes more options are certainly possible. Thanks.

[iiiJoe 55]

36 minutes ago, Luke said:

Hi, yes more options are certainly possible. Thanks.

Thanks for responding. Is there a technical reason why you would not just set the delay_max to 127 instead of 4? I'm sincerely trying to understand why you wouldn't let Emby work at 100% to re-establish failed connections, especially on recordings.

Edited September 14, 2023 by iiiJoe

[Luke 37119]

I think the best default (for most in general), is something on the lower side.

 More options are always possible to control it.

[iiiJoe 55]

I can understand that. But I'm not comprehending this setting being at 4 when we know that means that the re-tries will terminate after 3 seconds. Per the Intrasonics article: "So we have a pattern that goes from 0, 1, 3, 7, 15, 31, 63, 127". "8, will always terminate after it reaches the 7 second delay". I've been using Beta and 4 did not prevent failed recordings. 3 seconds of re-tries is just not long enough.

[Luke 37119]

9 hours ago, iiiJoe said:

I can understand that. But I'm not comprehending this setting being at 4 when we know that means that the re-tries will terminate after 3 seconds. Per the Intrasonics article: "So we have a pattern that goes from 0, 1, 3, 7, 15, 31, 63, 127". "8, will always terminate after it reaches the 7 second delay". I've been using Beta and 4 did not prevent failed recordings. 3 seconds of re-tries is just not long enough.

Our retrying system is multi-faceted but within that single ffmpeg process and then again after we close it, so it's not that simple. Also, these values that we're playing with are generally for dealing with timeouts and things of that nature. If I recall, your streams stop for a different reason, which means that increasing this value isn't your solution. That's why since you're on the beta, please use the testing area for beta related discussion and let us know how things are changing once in a while as new builds come out, making sure to provide log examples, and then we can look at your specific issue in detail. 

[iiiJoe 55]

56 minutes ago, Luke said:

Our retrying system is multi-faceted but within that single ffmpeg process and then again after we close it, so it's not that simple. Also, these values that we're playing with are generally for dealing with timeouts and things of that nature. If I recall, your streams stop for a different reason, which means that increasing this value isn't your solution. That's why since you're on the beta, please use the testing area for beta related discussion and let us know how things are changing once in a while as new builds come out, making sure to provide log examples, and then we can look at your specific issue in detail. 

Thank you for the response. I’m currently operating 3 different Emby servers (one of these being Beta) on 3 seperate computers utilizing 2 seperate client android servers. I have only seen Emby re-try on a recording when the recording is being initialized/ making the initial connection. I have NEVER witnessed Emby/ ffmpeg re-try when a recording ends prematurely on ANY error, http 5**, 4** or otherwise. The exception being the changes you made to Beta on June 5th, which I very much appreciate. And it does retry, but only for 3 seconds. I have NEVER witnessed a successful re-connection during those 3 seconds. And I record several shows almost daily. Approx 80% of my failed recordings are due to “http 5** / 4** errors. The other 20% are “media sequence changed unexpectedly” which are almost always sports related. This means that a majority of my, and likely many others, failed recordings can theoretically be cured with a delay_max setting that lasts long enough to actually have a chance to re-connect. The delay max value of “127” was no doubt built into ffmpeg for good reason. This provides over 4 minutes of re-tries. I understand this may need some adjustment to work with various platforms like Emby, if there’s a re-try system in place, to prevent redundancy but I have seen no evidence at all of Emby trying to save a failed recording and I’ve been sleuthing this issue now for well over a year. If there’s a feature of Emby that I’m missing that will activate this retry system please show me. If not, can we please address specifically why the delay_max value shouldn’t be at “127”? 

[Luke 37119]

HI, yes we are continuing to work on improving it. Thanks for the feedback.