OBS does not document a built-in setting that restores the last video in a YouTube playlist after OBS restarts. To resume deliberately, show the playlist in a Browser Source and use a player built on YouTube’s IFrame Player API to save and reload the playlist index and playback time.
A static playlist embed can display a playlist, but the documentation does not say it remembers its position through an OBS restart. The distinction matters: choosing a playlist is not the same as saving playback state. If you need a reliable recovery path, plan for state to be stored somewhere that survives OBS closing, and test what happens when automatic playback is blocked.
What OBS does not restore by default
OBS sources have different jobs. A Media Source plays supported media files, and OBS’s VLC Video source can play a playlist of media items with VLC installed. Those features should not be confused with restoring the current item in a YouTube playlist. OBS describes Browser Source as a way to put a webpage into a scene; it does not document a setting that remembers a YouTube playlist’s last item after a restart. See the OBS media source guide and the sources guide for the roles OBS assigns to those source types.
There are two different kinds of “resume” you may mean. One is returning to the same video in the playlist; the other is returning to the same point inside that video. The first requires the playlist index. The second also requires saving playback time. If you save only the index, the player can begin the right video from its start rather than from the point where the restart interrupted it.
YouTube Help describes progress for a viewer choosing a partially watched video on YouTube: playback may restart from where it was left. That guidance is not a promise that an embedded playlist in an OBS scene will restore its last item after OBS closes. Treat the OBS restart as a separate recovery case and use explicit saved state if that behaviour matters to your channel.
If the actual requirement is changing which pre-recorded playlist appears while the broadcast stays live, that is a related but separate workflow; the guide to switching between two pre-recorded playlists without ending the stream covers that case. Here the concern is narrower: restoring one playlist’s item and, optionally, its position within that item after the local OBS process restarts.
Put the playlist in a Browser Source
In OBS, add a Browser Source to the scene where you want the player displayed. A Browser Source renders a webpage, which makes it the appropriate source type for an embedded YouTube player. You can use a page that contains a player rather than treating a Media Source or VLC playlist as if it controlled a YouTube playlist.
A basic YouTube playlist embed uses the playlist identifier in the player URL. YouTube’s embedded player parameters document listType=playlist and list=PLAYLIST_ID for selecting playlist content. These parameters identify what to load; they do not provide persistent cross-restart position on their own. The YouTube embedded player parameters documentation is the reference for the supported URL parameters.
For an initial test, a static embed is useful: it helps confirm the playlist ID is valid and the player is visible in the scene. Keep it as a display test, not as a resume solution. Before depending on it for an overnight or unattended channel, decide how a saved index and time will be read on startup. A static page that contains only a playlist does not, by virtue of that playlist URL, know which item OBS was playing before it closed.
Check the Browser Source dimensions and scene layout with the player controls visible. Controls make it easier to recover manually if autoplay is refused or a saved state is wrong. If you hide them too early, a browser policy prompt or a player error can be harder to diagnose. The same principle applies to other long-running setup decisions: the laptop electricity and overheating guide is useful if the machine running OBS is also expected to stay on continuously.
Use a player with the YouTube IFrame API
For explicit restoration, use a small page that creates a YouTube IFrame player through the IFrame Player API. The player can load a playlist, report the current playlist index, and expose playback-time controls. This gives the page the controls needed to reconstruct where playback was, but the page still needs to save and retrieve the state; the API is not a persistence system by itself.
The API’s loadPlaylist method accepts a playlist and an optional index for the first item to play. That index is zero-based: 0 means the first video. The API’s getPlaylistIndex() method reports the currently playing item’s index when the playlist is not shuffled. These are explicit controls, unlike a static embed that merely selects playlist content. Refer to Google’s YouTube IFrame Player API reference for the method details and player events.
The Browser Source displays the page, while the page’s JavaScript controls the player. That separation is useful to understand when debugging. If the player loads the wrong item, inspect the playlist ID and saved index. If the page never receives a ready event, investigate player loading and browser behaviour rather than changing the playlist state. The official documentation establishes the available player controls; it does not verify any particular third-party script or storage setup as a reliable package.
Keep the page as small and understandable as you can. Its essential responsibilities are to initialise the player, read previously saved state, load the playlist at the saved index, seek to the saved time when ready, and record updated state while playing. You do not need a schedule, shuffle, or extra interface merely to solve restart recovery. If you do use shuffle, remember that the documented index is meaningful for an unshuffled playlist; a shuffled order complicates the idea of resuming a specific original list position.
Save the playlist index and playback time
While playback is running, periodically record both the current playlist index and the player’s current time. The index identifies which video is active; the time identifies where playback is within that video. Saving only when a video ends will not help much with a power cut or an OBS crash during a long item, while saving excessively often can create needless storage activity. Choose a practical interval for your implementation and accept that a sudden failure can lose changes since the most recent save.
The saved values must outlive the OBS process. Browser Source page state held only in the running page can disappear when OBS closes, so use durable storage that your page or helper can read again on startup. Depending on how you host the player page, that could be a local state file handled by a helper or a local service. This is an implementation choice, not an OBS checkbox or an automatic feature claimed by the YouTube API documentation.
Keep the saved record tied to the playlist it belongs to. If you change the playlist ID but reuse an old index and time, the index may point to a different item or no valid item in the new list. A useful record therefore identifies the playlist as well as the current index and time. If the record is missing, unreadable, or belongs to a different playlist, use a deliberate fallback such as starting at the first item rather than guessing.
Also consider how to handle shuffle and playlist edits. When a playlist changes, the item previously at a given index may have moved or been removed. If exact identity matters, an implementation can preserve a video identifier alongside the documented index and reconcile it with the current playlist. The essential point remains that an index alone is only meaningful relative to a particular playlist order. Avoid claiming more than your own implementation can check.
Reload at the saved index
On page startup, read and validate the saved record before calling the player to load the playlist. If it is valid for the current playlist, pass the saved index to loadPlaylist; if it is absent or invalid, choose a clear fallback. Since the index is zero-based, the first item is 0, not 1. That small detail is a common source of off-by-one errors when a human-readable list numbers its first entry as one.
Loading the playlist at a saved index restores the video selection, not necessarily the exact point in that video. The time is a separate value and should be applied only after the player is ready and has the intended item loaded. The API documentation allows a playlist to be loaded at a specified index; it does not say that it independently remembers a previous index across restarts.
If you edit the playlist regularly, make the fallback observable. For example, retain controls during commissioning and note which title loads after a simulated restart. If the saved value falls outside the current playlist or the playlist cannot load, a person should be able to see and correct the problem rather than leave a blank or unexpectedly different scene running. For channels with planned daily content, this complements rather than replaces a schedule: see the guide to creating a playlist schedule for a 24/7 educational stream.
Seek after the player is ready
Do not issue the seek just because the page has loaded. The player needs to be ready, and the requested video needs to be available, before restoring the saved playback time makes sense. In the API-based page, use the player’s ready and state events to sequence the work: initialise, load at the saved index, confirm the player is ready to accept control, then seek to the saved time.
A seek can be approximate in practice. The player may still be buffering, the video may have changed, or the saved time may exceed the current item’s duration if the playlist was edited. Validate the stored time as a non-negative value and consider a safe fallback when it does not make sense for the loaded video. This is not a guarantee of frame-perfect recovery; it is a way to request resumption from a recorded point using the available player controls.
Autoplay deserves its own check. YouTube’s IFrame API documents an onAutoplayBlocked event, and browser policies can prevent autoplay or scripted playback. A player that successfully loads at the saved index may still need a person to press play. Leave a manual-play recovery route during testing, and do not design your monitoring around the assumption that a successful page load always means the broadcast is advancing.
For an unattended setup, note what a blocked autoplay event looks like in your particular scene and who can respond. If you are running an always-on channel from a small computer, recovery depends on more than playlist state; heat and power interruptions can also restart the host. The Raspberry Pi overheating guide addresses that separate operational risk without changing what the player can restore.
Test restart and recovery behaviour
Test the full sequence before depending on it. Start the playlist, allow playback to move into a video, confirm that the index and time are being saved, then close and reopen OBS. Check which item appears, whether the playback point is close to the saved time, and whether playback begins or waits for interaction. Repeat with the player page refreshed and with OBS restarted so that you can distinguish page reload behaviour from process restart behaviour.
Test failure cases deliberately, but do so in a controlled scene or at a time when a test interruption will not disrupt viewers. Try a missing state record, a changed playlist, an invalid index, and a blocked autoplay case. Keep a note of the expected fallback for each. A clear start-from-first-item fallback is often easier to recover from than silently loading a stale value.
Do not infer that the live broadcast will recover just because the Browser Source has resumed. The page and the outgoing YouTube live broadcast are related parts of your setup, but they are not the same state. Verify OBS’s stream output and YouTube’s live status separately after recovery. For continuous streaming, decide how you will notice a stalled player or a disconnected broadcast and what action a person can take.
A simple comparison makes the trade-off clear:
| Approach | What it does | What you must handle |
|---|---|---|
| Static playlist embed | Selects and displays playlist content in a Browser Source | It does not, in the cited documentation, restore a saved index or time after OBS restarts |
| IFrame API player with saved state | Can load a playlist at an explicit index and seek to a recorded time | You must implement durable storage, startup sequencing, validation, and a manual-play fallback |
| OBS Media Source or VLC Video playlist | Plays supported media items from the local media workflow | It is not documented as a YouTube playlist resume mechanism |
The practical choice depends on how much control you need. If restarting at the beginning is acceptable, a static embed may be adequate for showing playlist content, but do not count on it to resume. If viewers need continuity through an OBS restart, an API-controlled page and persistent state give you the necessary controls, with the added responsibility of maintaining and testing that small piece of code.
If the ongoing problem is that your own computer must stay running for a file-based 24/7 broadcast, StreamNeo removes that particular burden by turning an uploaded video into a YouTube live stream that continues with your computer switched off; it does not change the OBS playlist-restoration behaviour described here.
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
Can OBS restore the last YouTube playlist video by itself?
OBS does not document a built-in setting for restoring a YouTube playlist’s last item after a restart. Use an API-controlled player and saved state if you need to request a particular index on startup.
Does a static playlist embed remember the last position?
The cited embed documentation explains how to select playlist content, but does not say that it preserves position across an OBS restart. A static embed should not be treated as a resume mechanism.
Do I need to save the time as well as the index?
Save the index to return to the same playlist item. Save playback time as well if you want to return to a point within that item rather than its beginning.
What if autoplay is blocked after restart?
The IFrame API documents an autoplay-blocked event, and browser policy may require user interaction. Keep a manual-play fallback and test it in the Browser Source configuration you intend to use.