A black screen on a YouTube 24/7 stream running from Vultr does not identify its own cause. Find the last place the video is visible—your media source, OBS Preview, OBS Program output or YouTube—before changing settings.
For a file-based channel, first confirm the correct scene is live and the video file is present, playing and set to loop. Then compare what OBS is sending with the messages in YouTube Live Control Room; investigate CPU, encoder or network settings only if those checks give you a reason.
Find the last place video is visible
Treat the symptom as a chain rather than a single fault. A video file feeds an OBS source, that source appears in a scene, the active scene produces Program output, OBS encodes and sends that output, and YouTube receives it. A blank player could originate at any point in that chain, so start at the earliest point you can inspect and move downstream.
Use the same moment in the same stream when comparing screens. If the file is visibly playing in OBS Preview, but the YouTube player is black, the source itself is less likely to be the point where video disappears. If Preview is already black, changing YouTube’s bitrate cannot make that source visible. If OBS’s Program output is black too, check the scene and its sources before investigating the receiving end.
Write down what you observe: whether the source appears in Preview, whether Program shows the intended scene, whether OBS reports dropped frames, and what Live Control Room says about stream health. Also note whether the image disappears immediately or only after a remote desktop disconnect, a scene change or a media loop. These are observations, not proof of a cause, but together they narrow the next check.
This sequence is useful whether the channel carries bhajans, a study loop, a local news slate or another continuous programme. If your setup is still being tested, the pre-flight checks for a YouTube RTMP setup provide a related way to verify the complete path before you rely on it overnight.
Check OBS Preview and the active Program scene
In OBS, look at the intended scene and confirm that the source is present and enabled. A source may exist in the scene list but be hidden, covered by another source, or assigned to a different scene from the one currently being sent. Check its visibility control and ordering, then see whether it actually displays moving video in Preview.
Preview and Program are not interchangeable. In studio mode, Preview is a staging view; the scene does not become the live output until you transition it to Program. Without studio mode, the selected scene may already be the output, but you should still verify that it is the scene YouTube is meant to receive. Vultr’s Ubuntu and OBS streaming-server guide describes verifying that sources feed correctly and transitioning the intended scene to the live Program screen.
A useful split is simple: if the source is black in Preview, inspect that source and its media first. If Preview is right but Program is black or shows a different scene, correct the scene selection or transition. If both OBS views show the intended image, leave the scene alone for now and check the output and YouTube’s receiving status.
For a remote Vultr desktop, do this while connected to the same OBS session that runs the stream. Avoid opening a second OBS instance or changing scenes in a session that is not controlling the live broadcast. If you suspect the stream changes when you disconnect, record the current image first; later, test the disconnect as a separate change rather than combining it with other troubleshooting.
Verify the media file and loop setting
A 24/7 file-based channel depends on more than a source name in OBS. The file must exist at the path OBS expects on the VPS, and the source must be able to read and play it. A path that points to a local computer, a moved file or a mounted location unavailable to the running session may leave a media source blank or stalled. Confirm the file is on the server and inspect the source’s configured path.
Then test playback in Preview. Seek or restart the media if appropriate and confirm that the picture advances rather than showing a still frame. Vultr’s Broadcaster Marketplace App guide recommends checking media playback in OBS Preview and says to enable Loop for automatic replay. Verify that setting on the source you are actually using, not on a similarly named source in another scene.
A loop problem can be confused with a black-screen problem. Watch what happens at the end of the file: does the media restart, stop on a final frame, or go blank? Let the stream reach the boundary only if it is safe to do so, and note the result. If video disappears at that point, check playback and loop behaviour before touching encoder or network settings.
If the source works during a brief preview but fails after an OBS restart or remote-session change, check that the file path remains available to the same account and session. Do not assume a visible desktop file is accessible to every process or login. For symptoms tied specifically to a playlist boundary, the guide to a 24/7 stream freezing when a large video repeats may help distinguish a repeat issue from an absent source.
Inspect OBS output before changing settings
Once Preview and Program show the intended moving image, check whether OBS is producing the output you expect. Watch the live Program view and OBS’s status indicators while the stream is running. If OBS offers recording as a safe local check, a short recording can help establish whether its encoded output contains the picture; do not stop a broadcast you need to keep live just to perform that test.
If the Program view is visibly black, return to scenes and sources. If Program is correct but a recording or other available output check is black, the problem is later in OBS’s output path. Look for relevant encoding or rendering messages and logs, and note whether the issue starts after a transition, a media restart or a change in the remote session. Do not infer a CPU fault merely because the server is running OBS.
Vultr’s Ubuntu guide discusses resource requirements and recommends starting with 720p for a server with at least two vCPUs; it also advises monitoring CPU and frames. These are Vultr’s setup recommendations, not universal requirements for every OBS workflow. Only use them as context if OBS shows sustained resource pressure or dropped frames. A black Preview with a healthy CPU reading still points you back to the source or scene.
Check the remote-session question on its own. Vultr’s Ubuntu guide asks users to disconnect the Ubuntu desktop and verify the stream remains active. The guide also describes a session-lock issue and a tscon workaround for a separate Windows Server and RDP setup. Do not apply a Windows remedy to Linux. First identify the VPS operating system and the remote connection type, then observe what actually changes when you disconnect.
Compare YouTube Live Control Room health
Open YouTube Live Control Room while the stream is active and compare its stream-health status and messages with OBS’s output. YouTube’s encoder guidance recommends testing with audio and movement similar to the real stream and monitoring stream health. Use the current messages as diagnostic evidence, and consult the official guidance again before relying on particular encoder recommendations because they can change.
If OBS Program is already black, a message about ingest does not restore the missing picture; solve the upstream image problem first. If OBS shows a moving image but YouTube reports a stream or ingest problem, keep the source and scene unchanged while you examine the message. Check that the stream is going to the intended YouTube broadcast and that the configured key matches the one shown for that event. The stream-key mismatch troubleshooting guide covers that specific check.
A healthy status is informative, but it does not prove that the player is showing the intended content at every moment. Verify the public or preview player as well, allowing for processing and display delay. Compare the image at the same time rather than judging an OBS frame against a YouTube screen that has not caught up.
Keep a short record of the exact message and when it appeared. “OBS is streaming” alone does not establish that YouTube is receiving the expected video, and a black player alone does not tell you whether OBS sent black frames or YouTube rejected the stream. The distinction determines which part of the chain to investigate next.
Follow diagnostic clues for encoder or network issues
Change encoder settings only when the evidence points to an output or compatibility problem. Relevant clues include OBS logs that name an encoder failure, a non-black OBS Program view paired with YouTube messages about stream configuration, or output that fails to reach the receiving service. Check YouTube’s current official encoder page for supported settings before adjusting codec, keyframe interval, frame rate or bitrate. Do not copy settings from a different resolution or codec without checking that they apply to your stream.
CPU is a clue when OBS reports encoding lag, frames are being missed, or resource use is persistently high at the time the image fails. Vultr’s guide cautions that higher resolution and frame rate require more processing and recommends reducing resolution or moving to more vCPUs when its diagnostics support that conclusion. Its cited CPU guidance is specific to Vultr’s guide; it is not a universal threshold or evidence that CPU caused a black screen. If the source and Program remain correct and no resource symptoms appear, do not lower resolution as a guess.
Network changes are justified by connection evidence, such as OBS’s dropped-frame statistics or messages from YouTube about receiving the stream. OBS’s connection troubleshooting guide explains that dropped frames indicate an unstable connection to the remote server or a connection unable to sustain the configured bitrate; it suggests lowering bitrate as a diagnostic step. That can help test a connection symptom. It cannot repair a missing media file or a hidden OBS source.
Separate connection symptoms from a fully black image. Buffering, interruptions or dropped frames can point to transmission trouble, while steady, black output may have an upstream source or scene explanation. Do not prescribe a lower bitrate, different encoder or new resolution until the relevant OBS or YouTube evidence supports testing it. Change one variable at a time and retain the original setting so you can reverse a test that does not help.
Retest after each change
After correcting a source path, visibility setting, scene transition or loop option, check the complete chain again: media playback, Preview, Program, OBS output and YouTube health. If the image returns, leave the other settings alone for that test. If it does not, note the last visible point and continue downstream only when the upstream checks pass.
For a network or encoder adjustment, use a representative portion of the actual programme. A devotional loop with a static title card may not exercise the same video movement as a sequence with animation; audio should also be present if it is part of the channel. YouTube’s encoder documentation recommends testing with audio and movement similar to the real stream, rather than assuming a brief still image is a sufficient test.
If remote-session disconnection is suspected, first establish a working picture, then disconnect the desktop without changing anything else. Check whether OBS remains active and whether YouTube continues receiving video. Reconnect and compare. This test tells you whether session behaviour is relevant to your setup; it does not establish a general rule for all Vultr operating systems or remote desktop types.
Keep a basic change log: time, symptom, one change, and result. For a long-running channel, a short retest now is less costly than stacking several speculative changes and losing track of the one that mattered. If the file and scene are sound but the stream cannot be monitored or restarted reliably from your own computer, StreamNeo can remove that particular burden by running an uploaded file as a YouTube stream without keeping your computer on.
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 is OBS Preview black but YouTube still shows a stream?
A live connection can continue sending output even when the intended media source is blank, stalled or hidden. Check the source path, visibility and playback in Preview, then confirm that the intended scene is on Program. A stream being active is not the same as the picture being correct.
OBS is streaming, but YouTube shows a black screen. What should I check first?
Compare OBS Program with YouTube’s stream health and player at the same point in time. If Program is black, stay with the source and scene checks; if it is correct, inspect YouTube’s messages for receiving, key or encoder clues. Avoid changing bitrate without a connection symptom.
Could disconnecting from the Vultr VPS cause the image to disappear?
It is possible for remote-session behaviour to matter, but the answer depends on the operating system and connection type. Verify a working stream first, then test disconnecting without changing other settings. Use guidance for the specific VPS setup rather than applying a Windows RDP workaround to Linux.
Should I lower the resolution or bitrate to fix a black screen?
Only if OBS or YouTube diagnostics point to resource pressure, encoding trouble or a connection that cannot sustain the stream. A black media source or wrong Program scene will not be repaired by lowering those settings. Make one evidence-based change, retest the full chain and revert it if the symptom is unchanged.