A 24/7 fireplace stream can start streaming when OBS opens, but OBS must first be opened by Windows or another process. The key launch parameter is --startstreaming; on Windows, an automated task should also use the folder containing obs64.exe as its working directory.
OBS automatic reconnect is a separate layer. It can retry a disconnected output while OBS is still running, but it does not reopen OBS after a crash, launch it after a reboot, or guarantee an unattended stream through every failure.
Save the fireplace setup before automating it
Start with a normal OBS setup that works when you operate it manually. Automation should remove repetitive clicks, not hide an unfinished scene, an untested stream key, or an encoding problem.
Create or open the profile you intend to use for the fireplace channel. Check the output resolution, frame rate, encoder, bitrate, audio settings, and recording choices. The correct values depend on your computer, connection, and the type of fireplace video you are showing. A mostly static 1080p fireplace scene has different practical demands from a high-motion 4K video with several audio tracks.
Create a scene collection for the channel and confirm that the intended scene is selected. Check the media source itself:
- The file opens without a missing-path warning.
- The video plays for longer than a brief preview.
- The fireplace audio is audible but does not clip.
- The source is set to behave as you expect when playback reaches the end.
- Any overlays, logos, text, or browser sources appear correctly.
- The scene remains correct after closing and reopening OBS.
If the file is on an external drive, a disconnected network location, or a desktop folder that may be moved, automation will not fix that dependency. Put the source in a stable location and use the saved path in OBS. Keep the computer from entering sleep, and make sure Windows can sign in to the account that owns the OBS configuration.
Select the YouTube service and enter the stream key in OBS. Treat the key as a credential. Do not paste it into a public screenshot or place it in a script that other users can read. If you rotate the key later, update OBS and carry out the manual test again.
Before adding a launch argument, click Start Streaming in OBS and inspect the YouTube control room. Confirm that the broadcast is arriving, the picture is clean, and the audio is present. YouTube's current guidance on starting and managing live streams is available in its official live-streaming Help documentation. This manual start is useful because it separates an OBS configuration problem from a Windows automation problem.
For a long-running video channel, also review the practical network questions covered in Can Indian broadband handle 24/7 4K 60fps YouTube live streaming. You do not need a 4K fireplace stream merely because the source file is 4K. A lower output can reduce the work done by the computer and the amount of data sent, provided the result suits your viewers.
Close OBS normally after the manual test, then open it again without changing anything. Confirm that the profile, scene collection, scene, source path, and stream settings are still the ones you expect. Only then should you add unattended launch behaviour.
Launching OBS is different from reconnecting the stream
There are several failures that look similar from a viewer's point of view but require different remedies. The stream may disconnect while OBS remains open. OBS may freeze or close. Windows may restart after an update. A power cut may bring the computer back before the router or broadband connection is ready. One setting cannot handle all of these events.
The --startstreaming parameter tells OBS to begin streaming as part of its launch. It does not launch the OBS executable. A shortcut, Task Scheduler, the Windows Startup folder, or another process must open OBS first.
Automatic reconnect works at the output layer. When OBS is running and its connection to the streaming service is interrupted, OBS can retry according to its reconnect settings. That is useful for a temporary network drop. It is not a process supervisor. If OBS crashes, the reconnect feature has no running OBS process in which to operate.
The distinction is easier to see in a table:
| Mechanism | Failure it addresses | Must OBS already be running | What it does not do |
|---|---|---|---|
--startstreaming |
Starts the stream when OBS is launched | No, but something else must launch OBS | It does not create a startup trigger or restart a crashed process |
| OBS automatic reconnect | A temporary disconnection from the streaming output | Yes | It does not reopen OBS after a crash or reboot |
| Startup folder or Task Scheduler | Opens OBS when Windows or a user session starts, depending on the task | No | It cannot ensure that the network is ready at that exact moment |
| External supervisor or script | Can detect that OBS has exited and relaunch it when correctly configured | No | It needs its own careful design and does not remove power or connectivity risks |
This is why a 24/7 setup normally has layers. One layer opens OBS, one tells OBS to start streaming, one retries a dropped output, and an additional operating-system process may deal with an exited application. These layers should be tested separately.
If your real requirement is simply to keep a recorded fireplace video online without leaving a home computer running, compare that operating model with the approach described in the guide to looping devotional videos without a PC in India. That is a different trade-off, not an OBS setting.
Add --startstreaming to the launch method
OBS documents launch parameters for starting the application with specific behaviour. The parameter relevant here is:
--startstreaming
A basic Windows command therefore points to the executable and adds the parameter, for example:
"C:\Program Files\obs-studio\bin\64bit\obs64.exe" --startstreaming
The exact installation path on your computer may differ. Use the path shown by the OBS shortcut or locate obs64.exe in the installation folder rather than copying a path that does not exist on your machine.
You can add the parameter in a desktop shortcut. Right-click the shortcut, open Properties, and place --startstreaming after the closing quote in the Target field. The result should have the executable path first and the parameter after it. Do not put the parameter inside the quotation marks that surround the path.
A shortcut can also select an explicit profile, collection, or scene. OBS documents parameters including --profile, --collection, and --scene in its launch parameters reference. Use these only when you need the launch to select something other than the saved default. If you use a name containing spaces, follow the quoting format shown in the OBS documentation.
For example, a launch command may look conceptually like this:
"C:\Program Files\obs-studio\bin\64bit\obs64.exe" --profile "Fireplace" --collection "Fireplace Channel" --scene "Main Fireplace" --startstreaming
The names in that example are placeholders for the names you created in OBS. They are not settings that OBS will create for you. If a profile or collection name is misspelled, the automated launch may not select the intended setup. Start with the simplest command, confirm it behaves correctly, and add explicit selection only where it solves a real ambiguity.
Test the shortcut while you are present. OBS should open with the intended configuration and begin the stream without requiring you to press Start Streaming. Check YouTube rather than assuming the OBS status alone proves that the broadcast is available. If the shortcut opens the wrong profile or scene, correct the saved configuration before moving to Task Scheduler.
Set the Windows task's working directory
Task Scheduler has an important field that is easy to overlook. In the task's action, the executable belongs in Program/script, any launch parameters belong in Add arguments, and the folder containing the executable belongs in Start in, also called the working directory.
To create a basic task, open Task Scheduler and choose the option to create a task rather than relying on a shortcut alone. Give it a clear name such as OBS Fireplace Stream. Under the trigger, choose the event that matches your requirement. A task that runs at user logon is not the same as a task that runs when Windows starts, and the choice affects whether a desktop session is available.
Under Actions, create an action that starts a program. For a typical installation, the fields should be conceptually arranged like this:
| Task Scheduler field | What to enter |
|---|---|
| Program/script | The path to obs64.exe, without launch parameters |
| Add arguments | --startstreaming, plus any explicitly required profile, collection, or scene parameters |
| Start in | The directory that contains obs64.exe |
For the example installation path, Start in would be:
C:\Program Files\obs-studio\bin\64bit
Do not put the executable filename in Start in. It is the folder only. Do not leave the field blank simply because the full executable path is already present in Program/script. The OBS launch guidance specifically calls for the executable's directory as the working directory for this type of automated launch.
The working directory matters because an automated launch is not always started from the same context as a double-click on a desktop shortcut. Relative paths and application resources can behave differently when Windows starts a task. Setting the directory removes one avoidable source of failure and makes the task match the documented OBS launch arrangement.
In General, decide which Windows account should run the task and whether a user must be logged on. OBS scenes that depend on a desktop, graphics session, browser source, or audio device need a session in which those resources are available. A task that runs in a non-interactive context can have different access to displays, sound devices, permissions, and saved user settings.
Use the least complicated setup that fits the channel. If you are operating the computer at home and need to see OBS, a logon-triggered task may be easier to diagnose. If the machine is intended to recover after a reboot without someone opening a desktop, you need to design the startup task and the Windows account behaviour deliberately. The --startstreaming argument alone does not configure either trigger.
If you are choosing between a dedicated computer and another operating model, should Indian YouTube creators use a spare PC or cloud streaming service explains the practical trade-offs. A spare PC can give you direct control over OBS, but it also leaves you responsible for Windows, power, network readiness, updates, and failed hardware.
Configure reconnect as a separate recovery layer
In OBS, open the settings for the stream output and configure automatic reconnect for the temporary disconnections you expect. The OBS output reference describes retry count and interval settings. The retry interval increases between attempts, so the setting is not the same as repeatedly launching OBS.
Choose values that reflect the connection rather than assuming that more retries solve every problem. If the router is briefly renegotiating a connection, retries may allow the existing OBS process to resume. If the computer has lost power, the application has closed, or Windows is still booting, reconnect settings cannot act until OBS is running again.
A stream may also fail because the network is available locally but cannot reach YouTube, because the router has not completed its startup, or because the platform is temporarily unavailable. OBS can report the output state, but it cannot control every part of that chain. You should therefore treat reconnect as a useful attempt to recover an output, not as a promise of continuous broadcasting.
Power outages deserve their own test. After Windows starts, a scheduled task may run before the modem or router is ready. An OBS forum discussion about an always-on Windows stream describes this as a practical concern and mentions waiting for connectivity before starting or restarting OBS as a possible scripting consideration. That is community advice for a particular situation, not a universal OBS rule or a complete script.
You can reduce some short power interruptions with a UPS sized for the streaming computer and network equipment. A UPS may keep those devices powered during a brief interruption, but it does not restore an internet service failure, repair a crashed application, or restart OBS by itself. It is an optional power measure, not part of OBS's reconnect feature.
For a more detailed look at network recovery in a different command-line setup, see how to make an FFmpeg YouTube live stream recover after a network drop. Do not copy its commands into an OBS task without understanding which application owns the output and the recovery logic.
Add process recovery only if you need it
A task that launches OBS at logon or startup covers a reboot-triggered launch, assuming Windows reaches the relevant trigger and the task account can run the application. It does not necessarily cover an OBS crash later in the day. For that failure, you need an additional process-management layer.
An external supervisor or monitoring script can watch for the OBS process, detect that it has exited, and launch it again with --startstreaming. The exact design depends on the Windows account, whether the process needs an interactive desktop, how you want to avoid duplicate OBS instances, and how the script should behave when the network is offline. The researched OBS documentation establishes the launch argument and the output reconnect behaviour; it does not provide a complete cross-purpose crash-supervisor recipe.
Avoid treating a scheduled task that runs once as a crash supervisor. A one-time task can open OBS during startup, but it will not automatically notice every later exit unless you configure an appropriate trigger or monitoring action. Similarly, enabling reconnect does not turn OBS into a watchdog for itself.
If you create a supervisor, include a way to inspect what happened. Keep logs of launch attempts and exits, and make sure a failed start does not create a chain of duplicate OBS windows. Test how it behaves when OBS is closed normally, when the internet is disconnected, and when the computer is restarted. A recovery mechanism that works only when the network is already healthy may need a delayed or connectivity-aware launch decision.
Do not add a script merely because the word “24/7” appears in the project. More automation creates more places to diagnose. First establish a clean manual OBS setup, then automate launch, then test reconnect, and only then decide whether a process supervisor is justified.
Test the unattended sequence in stages
A convincing test is a sequence of failure simulations, not just one successful launch. Perform it while you can observe the computer and the YouTube control room. Do not claim that the stream is unattended until the exact trigger and recovery path have been exercised.
Start with the launch shortcut or scheduled action. Close OBS, run the action, and confirm all of the following:
- The intended Windows account runs the task.
- The correct OBS profile, collection, and scene open.
- The fireplace file is available and playing.
- OBS begins streaming because of
--startstreaming. - YouTube receives the broadcast.
- The audio and video are still correct after the automated launch.
Next, test a temporary network interruption without closing OBS. Observe whether the output reconnects according to the settings you configured. Restore the connection and check that the broadcast returns in the way you expect. If the output does not recover, record whether OBS stayed open, whether the encoder continued, and what status OBS displayed. Those observations tell you whether the issue belongs to reconnect, the network, or the application.
Then close OBS and restart Windows. Check whether your chosen startup or logon trigger runs. If the task opens OBS before the network is ready, record the result rather than silently assuming that a later retry occurred. This is the point at which a delayed launch, connectivity check, or separate recovery design may be needed.
Finally, test the process-exit case if you have added a supervisor. Close OBS in the way your supervisor is meant to detect, and check whether it relaunches only once. If you have not added a supervisor, record that a crash remains outside the coverage of your launch argument and reconnect settings.
Keep a small runbook beside the computer. Include the OBS profile name, source file location, task name, executable path, stream-key replacement procedure, and the checks to perform after a reboot. Do not store the stream key in that document. A runbook helps another person recover the channel without guessing which shortcut or profile is authoritative.
When the file and channel are ready, the simpler alternative is to remove the always-on computer from the daily operation: StreamNeo handles the specific pain of leaving OBS running locally by taking an uploaded video and running the YouTube broadcast after you provide the stream key. It does not remove the need to check the channel or follow YouTube's current rules, but it avoids making a home Windows task responsible for every restart.
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 --startstreaming restart OBS after a crash?
No. It tells OBS to start streaming when OBS is launched. A shortcut, Startup-folder entry, Task Scheduler task, or external supervisor must launch the application first, and a separate process-recovery arrangement is needed if OBS later exits.
Why does the Windows task need a Start in folder?
The Start in value is the working directory for the action. Set it to the folder containing obs64.exe, while keeping the executable itself in Program/script and the launch parameters in Add arguments. This follows the OBS launch guidance and avoids relying on the working directory chosen by the task runner.
Will OBS reconnect after the router reboots?
It may retry the output if OBS is still running and the connection becomes available again, according to the reconnect settings. It cannot reopen OBS after a crash or start the application after a full computer reboot, and the task may run before the router is ready.
Should I use a startup task or a logon task?
Choose based on whether the scene requires an interactive Windows session and whether someone needs to see OBS. A startup task may run before network equipment is ready, while a logon task depends on the configured account session. Test the chosen trigger on the actual computer rather than assuming the two behave identically.