Reconnect Strategy Not Disclosed, Settings Unclear - Exponential Backoff, Hardcoded Values

[Kaszanas]

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

Other

OBS Studio Version (Other)

30.0.0

OBS Studio Log URL

No Log

OBS Studio Crash Log URL

No response

Expected Behavior

One could think that changing the advanced settings for "Automatically Reconnect" would lead to a defined behavior understood by the users:

Yet it is not clear from the UI that the reconnect strategy that is used is called "exponential backoff" which multiplies the "Retry Delay" setting between each reconnect attempts (user is unaware of the change which is not disclosed). Currently settings imply a "polling" strategy. This is because the "Retry Delay" is set by the user explicitly.

Hardcoded exponential backoff settings? https://github.com/obsproject/obs-studio/blob/762e0502f2ad67a6330283d10674c7b133eb1a15/libobs/obs-output.c#L30-L31

Exponential backoff implementation? https://github.com/obsproject/obs-studio/blob/762e0502f2ad67a6330283d10674c7b133eb1a15/libobs/obs-output.c#L2710-L2735

Current Behavior

User Is unaware of the changing delay between each of the reconnect tries.

Steps to Reproduce

1. Disconnect from the internet and observe the time to reconnect

Anything else we should know?

This is clearly a UX issue that should be fixed or communicated better to the users. I have seen multiple instances where people do not know what these settings actually do.

• https://obsproject.com/forum/threads/obs-takes-to-long-to-reconnect-after-internet-downage.164378/
• https://github.com/obsproject/obs-studio/issues/8335

[Fenrirthviti]

We're aware of all this, but this post doesn't seem to provide any kind of proposed solution. Communicating these settings in a succinct and clear way to users is extremely difficult. Adding incremental delays when the reconnect fails is fairly standard and isn't directly communicated outside the UI showing the timer increasing each time. Do you have any suggestions or examples from other programs that communicate similar concepts? At the moment, this doesn't feel like a bug report, but an unactionable feature request.

[DmitriyFrogo]

Now I know why my OBS very rarely fits in Twitch's 90-seconds reconnection time limit As user I expect that OBS have 90 tries every 1 second, for example (or 45/2, or 30/3), like in ping tool

any kind of proposed solution

Why just don't reconnect X times every N seconds as UI says? I undestand for what this part of the code - protection against network overload / DDoS / etc., but it's hard for me to imagine a person who would use OBS as DDoS tool If I'm right, then easier to hardcode minimum of time to retry for like 5 seconds per try

Adding incremental delays when the reconnect fails is fairly standard

Not all standards are worth using, especially if they cause harm or illogical behavior

https://en.wikipedia.org/wiki/KISS_principle

[Kaszanas]

We're aware of all this, but this post doesn't seem to provide any kind of proposed solution. Communicating these settings in a succinct and clear way to users is extremely difficult. Adding incremental delays when the reconnect fails is fairly standard and isn't directly communicated outside the UI showing the timer increasing each time. Do you have any suggestions or examples from other programs that communicate similar concepts? At the moment, this doesn't feel like a bug report, but an unactionable feature request.

How I would try and do it:

1. Similarly to how it is on some other pages have a short description of what is the strategy, e.g. "Note that each reconnect failure extends the waiting time for next reconnect by <number>. Settings for the exponential backoff reconnection strategy. ", or something along these lines. Example from another UI piece below (actionable):

2. Implement a dropdown for the retry strategy and have a polling listed as a special case of the exponential backoff (with value validation so that people cannot mass retry too fast)

Important question would be if there are some issues that could arise on the side of the platforms if polling is used? There are probably multiple disconnection scenarios.

[Fenrirthviti]

The current strategy is largely informed by requests from streaming platforms, and in part to avoid spam retrying with low timeframes, which can cause further issues.

[DmitriyFrogo]

While your Internet is not working, it's not reconnecting to anything (and you DDoS only your router maybe), but reconnection delay increases So, if your Internet starts to working, delay can be more than user set up in UI

easier to hardcode minimum of time to retry for like 5 seconds per try

Even if you hardcode minimum retry delay to 10 seconds, it will be better than what we have now

[Kaszanas]

The current strategy is largely informed by requests from streaming platforms, and in part to avoid spam retrying with low timeframes, which can cause further issues.

@Fenrirthviti If that is the case, then a simple tooltip/description is the solution. Currently settings imply full control over the retry logic parameters. Similarly if streaming platforms wish to have less reconnect retries with low timeframes then it could be viable to set a minimal threshold of 5-10 seconds in the polling strategy (hence the dropdown strategy idea with different hardcoded minimum values for strategies).

Anyway, someone with enough knowledge is still able to compile OBS with modified logic and spam retires. Personally I'd start with the easies way to "fix" the misunderstanding that users have with the UI, and think of a long term and featureful solution for later.

@DmitriyFrogo

While your Internet is not working, it's not reconnecting to anything, but reconnection delay increases

I think that would depend if the outage and disconnect is caused by the client or the platform.

[Fenrirthviti]

I think a tooltip is certainly fair. I defer to @Warchamp7 on how best to communicate this.