A YouTube Live loop can recover from a brief connection loss if OBS is still running and automatic reconnect is configured. A Windows restart is different: OBS has to launch again, and a startup task using OBS’s --startstreaming parameter may help, but it cannot guarantee that the stream resumes.
The steps here are for OBS on Windows, not every encoder or Windows setup. A sign-in prompt, unavailable network, encoder error or YouTube event setting can still stop recovery, so test the whole path before relying on it overnight.
Separate a connection drop from a Windows restart
Think of recovery as two separate stages. A temporary loss of internet can interrupt the connection between an open OBS session and YouTube; automatic reconnect addresses that situation. A Windows update that restarts the computer closes OBS altogether. A reconnect setting inside OBS cannot reopen an application that is no longer running.
That difference changes what you should troubleshoot. If OBS remained open but its connection dropped, inspect OBS’s reconnect behaviour and the network. If Windows restarted, first determine whether OBS opened afterwards. Only once it is open does it make sense to investigate whether it began streaming and whether YouTube received the feed.
Keep a short record of the setup that currently works: the encoder, the scene or media source supplying the loop, the YouTube stream or event being used, and how the stream is normally started. Do not put your stream key in a shared note or screenshot. It functions as a credential: YouTube Help describes stream keys as the password and address for a stream, and explains that the encoder uses them to send its feed. See YouTube’s guide to managing live stream settings.
If you use a different encoder, do not assume OBS’s settings or launch parameters apply. Check that encoder’s official documentation for what it can do after a connection drop and how it can be started after a reboot. The same diagnostic distinction still helps: is the encoder running, and if so, is it sending a feed?
A software restart plan is also not protection against every interruption. A power cut, a router that remains offline, a computer that cannot get past sign-in, or a source file that is unavailable can each break a different part of the chain. The purpose of the procedure is to make those stages visible and testable, not to promise continuous broadcasting.
Configure OBS automatic reconnect
In OBS, look in the Advanced settings for Automatic Reconnect. OBS’s overview guide identifies this as an Advanced setting. It is for restoring a dropped connection while OBS is running; it does not launch OBS after Windows has closed it.
Before changing settings, note the current configuration so you can restore it if needed. Confirm that the loop is playing in its scene and that the intended output is the YouTube stream. Then review the reconnect setting in the context of your connection. A reconnect attempt can only succeed when the computer has network access again and OBS can still encode the source.
Test a connection interruption separately from a Windows restart. For example, use an appropriate test stream and briefly disconnect the network only if you can do so without disrupting a public broadcast. Watch whether OBS reports a disconnection and then reconnects when the network returns. If it does not, record the displayed status or error rather than changing several unrelated settings at once.
This test tells you about the first failure type only. If OBS reconnects successfully after a short network interruption, that is useful evidence about that particular path; it says nothing about whether Windows will sign in, start OBS or have a ready network after an update restart. Keep those as separate tests.
Prepare YouTube and OBS encoder settings
Before setting up a Windows task, confirm that YouTube and OBS are configured to work together. In the YouTube Live Control Room, identify the stream or scheduled event you intend to use. Check its current stream URL and key against the values entered in OBS. Treat the key as private, and replace it in the encoder if you rotate it in YouTube.
YouTube’s encoder workflow requires the encoder to send output to the stream URL using the correct key. If OBS opens after a restart but YouTube receives no feed, a stale or mismatched key is one of the first things to check. YouTube’s instructions for creating a live stream with an encoder describe the workflow; use the current Live Control Room values rather than relying on an old note.
Review event behaviour as well as credentials. YouTube stream settings include auto-start and auto-stop choices that affect how encoder output and the event interact. Do not assume that having OBS send video necessarily means the YouTube event will behave as you intend. Check those controls in the relevant Live Control Room event, then test the actual sequence you plan to use.
Also verify the OBS scene and media source. A task can start OBS and initiate streaming while the wrong scene is selected, the file is unavailable, or the source is not playing as expected. If the stream uses a prerecorded file, check its path and loop behaviour from the Windows account and folder where OBS will run. A useful reference for planning a file-based broadcast is this guide to looping a video playlist to YouTube Live from a Synology NAS; its storage approach differs, but the source and playback questions matter for any loop.
Keep the stream key out of task arguments, batch files that others can read, screenshots and support messages. The launch parameter discussed below tells OBS to start streaming; it does not supply a missing key or verify that the key is correct. Confirm credentials in OBS itself and protect access to the Windows account that stores the configuration.
Use the OBS startstreaming parameter
OBS documents --startstreaming as a launch parameter. It instructs OBS to begin streaming when it is launched with that parameter, provided the rest of the setup permits it. The OBS launch parameters documentation also gives a specific requirement for automated launches: the working directory, often labelled “Start in”, should point to the folder containing obs64.exe.
The parameter is not a Windows restart setting by itself. It only matters if a startup mechanism actually launches OBS with the argument. You still need to decide what will launch it after Windows starts, under which account it will run, and whether that account can reach the configured OBS profile and media source. Windows editions and account configurations vary, so avoid treating a task recipe as universal.
A typical launch entry has the OBS executable as the program and --startstreaming as an argument. Use the executable path for the OBS installation on your machine rather than copying a path from another computer. If OBS is installed somewhere other than its usual location, the path and working directory must reflect that installation.
The key prerequisite is that Windows reaches a state in which the scheduled task can run with the permissions and profile OBS needs. If the machine stops at a sign-in prompt, requires confirmation, or cannot access the user’s profile, a task configured for that user may not behave as expected. Do not assume that the OBS parameter configures unattended Windows sign-in; it does not. Consider the security consequences of any sign-in choice, especially on a shared or publicly accessible computer.
There are other reasons a launch may fail to produce a stream. OBS may open but encounter an encoder error, the network may not be ready, the source file may be missing, or YouTube’s event settings may not accept the feed in the way you expect. The parameter does not correct these conditions. It is one part of a startup sequence that needs a controlled test.
Set the scheduled task working directory
When you configure a scheduled task to open OBS, set its program path, arguments and working directory deliberately. OBS’s guidance is that automated launches should use the folder containing obs64.exe as the working directory. In Task Scheduler, this is commonly entered in the “Start in” field, separate from the executable path and arguments.
This detail matters because an automated process may start with a different working folder from the one used when you open OBS from a desktop shortcut. A missing or incorrect working directory can affect how the application finds files or behaves at launch. Follow the OBS requirement even if a manually opened OBS session works without you thinking about that field.
Before saving the task, check each field against the actual installation and account:
- Program or script: the full path to the installed OBS executable.
- Add arguments:
--startstreaming. - Start in: the directory containing
obs64.exe, not the executable filename itself. - Account and run conditions: the Windows user and conditions under which the task is permitted to start.
The last item is where a universal recipe would be misleading. Whether the task can run before or after an interactive sign-in depends on Windows configuration and security choices. Check the current Task Scheduler options on your Windows edition, and test under the same account and conditions you expect after an update. A setting that works while you are logged in does not prove it will work at the sign-in screen.
Avoid adding unrelated Windows Update changes just to make the task appear reliable. Deferring a restart and recovering after a restart are different goals. Update controls differ by Windows edition and configuration, so check the current Microsoft guidance for your version if you are considering them. A delayed restart does not replace a tested recovery plan.
If the local computer needs constant attention or a sign-in prompt makes unattended operation unsuitable, the trade-off may be that you keep a person responsible for restarting it. For a loop where the specific pain is needing to leave a personal computer running, StreamNeo removes that dependency by letting you upload the video and run the YouTube broadcast without that computer being left on. It remains necessary to confirm that the video, channel and intended stream are ready before relying on any approach.
Test a controlled restart
Do not make the first restart test during a public broadcast you cannot afford to interrupt. Use an unlisted or private test stream where appropriate, or arrange a maintenance window and tell anyone who depends on the channel. YouTube recommends previewing before going live and monitoring stream health; consult its guidance on live stream settings and encoder checks while planning the test.
Before restarting, confirm that the loop source plays in OBS, the stream URL and key match, and the task points to the correct executable and working directory. Check the task’s run conditions and make sure you know how to recover locally if OBS opens incorrectly. Keep a note of the time you start the test and what you observe at each stage; do not expose credentials in that note.
Then perform a normal, controlled Windows restart while you are present. Observe whether Windows reaches the state required by your task, whether OBS opens, and whether the intended scene and media source are active. Next check whether OBS starts output and reports a connection. Finally, confirm whether YouTube receives the feed. This sequence isolates the point of failure instead of treating “the stream did not come back” as one undifferentiated problem.
A successful test is useful, but it only establishes that the tested account, task, network and event worked under those conditions. It does not guarantee recovery from a later sign-in prompt, a network outage, an encoder error or a change to the YouTube event. Re-test after changing OBS, Windows account settings, the task, the source location or the event configuration.
If the test fails, write down which stage failed before editing settings. If OBS did not open, investigate the Windows task, account and startup conditions. If OBS opened but did not send output, inspect its status and encoder error. If it sent output but YouTube did not show the feed, check network readiness, stream URL and key, and the Live Control Room event settings.
Verify recovery in Live Control Room
When OBS appears to be streaming, verify the result at YouTube rather than relying only on the OBS status bar. Open the relevant event in Live Control Room and look for its incoming preview or feed and stream-health information. Check that the event you intended to use is receiving the signal; a successful connection to a different event is not recovery of the intended loop.
If no feed appears, diagnose in stages. First confirm OBS is sending output and that the loop source is playing. Then check whether the network is available and whether OBS reports an encoder or connection error. Next compare the configured stream URL and key with the current values in YouTube, taking care not to share the key. Finally, check the event’s auto-start and auto-stop behaviour and other relevant settings.
YouTube’s troubleshooting advice for encoder start errors directs creators to obtain the stream key from Live Control Room and update the third-party encoder configuration when needed. Follow the current YouTube encoder troubleshooting guidance rather than changing unrelated Windows settings when OBS has opened but cannot start the feed.
Once the feed appears, check that the loop is showing the expected content and that the event is behaving as planned. A brief preview after one test does not tell you how every later outage will behave. Keep a simple check routine for after planned updates: confirm Windows has completed its restart, OBS and the source are active, and YouTube shows the intended feed.
For a continuous prerecorded channel, restart recovery is only one operational concern. The video source needs to keep playing, the event needs to be configured as intended, and somebody needs a way to notice when the feed has stopped. If you are planning what viewers see around the clock, consider the separate question of adding a logo and ticker to a prerecorded YouTube Live stream. If the channel carries music, review the rights and repeat-use considerations in whether you can stream the same song playlist 24/7 on YouTube.
For some creators, OBS is the right fit because they need its scenes, sources or local control and can maintain the PC and Windows task. Others may prefer a workflow that does not depend on their computer remaining available. Choose according to what you need to control and what you can monitor; no launch option removes the need to verify the result in YouTube.
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
Does OBS Automatic Reconnect restart OBS after a Windows update?
No. Automatic Reconnect is for a connection interruption while OBS is still running. After Windows restarts, OBS must be launched separately; the reconnect setting alone does not reopen it.
Can --startstreaming guarantee that my YouTube Live loop comes back?
No. It asks OBS to start streaming when OBS launches with the parameter, but Windows must run the launch mechanism and OBS must have working settings and a ready source. Sign-in prompts, network outages, encoder errors and YouTube event settings can still prevent the feed from resuming.
Why does OBS open after a restart but YouTube show no feed?
Check the OBS output status and any encoder error first, then confirm that the stream URL and key in OBS match the current values in Live Control Room. Also check network readiness and the event’s auto-start or auto-stop settings. Do not share the stream key while troubleshooting.
Should I test this on my live channel?
Use an unlisted or private test stream where suitable, or schedule a controlled maintenance window if the public stream must be tested. Stay present through the restart and check OBS, the loop source and YouTube’s incoming feed. Treat the result as evidence for the conditions you tested, not a guarantee for every future restart.