A YouTube live stream that shows the wrong video after resuming can be a viewer playback issue or a creator-side source issue. First establish where the wrong video appears: a viewer returning after a pause is dealing with YouTube playback and DVR, while a wrong clip in the outgoing broadcast points to the encoder or its playlist.
The title alone does not establish which cause applies. Check the event page and the point where the video changes before changing stream settings or replacing a file. The steps below separate those paths so you can test the relevant one.
First identify who sees the wrong video
Ask what “resumes” means in this case. Does one viewer pause the stream and later see a different image or an unexpected position? Does the creator restart an encoder and find that it now sends another file? Or does everyone watching the live feed see the wrong content? Those are different symptoms, even if they are described with the same words.
Start by recording what happened just before the problem: a pause, refresh, reconnect, scene change, playlist transition, or restart. Note whether the issue affects one viewer or the outgoing stream generally. If the creator can see the wrong clip in the encoder preview or YouTube’s Live Control Room preview, investigate the source path first. If the preview and local recording are right but one viewer gets unexpected playback, focus on the event page, player, and DVR.
| What you observe | Where to start | What it helps distinguish |
|---|---|---|
| One viewer returns to an unexpected position after pausing | Confirm the event page and check DVR behaviour | YouTube player playback versus the encoder feed |
| The Live Control Room preview shows the wrong clip | Inspect the active scene, source, or playlist | Content sent by the encoder |
| The preview looks right but the archived recording contains the wrong clip | Check the local encoder output and source transitions | Whether the problem was already in the outbound feed |
| Only a particular device or app behaves differently | Compare with another supported device or app | A playback-path difference, not necessarily a source change |
These are diagnostic clues, not proof by themselves. A local recording may be unavailable or may not capture every failure, so compare the evidence you do have rather than treating any single check as conclusive.
Viewer playback or creator-side source selection?
YouTube DVR and an encoder’s prerecorded media are separate stages. DVR controls how a viewer moves through a live event that is already being delivered. The encoder decides what video and audio are sent into that event. A stream key identifies the YouTube destination for an encoder; it does not select a clip within the encoder. YouTube describes stream-key use in its live streaming setup guidance, while OBS documents media-source and playlist controls separately.
That distinction matters when someone says “the stream resumed with the wrong video”. A viewer may have reopened a different scheduled event or returned to a different point in the same event. A creator may have restarted a source from its beginning, activated a scene with another file, or continued a playlist in an unexpected order. Do not reset a stream key as the first response to a wrong clip: it is a destination credential, not a media selector.
If the source software is not OBS, apply the same logic using that encoder’s documentation: identify the active output, verify the selected file or playlist, and compare it with what YouTube receives. An encoder reconnect is useful context, but it does not by itself prove the reconnect caused the wrong content.
For viewers, confirm the scheduled event and watch page
Open the channel’s live tab or the original event link and check that the watch page belongs to the intended scheduled stream. A channel may have several scheduled or past events with similar titles or thumbnails. The title can help, but it does not prove that the open page is the event you meant to watch. Check the channel, event details, and whether the player is live or showing an earlier recording.
If the page looks stale or the player appears to be continuing the wrong item, refresh it and reopen the intended event directly. Compare the result in another supported app or device if one is available. A difference between devices can narrow the investigation to a player or app path; it does not mean one device can disregard YouTube’s DVR limits.
YouTube’s guidance on live streaming and DVR explains the live-player controls and their limits. Keep in mind that ordinary uploaded videos and live streams are not interchangeable cases. YouTube’s watch progress guidance covers resuming partially watched videos; a live event has a stream start and DVR window to consider as well. If you have reached a regular replay rather than a live event, do not assume its progress behaviour identifies a live DVR fault.
Understand where DVR resumes after a pause
For live DVR playback, YouTube says viewers continue from where they paused when they resume. That describes the expected behaviour, but the available rewind range still depends on the stream and playback context. If the viewer returns to an unexpected picture, check whether the player is at the pause point, at the live edge, or showing a different event before concluding that the source changed.
A live stream’s “live” position is its current edge, while a paused viewer may be watching an earlier part of the broadcast. If the stream continues while the viewer is away, the viewer’s position and the live edge move apart. The player may therefore show older content than a creator’s current output without the encoder having switched files. Conversely, if the viewer is seeing a clearly different clip at the current edge, ask another viewer to check the same event and compare with the creator’s preview.
Try a simple, controlled check: note the visible scene and player position, pause briefly, then resume on the same page. If the behaviour differs, refresh and reopen the same event. Avoid repeatedly jumping around while diagnosing, because each seek changes the playback position you are trying to compare. If other viewers see the intended live content and the creator preview is correct, the evidence points towards the individual playback path, though it does not establish a specific device fault.
Check DVR seek limits for long streams and devices
YouTube warns that rewind may be limited or unavailable on streams longer than 12 hours. It also notes lower limits on Apple TV, Apple AirPlay, and older app versions. Viewers cannot seek earlier than the beginning of a live stream. These restrictions matter on continuous channels, where the current broadcast may have been running for many hours before someone opens it.
Do not interpret an unavailable earlier section as proof that YouTube selected another video, and do not promise that a viewer can jump to any moment in a long broadcast. The available range is bounded by the stream’s start and YouTube’s DVR support for that stream and playback device. If the player cannot reach the moment you expect, test from a supported, updated app or browser and compare with another device, but treat that as a diagnostic comparison rather than a guarantee of deeper rewind.
For a devotional channel that has been live overnight, for example, someone who opens the player in the morning may be unable to reach a point before the stream began or may face a more limited rewind window on a particular device. The practical response is to confirm the live event’s start and the player’s supported range, not to adjust the encoder playlist unless the outgoing feed itself contains the wrong clip.
For creators, verify source or playlist selection
If the error is in the outgoing feed, inspect the exact scene and source being sent. In OBS, select the scene that is live and open its Media Source properties. Confirm the assigned file path and filename, and check that it points to the intended video rather than an old export with a similar name. If the source is a playlist, review every entry and its order.
OBS documents a Media Source option called “Restart playback when source becomes active”. When enabled, a source can start from the beginning as it becomes active. That may be suitable for a short interstitial but surprising for a long-running programme when a scene is toggled. Check the setting against the intended show behaviour, and verify whether “Loop” is enabled where relevant. A restart from the beginning of the same file is different from a switch to a different file, so identify which actually happened.
For OBS’s VLC Video source, check the playlist contents, order, and the “Shuffle Playlist” and “Loop Playlist” settings. Shuffle can make the next item differ from the expected order; looping can return playback to the first item after the end. Also inspect visibility behaviour and whether a scene change is activating a source again. OBS provides details in its Media Sources documentation. For a church or music channel built around one repeated video, this guide to looping a prerecorded video in OBS covers the related setup choices.
You can also use the OBS versus FFmpeg comparison for a church stream to think through how the source is managed in your own workflow. It is not necessary to change tools to troubleshoot a wrong source; begin by checking the configuration and the actual files in the tool already running your broadcast.
For channels rotating several clips, compare the current playlist with the schedule you expect. A video-scheduling overview for YouTube Live may help when the issue is a planned sequence rather than a single file. Whether the sequence lives in OBS or another encoder, keep the intended order written down so a test can establish exactly where actual playback diverges.
Retest the relevant playback or restart path
Once you have identified a likely path, test that path before the next public broadcast. For an encoder issue, preview the outgoing feed in YouTube Live Control Room and confirm both the selected video and audio. YouTube recommends checking the preview before starting and monitoring the stream. After a test, inspect a local archive if one is available. YouTube’s live streaming troubleshooting guidance includes checks for the encoder feed and stream setup.
Compare what each stage shows. If the Live Control Room preview shows the wrong clip, correct the active scene or source before continuing. If the preview is right but the archive has the wrong clip, check the local output and transitions in the encoder. If both are right while one viewer reports an unexpected position, return to the watch page and DVR checks. This preview/archive comparison is a diagnostic inference: it helps locate where the content first differs, but a missing or incomplete archive cannot settle the question alone.
For an OBS restart, test the same sequence that previously preceded the issue: activate the scene, reconnect the encoder if that was part of the event, and observe whether the source restarts or advances. For a playlist, watch the transition between entries and confirm the next item is the one you expect. Make one relevant change at a time, then repeat the test; changing the file, scene, and playlist settings together can hide which control mattered.
If the encoder reports a healthy connection but sends unexpected content after reconnecting, check its active source and logs, use a current version of the encoder, and inspect local archives. YouTube also recommends checking the feed within the encoder and the connection when stream quality or delivery is in question. Those are general troubleshooting measures, not evidence that network conditions cause a wrong-file selection. For an always-on setup, a continuous OBS stream guide for Ubuntu can help you review the broader restart path without confusing it with viewer DVR playback.
If you rely on a computer to keep sending a prerecorded file, a machine that is turned off or disconnected cannot continue that local encoder output. StreamNeo removes that specific need to leave your own computer running for an uploaded file: it runs the YouTube broadcast after you provide the video and stream key. That does not select the correct source for you, remove YouTube playback limits, or guarantee a particular viewing result, so confirm the file and event before relying on any workflow.
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 my YouTube live stream show a different video after I resume?
The wording can describe viewer DVR playback or a creator restarting prerecorded media, and the title alone cannot identify which is happening. Check whether the wrong content appears in the Live Control Room preview or only on one viewer’s watch page, then follow that path.
Can I seek earlier than the start of a live stream?
No. YouTube says viewers cannot seek earlier than the beginning of the live stream. Rewind may also be limited or unavailable for streams longer than 12 hours, with lower limits on certain devices and older app versions.
What should I check first in OBS if the wrong file plays after reconnecting?
Confirm the active scene and the file assigned to its Media Source. Then check whether source activation restarts playback and, for VLC Video, verify the playlist order and shuffle setting. Test the same reconnect or scene-change sequence again before the next public broadcast.
Should I reset my YouTube stream key to fix the wrong video?
Not as the first step. The key directs the encoder to the YouTube stream; the encoder’s source or playlist determines which prerecorded content it sends. Confirm the source and outgoing preview before changing destination settings.