How do I stop OBS from freezing when looping a video overnight? There is no single setting that guarantees stability: first work out whether OBS, its preview, or the recorded output has stopped, then test the media source and scene in a controlled way.
Check the session log from the run that failed before deciding what caused it. A loop setting, hardware-decoding test, simpler scene, or Windows HAGS test can help narrow things down, but none proves a cause without the relevant log and system details.
First identify what actually froze
“OBS froze” can describe several different symptoms. The OBS window or process may have become unresponsive; the preview may show a still frame while the broadcast or recording continues; or the recording may continue to grow in duration but contain a frozen image. Those are not interchangeable failures, and one symptom does not identify the cause of another.
When you next see the problem, note what remains responsive. Can you move the OBS window or use its controls? Does the stream remain visible on YouTube? Does the recording file continue to increase in size or duration? After stopping the test, does the file play normally, show one frame for a long stretch, or fail to open? Avoid terminating OBS immediately if it is still responsive: first note the time and state, and save what evidence you can.
Write down the OBS version, operating system, video file type and codec if known, whether the whole computer or just OBS appears stuck, and whether the preview, live output, and recording differ. For a YouTube channel, check the viewer-facing stream separately from the local preview. A frozen preview is not by itself proof that viewers received a frozen image, just as a moving preview does not prove that the recording is intact.
If the recording is missing or damaged after a forced shutdown, treat that as a file-recovery problem as well as a playback diagnosis. Changing the recording container can reduce the risk that an interruption ruins the file, but it does not stop OBS from freezing. Keep those questions separate while testing.
Reproduce the failure with one source
The aim is to turn an occasional overnight report into a comparison you can repeat. Start with the same lecture file, the same output settings and one scene containing only the video source. Note when playback starts and when the source reaches its end. If the simple test works but the full production scene does not, you have useful evidence that the added scene workload or another source may matter; you still do not have a confirmed root cause.
Do not change several settings between attempts. If you switch the media source, decoding mode, output resolution and graphics settings together, a different result cannot tell you which change mattered. Change one item, repeat the same playback, and record the result. A short controlled test is useful for comparing configurations, but it cannot demonstrate that a setup will last all night. Run a longer test before relying on a configuration for an important scheduled stream.
Make a small test record with the timestamp, OBS version, source type, loop state, decoding state, scene contents, whether OBS responded, and what the preview and output showed. Include whether recording was active. These notes give context to the session log and make it easier to compare a test that stopped at the end of the file with one that ran for longer.
If you need a walkthrough of the broader Windows arrangement, the guide to configuring OBS for recorded lessons on YouTube covers the streaming setup around the playback task. For this diagnosis, keep the test smaller than a finished channel scene so that fewer moving parts can obscure the result.
Check the loop and compare decoding modes
For one local lecture file, OBS Media Source is often the most direct starting point. Open the source properties and confirm that Loop is enabled. The OBS Media Sources documentation describes Loop as replaying the file after it completes, and lists it as off by default. Do not assume that a source will repeat just because it is in a scene; inspect the actual source setting.
Restart playback when source becomes active is separate from Loop. It controls playback when the source becomes active, rather than whether playback repeats at the end; the documentation lists it as on by default. Note which behaviour you want, especially if the source is hidden and shown by scene switching. A loop test should let the file reach its end and confirm that playback starts again, rather than relying on a brief preview near the beginning.
If you use a VLC Video source for a playlist or format support, check Loop Playlist in that source instead. VLC Video has a different dependency from a single Media Source: the OBS guide notes that VLC must be installed and that 64-bit OBS requires 64-bit VLC. A single local lecture file may not need this extra source type. Compare Media Source and VLC only when there is a practical reason, such as a playlist requirement, and record which one you tested.
Hardware decoding is another setting to test, not a presumed fix. OBS documents it as off by default for Media Source and explains that it uses the GPU when a suitable decoder is available. Test the same file and scene once with hardware decoding off and once on, changing no other relevant setting. If one mode repeats the failure and the other does not in a controlled comparison, that is a lead to verify in longer runs and the affected-session log, not proof of a universal setting.
The video settings guide for 24/7 YouTube streams can help you consider whether the file is more demanding than the output needs. Do not convert a file or change output quality merely because a freeze happened; use a lower-resolution copy only if that resolution is adequate for the viewers and the intended stream.
Reduce scene work and inspect the failing log
OBS has to composite and render the scene as well as play and encode its sources. The OBS encoding performance troubleshooting guide notes that scene complexity, sources, filters and resolution can consume resources; sources may still demand resources even when they are not visible. A clean test scene is therefore more informative than an elaborate scene with browser panels, filters, overlays and other media all enabled.
Duplicate the scene or make a temporary test scene, then leave only the lecture source and the necessary output. Remove non-essential filters, browser sources, animated overlays and extra captures for the comparison. If the simpler scene behaves differently, add items back one at a time. This helps identify a reproducible difference without assuming that any particular source is responsible.
Compare the media resolution with the actual output resolution. If a lecture file is larger than needed for the output, a suitable lower-resolution copy may reduce work, but it also changes the test and may affect image quality. Keep the original, note the copy's properties, and compare like with like. The OBS system requirements page also cautions that requirements depend on what you are doing; a listed capability should not be read as a promise that every scene and workload will run reliably overnight.
Use a log from the run that includes the problem. OBS provides an upload workflow under Help > Log Files; upload the log from the affected session and review it with the OBS Log Analyzer. A log from yesterday's successful test may not contain evidence from tonight's freeze. Keep the test notes alongside it, particularly the time the symptom began and whether recording or the YouTube output continued.
The log can help identify warnings or configuration details worth investigating, but it should not be treated as an automatic diagnosis detached from the symptom. If OBS itself hangs, preserve any crash information as well. If the output alone is wrong, describe exactly what the viewer or saved recording showed rather than labelling every case an OBS crash.
On Windows, test HAGS and reboot
If you run OBS on Windows, Hardware-accelerated GPU scheduling (HAGS) is a specific troubleshooting test worth separating from the source tests. OBS says HAGS may cause performance problems and failures with OBS and hardware encoders, and recommends disabling it when troubleshooting performance issues or freezing. This guidance applies to Windows; it does not explain every freeze on every computer.
Change HAGS through Windows graphics settings, then reboot before repeating the same test. The reboot matters because the comparison is intended to be between sessions with the setting in effect, not a change made while relying on the old session state. Keep the video, scene, output settings and decoding mode the same as the comparison you are using. Note whether HAGS was enabled or disabled in your test record.
If disabling it makes no observable difference in repeatable tests, restore the setting rather than leaving a change in place without a reason. If the result does differ, gather the log and system details before concluding it was the cause. The OBS HAGS troubleshooting page describes the setting and recommendation; it is a diagnostic step, not an assurance of overnight stability.
Check overlays and other capture software
When OBS itself becomes unresponsive or behaves unusually, check what else is interacting with graphics or capture. OBS's known application conflicts page describes graphics-hooking applications as a possible source of crashes or unusual behaviour. This does not mean an overlay is necessarily responsible; it gives you a concrete variable to remove for a controlled comparison.
Temporarily close overlays, screen capture utilities and other recording or streaming applications, then repeat the same test. Do not uninstall software or permanently change a working setup based only on a suspicion. If the symptom disappears, reopen or re-enable items one at a time and capture a session log if it returns. This is more useful than changing unrelated graphics settings at the same time.
For channels where a local computer staying available is itself a concern, separate the operational choice from this OBS diagnosis. A hosted route can remove the need to keep your own PC running for a file-based YouTube loop; StreamNeo can remove that particular overnight computer-running burden, but it does not establish why an existing OBS session freezes. If you are comparing approaches to a continuous channel, the guide on keeping a YouTube stream running through power cuts discusses a different failure mode and the limits of relying on local equipment.
Protect the recording if a session is interrupted
Choose a recording format with recovery in mind if you are capturing the overnight run for review. OBS's Log Analyzer warns that an interrupted MP4 or MOV recording can be corrupted and unrecoverable. MKV or FLV can reduce that particular risk. This is protection for the saved file, not a way to prevent the player, preview or encoder from freezing.
If your editing workflow needs MP4, record to MKV and use OBS's remux option after a successful recording. Remuxing changes the container without re-encoding the video, but it cannot restore missing or damaged media from a failed session. Check that the remuxed file opens and seek through it before deleting the original recording. Keep the original as long as you need it for troubleshooting.
A recording that continues in duration but shows the same frame needs a different investigation from a recording that stopped growing after OBS became unresponsive. Note both the container and the observed playback result in your test record. That distinction, the session log and the source settings are more useful starting evidence than switching formats and assuming the runtime issue is solved.
For a repeatable diagnosis, make one change at a time: verify the loop, compare decoding modes, reduce scene complexity, then test HAGS only on Windows and reboot. Upload the affected session's log and use it alongside your notes. A configuration that completes a short test is a candidate for a longer run, not a guarantee that it will survive an overnight broadcast.
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
Why does OBS freeze only when the lecture reaches the end?
First confirm that the source's Loop option is enabled and observe whether playback restarts at the file boundary. If the source is a VLC playlist, check Loop Playlist instead. A freeze at that point does not establish whether the source, scene or another part of the session is at fault; compare a one-source test and inspect the affected log.
Is hardware decoding better left on or off?
There is no setting that is best for every file and system. OBS documents hardware decoding as off by default and dependent on a suitable GPU decoder, so compare on and off with the same file and scene. Keep the result that behaves better in repeatable testing, then verify it in a longer run.
Will disabling HAGS fix overnight freezing?
It may be a useful Windows troubleshooting comparison because OBS recommends testing with HAGS disabled for performance issues or freezing. Reboot after changing it and repeat the same test. If the result does not improve, restore the setting; neither outcome alone identifies the cause without the log and system details.
Does recording to MKV stop OBS from freezing?
No. MKV or FLV reduces the risk that an interrupted recording leaves an MP4 or MOV corrupted and unrecoverable; it does not prevent OBS from freezing. If you need MP4, remux a completed MKV recording in OBS and retain the original while you verify the result.