To make an OBS playlist rotation resume at the block that should be airing after a reboot, OBS must reopen and a schedule-aware rule must select the scene or media source for the current time. Restoring the file that was playing before shutdown is a different job: it can continue playlist playback without calculating which scheduled block is due now.
You can assemble a time-based approach with Advanced Scene Switcher, but treat it as an inference from documented features, not a tested recovery recipe. The exact result depends on your schedule, how you represent each block in OBS, and what happens at gaps and boundaries.
What should resume after a reboot?
Start by defining “resume”. It can mean restarting the same file, continuing a playlist from its last item, or skipping to the programme block that should be airing at the time OBS comes back. Those outcomes are not interchangeable. If the stream was offline for an hour, restoring yesterday’s or an earlier playlist item may be precisely the wrong result.
Write down the schedule before changing OBS. For each block, note its start and end time, the timezone used, and the scene or source that represents it. Decide what should happen during any gap, and which block wins if two windows touch or overlap. A devotional channel might have morning bhajans followed by a recorded talk; a news loop might have hourly summaries. In either case, “what was playing?” and “what belongs on now?” are separate questions.
Also decide how viewers should experience a change of block. Does a new scene start from its first frame, or should an already-running source remain visible? Does audio need to restart with the video? Your answers affect whether you select a scene, activate a media source, or manage a playlist. This is a small design decision with practical consequences: a correct schedule match can still look wrong if the scene is black or its source has not begun playback.
If you are still building the rotation itself, first make the source and files predictable. The guide to preparing long MP4 files for reliable playback in OBS covers the media side. For a continuously changing programme, rotating a YouTube livestream playlist without restarting OBS is a useful companion, but neither playlist playback nor a normal rotation rule, on its own, establishes time-aware recovery after downtime.
Restore the current file or select the scheduled block
OBS offers several ways to play media, but their playback settings should not be mistaken for schedule logic. A standard Media Source points to one file and includes a “Restart playback when source becomes active” property, on by default. OBS’s Media Sources documentation also describes VLC Video as a playlist source that can play items in order or shuffle them, loop a playlist, and respond to visibility changes. VLC must be installed for the source to appear; 64-bit OBS requires 64-bit VLC.
These choices help decide how content plays once a source is active. They do not document a rule that examines an outage’s end time and chooses whichever scheduled block is current. Looping a playlist means it goes round again; it does not mean “skip the items that would have played while the computer was off”. Likewise, restarting a media source when it becomes active is not the same as selecting the right programme window.
A separate community plugin, Media Playlist Source, documents saving the currently playing file so it plays when OBS restarts. Its description distinguishes starting with the first file from starting with the current file. That can suit a channel whose priority is continuity through an OBS restart, but it does not establish current-time schedule selection after downtime. Check the plugin’s resource page for release and OBS-version compatibility before relying on it; do not assume older README statements apply to the build you install.
| Your requirement | Relevant feature | What it does not establish |
|---|---|---|
| Replay one file when its source becomes active | OBS Media Source restart-on-active property | Which scheduled block is due after downtime |
| Play a list in sequence, shuffle it, or loop it | OBS VLC Video playlist source | Time-based recovery after the computer was off |
| Restore the same playlist item across an OBS restart | Media Playlist Source current-file persistence | Selection of the block scheduled for the current time |
| Choose a block based on the current date and time | Advanced Scene Switcher conditions and actions | A ready-made, verified macro for your particular schedule |
The choice is not a contest between plugins. If your requirement is simply to carry on with the current file, state restoration may be the closer fit. If you need the block that should be on now, you need a schedule rule and a way to apply its result. For broader file and source preparation, see how to keep an OBS playlist playing after Windows updates and restarts; that kind of playback continuity should still be tested separately from schedule selection.
Launch OBS after startup
A time-based rule cannot help if the computer reboots and OBS stays closed. Configure the operating system to launch OBS after sign-in or startup, using the startup mechanism available in your OS. This step sits outside Advanced Scene Switcher: a plugin’s setting to start inside OBS does not itself make the operating system open OBS.
The distinction matters on a shared or unattended computer. Confirm whether the machine waits for a user to sign in, whether a password prompt blocks startup, and whether power settings allow it to restart after an interruption. Avoid changing security settings just to make an automatic launch convenient. Use an account and startup arrangement you can maintain, and record the steps so another person can recover the channel if needed.
When OBS does launch, confirm that it opens the intended profile and scene collection. If you keep test and live collections, a reboot that opens the wrong one can leave the stream in an apparently healthy but incorrect state. Check the stream destination, audio routing, and the scene that viewers see before treating startup as complete. For the separate question of video quality and stream output, the YouTube Live encoding settings guide is a relevant reference; encoding does not solve schedule selection, but it is part of the overall recovery check.
Do not assume that a successful OBS launch means the YouTube broadcast is live. This article’s scope is choosing content inside OBS. Your channel’s stream connection and YouTube’s status are additional things to monitor after a reboot, and the appropriate checks depend on how your broadcast is configured.
Configure Advanced Scene Switcher
Advanced Scene Switcher is a community plugin for OBS. Its documented capabilities include date/time conditions and actions involving scenes, media and macros. The plugin’s resource listing describes its supported OBS versions and operating systems; check the current listing and release information against your installed OBS build before installing or updating it. Plugin compatibility changes, so do not treat a version note found in an older guide as current.
At a high level, the proposed arrangement is to map each schedule window to an explicit action. If a morning block is represented by a scene, the action would select that scene; if each block is a separate media source, the action would activate the appropriate source. Keep the mapping legible: names such as Morning Bhajans and Evening Talk are easier to audit than Scene 4 and Media 7 when you revisit the configuration after a reboot.
The plugin must be running after OBS reopens. Its startup choices are separate from operating-system startup: the plugin can be configured to start with OBS, while the OS must launch OBS in the first place. The plugin’s documented startup options include always starting it or starting it if it was running previously. Choose deliberately, then verify the switcher is active in the reopened OBS session rather than assuming it inherited the state you intended.
This is where the limits of the advice matter. The features documented by the plugin provide building blocks, not proof that a particular macro design correctly handles your schedule, restart timing, or every OBS state. Translating those capabilities into a post-outage selector is an inference. There is no universal set of macro values to copy because block count, schedule, timezone, gaps and scene design differ from channel to channel.
Use date and time conditions for schedule selection
Represent the schedule as time windows, then associate each window with the scene or media action you want. Before creating conditions, settle on one timezone and use it consistently. If your channel follows local time in India, note what should happen when the computer’s clock or timezone changes; do not leave the schedule dependent on an unexplained mix of local and UTC times.
For each block, define its start and end boundary in plain language first. Decide whether the start is inclusive and how an exact handover is handled. If one programme ends at 10:00 and the next begins at 10:00, assign the boundary unambiguously so both rules do not compete or neither rule match. Decide too what happens outside the schedule: hold the last scene, show a slate, or use a designated fallback. These are editorial choices, not settings that can be inferred from the plugin’s feature list.
In Advanced Scene Switcher, use a date/time condition to identify a matching window and an action to select the corresponding scene or media source. The plugin also has a Macro Schedule feature intended to schedule macro actions for a date and time, documented in its update history. A schedule of repeating daily windows and a specific dated macro event are not necessarily the same design. Pick the feature that matches your intended schedule, and check the current documentation rather than assuming a feature name guarantees the desired restart behaviour.
Keep the rule set simple enough to inspect. A table outside OBS, or a short written map next to your configuration notes, can show each time window, timezone, intended scene, and fallback. That gives you a way to spot omissions before you build conditions. If a source should start from the beginning when selected, check its playback properties; OBS Media Source’s restart-on-active setting may matter. But do not use that property as a substitute for testing the schedule match.
A channel with different weekday and weekend content has more than one calendar pattern to account for. Likewise, a schedule that changes seasonally needs an explicit way to update or replace its windows. Keep a dated copy of the current schedule and note when you change it. A configuration that worked for last month’s timetable can be wrong after a programme shift, even if OBS and the plugin have not changed.
Check the schedule against outage time
An outage creates a gap in playback, but the relevant selection point is the time OBS and the switching rules become active again. If the computer returns before a boundary, the current block may still be due. If it returns after a boundary, the next block may be due instead. A rule that merely restores the last active item can ignore that elapsed time.
Make a recovery table before testing. Include a restart during the middle of a block, a restart just before a boundary, one just after it, and any schedule gap or overlap that your channel actually has. Record the expected scene or source for each case. These examples do not prove how the plugin will behave; they make the intended result explicit so you can see whether your configuration agrees with it.
Also consider what happens if OBS opens close to a boundary. A macro might run before a source is ready, or the next condition may become true immediately afterwards. The plugin’s capabilities do not, by themselves, tell you which scene will be visible throughout startup in every configuration. Decide which outcome is acceptable and observe both the scene selection and the audio/video playback after each test.
If you are using a playlist, distinguish the playlist’s internal order from the schedule’s order. A playlist might contain several songs for one block, while the schedule chooses which block’s playlist or scene should be active. One handles items within a block; the other chooses the block. Keeping those layers separate makes troubleshooting less confusing, especially when a viewer reports that the stream is live but showing yesterday’s content.
Test recovery without assuming it is proven
Do not treat this outline as a tested workflow. The combination of OS startup, OBS startup, plugin startup and time-based selection is a configuration inference from documented capabilities, not a verified recipe for every OBS version or schedule. Test your own setup before depending on it overnight, and do not infer correctness from one successful reopen.
Start with a copy of your OBS profile or a controlled test collection, and use non-live content or a private test destination where appropriate. Simulate restarts at different points in the schedule, including a boundary and any gap you have defined. For each run, note the time at which OBS becomes available, which scene or source is selected, whether playback begins, and whether the intended audio is present. If the result is wrong, change one element at a time: startup state, condition boundary, action mapping, or media-source behaviour.
Repeat after changes to OBS, the plugin, the schedule, or the computer’s startup arrangement. A test that passed before an update is not evidence that a changed configuration still behaves the same way. Keep the result notes with the schedule so the next operator knows what was checked and under what conditions. Avoid describing the setup to others as guaranteed or proven merely because it worked in a limited test.
If the only requirement is to resume the same playlist item after OBS restarts, evaluate Media Playlist Source separately and confirm compatibility with your installed OBS version. If the requirement is to skip to the block that should be on now, test date/time selection instead. These are distinct recovery goals, and your troubleshooting notes should say which one you are validating.
For some operators, the burden is not choosing a macro but avoiding a local computer and its restart behaviour altogether. StreamNeo addresses that specific operational pain by letting you upload a video and have it run as a YouTube live stream without keeping your own computer switched on; it does not replace a custom OBS schedule design, and it is limited to YouTube. Choose based on whether you need local OBS control or a file-based always-on 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
Will OBS automatically choose the next scheduled block after a reboot?
Not from playlist restoration alone. A date/time condition and an action that selects a scene or media source can be assembled from Advanced Scene Switcher capabilities, but this article does not establish a tested recovery recipe. Test your actual schedule and startup sequence.
Does Media Playlist Source resume the block that should be airing now?
Its documented feature saves the currently playing file so that it can play when OBS restarts. That is continuity for the current item, not documented calculation of which scheduled block is due after the time OBS was offline.
Do I need both OBS startup and Advanced Scene Switcher startup enabled?
The operating system needs to launch OBS, and then the plugin needs to run inside OBS for its rules to operate. These are separate steps. Verify both after a simulated reboot rather than assuming one setting enables the other.
What should I test first?
Write down the expected scene or source for a restart within a block, near a boundary, and during any gap. Then simulate those cases in a controlled setup and check selection, video and audio. A result from one test does not prove every schedule window or future update.