In OBS, enable Automatically Reconnect, then set a positive Retry Delay and a finite Maximum Retries. The delay is the first wait, not a fixed interval: OBS doubles the wait after each retry.
There is no India-specific delay or retry count officially recommended in the sources reviewed for this guide. Choose settings to suit the interruptions your connection actually has, and check whether bitrate, Wi-Fi, equipment or the route to YouTube is causing the disconnections in the first place.
Find the reconnect controls in OBS
Open OBS and look in its streaming output controls for Automatically Reconnect, Retry Delay and Maximum Retries. The precise location can vary by OBS version and output mode, so if the labels are not where you expect, check the streaming or output settings rather than looking for a special India profile. The OBS interface includes these controls; the OBS output reference documents how reconnecting behaves.
Before changing settings, note what is selected now. That gives you a baseline if you are troubleshooting a stream that has already been dropping. If you change several unrelated settings at once, it becomes harder to tell which change made a difference.
Reconnect settings apply to OBS’s response after a connection loss. They do not change the quality profile that you send to YouTube, and they do not guarantee that the stream will resume. Keep the distinction clear: retry behaviour determines whether OBS tries again; encoder and network settings affect whether it can maintain a usable stream.
If you are still getting familiar with OBS as a YouTube encoder, our guide to what OBS does well for YouTube Live puts these controls in the context of the wider streaming setup. You do not need to replace OBS to make reconnect attempts, but you do need to know where the output controls are in your version.
Enable Automatically Reconnect
Turn on Automatically Reconnect so OBS attempts to restore the connection after it detects a drop. This is useful when an interruption is brief: you may not need to notice it immediately and reconnect by hand. It is a recovery behaviour, not a way to prevent the original interruption.
Check the setting before a planned broadcast, particularly if you have changed output modes or updated OBS since the last test. A checkbox that is off will leave you relying on manual recovery even if you have set a delay and retry limit elsewhere. Once it is enabled, confirm that the other retry fields are usable and not set to disable reconnecting.
A reconnect can only work if the network becomes available again and YouTube accepts the incoming stream. If your internet connection stays down, OBS cannot send video. If the encoder configuration, stream key or YouTube ingest connection is not accepted, repeated attempts may not solve the underlying issue. Watch the YouTube Live Control Room as well as OBS when testing, because the two views can help distinguish an OBS retry from a healthy stream received by YouTube.
For a channel that loops a recording, recovery is only one part of the operating plan. The practical differences between local encoding and a hosted loop are covered in how to make a 24/7 silent study-room stream; whichever approach you use, test the complete chain rather than assuming a reconnect checkbox covers every failure mode.
Set a positive delay and a finite retry allowance
Set Retry Delay to a positive value and choose a Maximum Retries allowance that gives a temporary connection problem room to clear. A retry count of zero disables reconnecting according to the OBS output reference, so zero is not a useful choice if you expect OBS to try again automatically. Avoid treating any particular count or delay as a universal preset: official documentation describes the mechanism, not a recommended setting for every Indian connection.
The two fields solve different parts of the same process. Retry Delay is the initial pause before an attempt; Maximum Retries limits how many attempts OBS will make. The retry count is not a promise of a particular recovery time, because each successive wait becomes longer. Nor is a larger retry allowance a substitute for a stable connection.
If your connection sometimes pauses briefly and returns, allowing more attempts may give OBS time to recover without your intervention. If an outage is long or recurring, more attempts can merely extend a period in which the stream is absent. A smaller allowance may make it more obvious that manual attention is needed, but it also means OBS can stop retrying sooner. Make that trade-off deliberately and observe how the connection behaves during a representative test.
Do not choose the settings by guessing what is normal for India. A wired fibre connection in one home, mobile data in another, and a shared office network can behave differently. Location alone does not tell you how often your connection drops, how long an interruption lasts, or whether the cause is inside your home network or upstream.
Understand the doubling retry wait
OBS doubles the retry wait after each attempt to avoid overloading services. That means a delay entered as the starting wait does not remain the interval between all retries. If the first wait is D, subsequent waits are based on successively doubled intervals: D, then 2D, then 4D, and so on. This describes the pattern, not a recommendation for what D should be.
The effect matters when you decide whether your retry allowance is enough. A few attempts can cover progressively longer pauses than a fixed-interval retry schedule, but the total elapsed time can grow quickly. You should not multiply the starting delay by the retry count and assume that is the whole recovery window; account for the increasing intervals and for time taken by connection attempts themselves.
For example, the useful question is not “What number do people in India use?” but “How long do the interruptions I actually see tend to last, and how long do I want OBS to keep trying before I intervene?” If you do not yet know, run a test and record when drops happen and whether OBS reconnects. A short observation period is more informative than importing someone else’s preset from a different ISP, location or access technology.
Repeated retries can also produce a misleading sense that the stream is being looked after. They only tell you OBS is attempting recovery. Check whether YouTube shows the stream as healthy after it reconnects, and whether audio and motion have resumed as expected. If OBS stops retrying, or the stream reconnects and drops again, focus on the pattern and cause rather than raising the retry count indefinitely.
Choose settings for the connection you have
Start with the connection and broadcast you will actually use. Measure sustained upload performance at the location and time you plan to stream, then choose an encoder bitrate that leaves room for variation. A speed-test result is a snapshot rather than a guarantee of sustained performance; a busy household or changing mobile signal can make the available upload differ during a long broadcast.
OBS’s troubleshooting guidance offers 75% of total upload speed as a starting point for bitrate selection. Treat it as a starting point, not a guarantee, a universal formula, or a special rule for India. YouTube also advises choosing a quality that can be supported reliably by your internet connection. Its live encoder settings guidance gives bitrate recommendations by codec, resolution and frame rate, so compare like with like rather than borrowing a number without its video settings.
For instance, YouTube’s current guidance lists different recommendations for 480p, 720p and 1080p H.264 at 30 frames per second. These are encoder guidance figures, not measurements of what a particular Indian connection can sustain. If your upload is unstable or has little headroom, lowering resolution or bitrate can be more useful than asking OBS to retry harder. The trade-off is visible quality: a lower bitrate may reduce detail, but an overambitious setting can produce dropped frames or disconnects.
| What you are comparing | What to check | What it tells you |
|---|---|---|
| Connection headroom | Sustained upload at the streaming location against the selected bitrate | Whether the encoder is asking more of the connection than it can consistently provide |
| Local link | Wired Ethernet or Wi-Fi, and whether the issue changes when wired | Whether the connection between the computer and router may be contributing |
| Video settings | Codec, resolution, frame rate and YouTube’s matching encoder guidance | Whether the selected stream quality is appropriate for the available upload |
| Retry behaviour | Whether typical interruptions clear before OBS uses its retry allowance | Whether your chosen wait pattern is suitable for brief interruptions |
If you use Wi-Fi, try wired Ethernet where practical. OBS recommends a wired connection for streaming because Wi-Fi can be unstable. A cable can remove variability in the local wireless link, but it cannot fix ISP congestion, a poor route beyond your router or an outage at the provider. Use a cable with the right connector and enough length for your setup; it is an optional test, not a guaranteed remedy.
For a planned 24/7 loop, test for long enough to include the conditions under which you expect to run it, not only a quick launch check. Use representative audio and motion, and watch YouTube’s stream-health messages. The YouTube guidance recommends testing with content similar to the intended broadcast and monitoring stream health. A static image or silent test may not expose problems that appear when the real content has motion or continuous audio.
Investigate the cause of disconnects
When OBS reconnects, note the time, the message it shows and what YouTube reports in the Live Control Room. Look for a pattern: does the stream fail during a particular time of day, after other people start using the connection, or when the computer changes networks? A short log of observations can help you distinguish a brief interruption from a persistent upload problem without assuming which ISP or technology is at fault.
If you see dropped frames, first consider whether the chosen bitrate exceeds what your connection can sustain consistently. Reduce bitrate or output quality for a test, then compare the result under similar conditions. Reconnect settings cannot compensate for a stream that repeatedly overwhelms the available upload. For examples of why bitrate depends on the exact video format, see our YouTube Live bitrate guide for 1080p at 30 fps; use it as format context, not a substitute for measuring your own connection.
Check the local network in manageable steps. If you are on Wi-Fi, test Ethernet if available. Inspect cables and router or modem connections, and make sure network drivers are current. OBS also identifies VPNs, security software, network drivers, routers, modems and cables as possible troubleshooting areas. Avoid changing all of them at once; change one thing, run a comparable test, and record whether the symptoms change.
If the local link looks sound but drops continue, contact your internet provider and describe the pattern and the times you recorded. The issue may be congestion or a route problem outside your home. Do not infer that a provider is unsuitable from one failed test, and do not rank providers based on another viewer’s settings: the evidence needed is performance at your location on the service and plan you actually use.
OBS documents some further network troubleshooting options, including network optimisations and TCP pacing on Windows. It also describes testing IPv4-only as a troubleshooting step, then returning to the default IPv4/IPv6 configuration if that test makes no difference. Treat such changes as diagnostic experiments and follow the current OBS instructions; do not make advanced network settings your first response to an ordinary drop.
Dynamic bitrate, where available and configured, can lower bitrate during congestion and may help keep a connection going at reduced quality. That changes the picture rather than repairing the network. If quality falls or drops continue, investigate the underlying connection instead of assuming the feature has solved it. Likewise, changing the YouTube ingest endpoint should be a deliberate troubleshooting step, not an India-specific adjustment; use OBS’s maintained YouTube configuration and current official guidance when you have a reason to test it.
Keep reconnect separate from YouTube ingest settings
Reconnect controls do not decide whether the stream is encoded and delivered in a format YouTube accepts. YouTube’s encoder guidance covers ingest protocol, codecs, bitrate, keyframe interval and other settings. Keep those compatible with the current requirements, and avoid changing them simply because OBS lost its connection. YouTube recommends RTMPS for encrypted delivery; the separate guide to switching a YouTube encoder from RTMP to RTMPS explains that protocol change without treating it as a reconnect fix.
When testing, confirm both sides: OBS should show a connected output, and YouTube’s Live Control Room should receive a healthy stream. If OBS is connected but YouTube reports a problem, investigate the ingest or encoder message shown there. If OBS itself reports a network disconnection, focus first on the path between your computer and YouTube. This distinction narrows the troubleshooting without promising that one setting will resolve every failure.
A 24/7 channel also needs a plan for cases that retries cannot cover: a power cut, a computer shutdown, an extended outage, or a stream rejected by YouTube. Reconnect can help with a temporary interruption while OBS remains running; it does not keep a switched-off computer broadcasting. For that specific pain of leaving a computer on simply to carry a file-based channel, StreamNeo removes the need to keep your own computer running for the broadcast, while OBS remains a useful choice when you want local control and are able to monitor the setup.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What should I set Retry Delay and Maximum Retries to?
Set a positive delay and a finite retry allowance, then judge them against the interruptions you actually observe. OBS doubles the wait after each attempt, so the starting delay is not the interval for every retry. Official sources reviewed here do not prescribe a setting for India as a whole.
Why does OBS keep disconnecting from YouTube Live?
Reconnect settings describe what OBS does after a drop; they do not prevent the drop. Check sustained upload against your bitrate, the local Wi-Fi or wired link, and the messages in OBS and YouTube’s Live Control Room. If the issue persists after reasonable tests, ask your ISP to investigate the recorded pattern.
Does a longer retry allowance make a 24/7 stream reliable?
It can give OBS more opportunities to recover from a brief interruption, but it cannot restore an unavailable internet connection, power or a computer that has stopped running. A longer allowance also means OBS may keep retrying for longer before you intervene. Test recovery and have a separate plan for extended failures.
How much upload speed do I need for a stable YouTube stream?
There is no single answer independent of codec, resolution and frame rate. Use YouTube’s encoder guidance for the format you choose, measure sustained upload where you will stream, and leave headroom rather than treating a speed test as a guarantee. OBS’s 75% suggestion is a starting point for bitrate selection, not a promise of stability.