When a Restreamer YouTube stream disconnects, first identify which product you use, then find where the broadcast path stops: at the source, in Restreamer, on the outbound network or at YouTube. A bitrate reading alone cannot show that the whole path is healthy, so compare timestamps and errors from both Restreamer and YouTube before changing settings.
The name can mean Datarhei Restreamer, which you operate in your own setup, or Restream, a separate hosted multistreaming service. The screens, network path and available continuity features differ. The checks below start by separating those cases, then isolate the failing segment rather than treating any one setting as a universal fix.
Identify which Restreamer you mean
Check the product name and the page where you configure the broadcast. Datarhei’s Restreamer documentation describes connecting to YouTube with the channel’s current RTMP connection details and displaying outgoing bitrate in its main window. Restream is a separate service with its own encoder guidance and features. Advice for one product’s dashboard or fallback options should not be assumed to apply to the other.
If you use Datarhei Restreamer, write down what feeds it (for example, a local file or an encoder) and how its output reaches YouTube. If you use Restream, identify the encoder or source sending to Restream and the destination channel configured there. In either case, do not copy an example RTMP URL or stream key from documentation: use the current connection details shown for your own YouTube setup, and keep the key private.
This distinction matters especially for continuity. Restream documents a disconnect-protection feature for its RTMP/SRT setups, with a fallback video configured before going live; its documentation does not establish that Datarhei Restreamer integrates with that feature. Nor should you assume either product will preserve the same YouTube event or archive after a break. Check the behaviour of your installed version and current event configuration.
Map the path before troubleshooting
Draw the broadcast path in order, with one box for each hand-off. A Datarhei example might be: media file or upstream encoder → Datarhei Restreamer → internet connection → YouTube Live. A Restream example might be: encoder → Restream service → YouTube. Mark where video is produced or transformed and which network connection carries the final output.
Then record what you can observe at each point. When the next interruption happens, note the time and time zone; whether the source is still available; whether Restreamer reports an outgoing bitrate; any process error; and YouTube’s stream-health message at the matching time. A displayed bitrate means data is being sent at that point, not necessarily that YouTube is receiving a usable stream or that viewers can see it.
Keep a short incident log rather than relying on memory. For a channel that runs overnight, note when you checked before bed and what you saw in the morning, but avoid claiming an exact failure time unless the logs provide it. If the source still plays locally while YouTube reports a problem, that is useful evidence; if both stop together, begin closer to the source. This path map is also useful when you need to explain the setup to someone who maintains it.
Check that the source remains available
Start at the input, before adjusting YouTube settings. Confirm that the file, playlist or upstream encoder is still producing the expected picture and sound. If the source is a file on a computer or mounted drive, check that it remains accessible for the entire run and that the machine or storage is not sleeping, disconnecting or losing the file path. If another encoder supplies the feed, inspect its own status and output at the time of the interruption.
A useful test is to observe the source and Restreamer at the same moment. If the source has stopped or gone silent while the Restreamer output also changes, investigate that input first. If the source continues cleanly but the Restreamer process reports an input error, the problem may lie at the hand-off or in how the input is configured. Change one thing at a time and keep the timestamps, so a restart does not erase the evidence you need.
For an OBS-based sermon or music loop, the source chain can include a media source and audio devices as well as the video file. A guide to keeping OBS audio sources from dropping in a 24/7 radio stream is relevant when the picture remains but sound disappears. For a simple prerecorded loop, the church sermon loop setup using an OBS media source can help you check the source arrangement before treating the YouTube connection as the culprit.
Inspect Restreamer processing and publication
For Datarhei Restreamer, open the process details around the failure window and inspect the reported state and errors. Datarhei’s basic troubleshooting guidance recommends checking process details and including useful project information when reporting a problem. Record the Restreamer version, the input type, the destination and the exact message. Remove credentials from any screenshots or configuration you share, and never include a stream key in a public issue or support ticket.
Check whether the process is still receiving its input and whether it reports an outgoing bitrate. If the process has stopped, note the reason before restarting it. If it is running but the bitrate has fallen or disappeared, compare that point with the source status. If it reports output while YouTube shows a health error, keep both observations: they indicate different sides of the hand-off and are not contradictory.
Next, compare the actual output format with YouTube’s current encoder settings and bitrate recommendations. YouTube specifies H.264 video and AAC audio, and its bitrate recommendations vary with resolution and frame rate. Its guidance, for example, lists 4–10 Mbps for 1080p at 60 fps and 6–30 Mbps for 1440p at 60 fps; these are format-specific ranges, not interchangeable targets. Check the current page for the format you selected rather than copying a figure from another resolution or frame rate.
Review resolution, frame rate, video and audio codec, bitrate, rate control and keyframe settings together. A mismatched audio codec can produce an error even when the picture appears fine. Avoid changing several parameters at once: if a format change is followed by a stable run, you otherwise will not know which change mattered. A configuration that works on a short test may still need observation over the usual overnight period before you rely on it.
Check outbound network stability
If the source and Restreamer process appear intact, test the connection that carries the output to the streaming service. Measure upload performance on the relevant route and at the time the issue is likely to occur; a result from another location, connection or time may not represent the path in use overnight. Compare the selected video bitrate with the upload headroom available while other devices or applications are also using the connection.
Restream’s Help Center article on poor encoder stream quality, dated July 15, 2024, recommends at least 10 Mbps upload and ideally more than 25 Mbps to Restream’s servers, with video bitrate no higher than half the upload speed. It also suggests trying Ethernet and lowering encoder settings if instability remains. These are Restream’s troubleshooting recommendations for its service context, not a diagnosis for every Datarhei deployment or a guarantee. The stated upload-speed and bitrate figures are not YouTube requirements.
Where practical, try a wired Ethernet connection in place of Wi-Fi and observe whether the symptom changes. If the connection remains unstable, lower one output demand at a time, such as bitrate or resolution, and compare results against YouTube’s current guidance for that format. A lower bitrate may ease congestion but can reduce picture detail; reducing resolution or frame rate also changes what viewers see. For a channel where picture quality matters, make a deliberate compromise rather than lowering settings without checking the result.
You can use the same method for a source that travels over a cloud or remote connection: test the upload on the machine or service that actually sends the final feed, not just the office broadband where you happen to be monitoring. If the stream is generated on a home PC, power settings and a Wi-Fi link may matter; if an upstream encoder sends to Datarhei, there may be two separate network segments to inspect. Troubleshooting one link does not validate the other.
Compare with YouTube Live Control Room
Open YouTube Live Control Room and check the stream-health indicator and timestamped errors for the same period as the Restreamer log. YouTube’s live streaming error messages guide explains that the Live Dashboard and Live Control Room check the stream being sent to YouTube. It distinguishes critical errors from moderate ones and keeps errors visible when they have not been fixed. Use the actual message to choose the next check instead of interpreting a brief status change in isolation.
If YouTube reports a format problem, return to the codec and output settings. If it reports an unstable or missing feed while Restreamer still reports output, investigate the outbound path and the hand-off to YouTube. If YouTube appears healthy but viewers report a missing picture or sound, compare the report with the live preview and the source; a viewer’s device or playback route may be a separate issue. A matching timestamp is more informative than a general report that the stream “keeps disconnecting”.
The comparison is particularly useful when an operator notices a bitrate number and assumes that the broadcast is fine. Restreamer’s outgoing figure describes what its interface can observe at its end. YouTube’s health messages describe what YouTube detects as it receives the stream. Neither view alone proves what every viewer sees, but agreement or disagreement between the two helps narrow the failing segment.
Narrow the failing segment before changing settings
Use the observations to make a small decision table. The wording in your own logs may differ, but the direction of the next check should follow the evidence rather than a favourite fix.
| What you observe at the failure time | Segment to investigate first | Next useful check |
|---|---|---|
| The source stops or becomes unavailable, and Restreamer loses input | Source or input hand-off | Check file access, upstream encoder status and input errors |
| The source remains available, but Restreamer reports a process error or loses output | Restreamer processing or publication | Inspect process details, version and output configuration |
| Restreamer reports output, but YouTube reports missing or unstable input | Outbound network or YouTube hand-off | Compare timestamps, test the sending route and inspect YouTube’s exact error |
| YouTube reports a codec or format error | Output format | Match codec, audio format and settings to current YouTube guidance |
| Both sides appear healthy, but a viewer reports a problem | Viewer playback or an intermittent event | Check the live preview and ask what device and time the viewer observed |
This is a way to select the next test, not proof of a root cause. For example, a clean source and a Restreamer bitrate reading do not rule out packet loss between Restreamer and YouTube. Equally, a YouTube error does not by itself show whether the encoder, the network or a format setting caused it. Preserve the original configuration, change one variable, and collect another comparable observation before making a further change.
If you need to escalate, send the Restreamer version, a description of the source-to-destination topology, the failure timestamps and time zone, relevant process details and matching YouTube health messages. Include configuration only after removing credentials and private stream keys. This gives a maintainer something concrete to compare without exposing channel access. For a channel assembled from prerecorded material, the guide to looping a YouTube live playlist over one RTMP connection may also help clarify which component owns playback and which one publishes the feed.
For an always-on channel, plan how you will notice and respond to a break rather than assuming a reconnect policy. Datarhei’s cited materials do not establish a universal retry interval, automatic reconnection behaviour, event reuse or archive outcome for every Restreamer deployment. Restream’s documented fallback video is a feature of that separate service and its stated availability is limited to Business and custom Enterprise plans, as listed on Restream’s site in September 2026. Verify the current product documentation and your own YouTube event behaviour before relying on continuity arrangements.
If the main difficulty is that a computer must stay available to feed the broadcast, StreamNeo removes that particular operating burden by turning an uploaded file into a YouTube live stream that can run with your computer off; it does not diagnose or fix a Datarhei Restreamer installation, and it is YouTube-only.
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
Should I restart Restreamer as soon as YouTube disconnects?
Not before recording the time and the visible errors, if you can do so safely. A restart can restore the output, but it may also remove useful evidence about whether the source, process or network failed. Record the state on both sides, then restart if needed to restore the broadcast.
Does an outgoing bitrate mean YouTube is receiving a healthy stream?
No. It shows activity at the point Restreamer measures, but it does not prove that YouTube receives a valid, stable feed or that viewers can play it. Compare that reading with the same-time process details and YouTube Live Control Room health messages.
What bitrate should I use for a 24/7 YouTube stream?
There is no single target for every channel. YouTube’s recommendations depend on resolution and frame rate, while the available upload headroom depends on the connection carrying the stream. Match the output to YouTube’s current settings page and test whether the chosen bitrate remains stable on the actual route.
Will a fallback video keep my Datarhei Restreamer broadcast live?
Do not assume so. Restream documents fallback video for its own RTMP/SRT disconnect-protection feature, but that does not establish that the feature applies to Datarhei Restreamer. Check the documentation for your product and installed version, and verify what happens to your YouTube event after an interruption.