If OBS stops playing a podcast playlist during a YouTube live stream, the cause depends on what has actually stopped: the source in OBS, audio in your local monitoring, or audio reaching viewers. Those are different faults, so first note which one you can observe rather than changing settings at random.
If you use OBS’s VLC Video source, check whether a scene change hides it and what its Visibility Behaviour is set to; OBS documents a default that stops playback while hidden and restarts it when visible. If playback ends at the end of the queue instead, check Loop Playlist. If OBS appears to keep playing but viewers lose sound, use a local recording and YouTube’s Live dashboard to narrow down the path.
Identify what “stops playing” means
When the problem happens, look at the source and the audio meter in OBS before restarting anything. Is the playlist’s playback position no longer advancing, has its source disappeared from the preview, is the source meter moving, or is only the sound from your own speakers missing? Also check whether a viewer or a separate device actually hears silence. Each observation points to a different part of the signal path.
A source that visibly stops or resets is a playback or visibility clue. A moving source meter alongside silent speakers suggests a monitoring issue. If the meter moves and a local recording contains the podcast, but viewers report silence, investigate what OBS sends to the encoder and what YouTube receives. None of those observations alone proves the cause, but together they help you choose the next check.
Write down the source type, OBS version and operating system, and whether the interruption coincides with a scene change or the end of an item. The source type matters: OBS’s built-in Media Source handles an individual file, while its VLC Video source supports a playlist and requires VLC to be installed. A third-party playlist source may behave differently, so do not apply VLC-specific defaults to it.
If you are still building the playlist, the guide to creating a 24/7 YouTube music stream with a playlist can help you distinguish content organisation from what OBS is actually playing. For the diagnosis here, however, start with the source already in your scene and observe what it does when the symptom occurs.
Check whether the VLC source becomes hidden
In OBS, select the playlist source and inspect its visibility in the Sources list and preview. If it vanishes when you switch scenes, check the source’s Visibility Behaviour in its properties. OBS documents the VLC Video source default as “Stop when not visible, restart when visible.” With that setting, making the source invisible can stop playback; seeing it restart when the source becomes visible again would fit that behaviour.
This is a conditional explanation, not a diagnosis for every OBS playlist. The setting applies to the documented VLC Video source; a regular Media Source, plugin, or separate audio application can have different controls. Check the name and properties of the actual source before changing a setting. The OBS Media Sources documentation describes the source types and VLC Video properties.
If the playlist must keep progressing while its source is off-screen, consider changing Visibility Behaviour to a setting that keeps playback active while hidden. Test that choice before relying on it: continuous playback while hidden can mean the playlist advances even though nobody can see the source in that scene. If you want a different scene to show the same media, also consider how the source is used across scenes rather than assuming that hiding one copy preserves its position.
If VLC Video is missing from OBS’s source menu or cannot be added, check the dependency rather than treating it as a mid-stream dropout. OBS says VLC must be installed for the source to appear, and 64-bit OBS requires 64-bit VLC. That is a setup check, not evidence that a VLC installation mismatch explains a playlist that was already playing and then stopped.
Check Loop Playlist at the end of the queue
If playback stops when the final item finishes, open the VLC Video source properties and inspect the playlist and Loop Playlist. OBS documents Loop Playlist as on by default for this source, but settings can be changed, and your source may not be VLC Video at all. Confirm the actual setting instead of relying on a remembered default.
Check that the expected items are present, in the intended order, and that the final item is not simply the end of a non-looping queue. Shuffle Playlist is documented as off by default; if it has been enabled, the next item may not be the one you expect. For diagnosis, keep the playlist short and recognisable, then watch whether it returns to the first item after the last one.
For an individual file loaded as a regular Media Source, inspect that source’s Loop property instead. It is not the same control as Loop Playlist in VLC Video. A single file that is meant to repeat and a queue of several files that is meant to cycle need their own appropriate setting. The article on looping a long video without restarting the YouTube stream covers the related distinction between looping media and ending or restarting a live broadcast.
Do not use looping as a catch-all fix. If the source stops halfway through an item, the queue’s end behaviour is unlikely to explain that symptom. Note the item and elapsed position, then move on to visibility, file playback, or the recording test.
Compare OBS playback with a local recording
Make a brief local recording while reproducing the problem. Keep the OBS preview, source position and audio meter in view, and note the time at which the sound seems to stop. After the test, play the recording and compare the same moment. A local recording is useful evidence, though it may not capture every output in precisely the same way as the live stream.
If the recording also loses the podcast, focus first on the OBS source and media: confirm the file still plays, check whether the source became hidden, and see whether a playlist item ended or changed. If the recording contains clear podcast audio while viewers hear a dropout, the media may still be playing locally; inspect the audio routing, encoder output and YouTube dashboard rather than repeatedly replacing the playlist.
If your own speakers go silent but the OBS meter and recording remain active, separate local monitoring from the programme mix. Check which device OBS uses for monitoring and whether the relevant source is set to monitor, but do not assume that a monitor-device fault means the stream is silent. Conversely, a moving meter by itself does not prove that the right audio is routed to the encoder.
A report in the OBS issue tracker illustrates that local monitoring can differ from audio indicated as playing in a stream. It is a user report tied to its own circumstances, not a universal OBS defect or a guaranteed fix. Treat it as a reason to compare the meter, recording and viewer experience, not as proof that your system has the same problem.
Check audio routing and encoder output
When the source appears to play but viewers cannot hear the podcast, trace the audio path in order. Confirm that the source produces audio, that the relevant OBS audio channel is active, and that the channel is included in the audio sent to the stream. Check for a muted source or track, a scene-specific configuration difference, and whether other audio sources are still reaching the live output. Make one change at a time and test again.
Then inspect OBS’s stream output during a short test. Is the encoder reporting errors? Does CPU load change at the dropout? Does the local recording still sound normal? These checks help distinguish a source or mix issue from a problem producing the outgoing stream. Do not infer an encoder fault simply because someone watching remotely reports silence; compare what you can observe locally with the dashboard’s evidence.
YouTube’s live-stream troubleshooting guidance recommends checking the encoder output and whether audio and video sources are routed properly. It also advises checking encoder errors, CPU load and the local archive when the local encoder output looks or sounds poor. Follow its current guidance for the dashboard and encoder version you use.
If you are running a playlist continuously, keep a simple note of which scene was active and which audio source or track was expected to reach the stream. That record can expose a routing difference between scenes without requiring you to rebuild the entire OBS profile. If the problem began after changing scenes, compare those scene settings with a scene in which audio works.
Use YouTube Live dashboard to inspect delivery
Open the Live dashboard while the issue is happening, or review the relevant stream information afterwards. Look for encoder warnings or errors and compare their timing with the dropout you recorded. Dashboard indicators are evidence about the incoming stream, not a direct view of every OBS source property, so pair them with the local recording and what OBS shows.
If the local recording and encoder output both lose audio, return to OBS playback, the source and the audio mix. If local output is healthy but YouTube reports problems, check the dashboard’s encoder status and the outbound connection. YouTube explains that a healthy-looking and healthy-sounding encoder output can point to an issue with the outbound internet connection; that possibility does not establish a network cause for a playlist source that visibly stops inside OBS.
Keep dropped-frame symptoms in their proper place. OBS’s help portal describes dropped frames as a sign that the connection to the remote server is unstable or cannot sustain the configured bitrate, with frames dropped to avoid buffering and keep the stream playing. That guidance concerns delivery to the remote server. It does not by itself explain why an individual local playlist source stopped advancing.
If you find a connection warning, note the time and what the source and local recording were doing then. A network symptom can coincide with a separate source issue, so avoid treating timing alone as proof. The article on restarting a YouTube live stream automatically after a disconnection addresses recovery from a stream disconnection; it is a different problem from a playlist that stops inside OBS.
Test scene changes and playlist behaviour
Once you have a likely branch, reproduce it with a controlled test rather than leaving an uncertain change in a live channel. Use a short playlist with recognisable items, begin a local recording, and make the same scene change that was present when the problem occurred. Observe the source visibility, playback position, meter and recording. If the source stops exactly when it becomes hidden and resumes when shown, test the VLC Visibility Behaviour setting described above.
Next, let the short queue reach its final item. If playback ends there, check Loop Playlist and repeat the test. If the source continues through the queue but a scene transition removes audio from the mix, compare the routing for each scene and the source’s visibility. These tests isolate separate mechanisms; changing several settings together makes it harder to know what mattered.
For a channel that cannot tolerate a test during its main broadcast, duplicate the scene or use a private, controlled test before altering the live setup. Keep a record of the original setting so you can restore it. Check the OBS version, source type and operating system if the documented option is absent or behaves differently; do not assume instructions for one version or plugin apply unchanged to another.
If the first checks do not resolve the issue, collect the source type, OBS version, operating system, the scene active at the time, whether the audio meter moved, and whether the local recording and YouTube dashboard showed a dropout. Those details make a support request more useful than saying only that the playlist stopped. They also keep the next troubleshooting step grounded in evidence from your own setup.
For an always-on channel, the broader choice is whether to keep your own OBS computer and scene controls in the loop or to use a workflow that broadcasts an uploaded file without leaving that computer running. StreamNeo removes the need to keep your computer on for that file-based broadcast, but it does not control OBS scene visibility or local audio routing; those remain OBS-side checks.
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 playlist stop when I change scenes?
If the source is OBS’s VLC Video source, check whether the scene change makes it invisible and inspect Visibility Behaviour. OBS documents a default that stops playback while the source is hidden and restarts it when visible. Other source types can behave differently, so confirm the source before changing settings.
Why can I hear the podcast in OBS but not on YouTube?
The source meter or preview does not prove that the audio is routed to the stream output. Compare a local recording with the viewer experience, then check OBS audio routing, encoder output and the YouTube Live dashboard. Use the timing of any dashboard warnings to guide, not replace, those comparisons.
Why does the playlist stop after the last podcast episode?
Check whether the source is VLC Video and whether Loop Playlist is enabled; a non-looping queue can reach its end. If you are using a regular Media Source for one file, inspect that source’s Loop property instead. Confirm the behaviour with a short test playlist.
What should I note if these checks do not find the cause?
Record the source type, OBS version, operating system, active scene, whether the source meter moved, and what the local recording captured. Note whether the YouTube dashboard showed encoder or connection problems at the same time. That evidence helps distinguish playback, monitoring and delivery without assuming a cause.