A Dacast YouTube stream can disconnect because the encoder-to-Dacast link is failing, or because Dacast's Simulcast connection to YouTube is failing. Compare Dacast Preview with YouTube Live Control Room during the same test before changing settings.
The most important Dacast-specific check is the ingest URL. Dacast says the encoder URL changes when you create a multistream destination, so an old saved URL can become the wrong starting point after YouTube Simulcast is added or changed.
Map the two-hop path first
Your broadcast normally has two separate connections:
- The encoder sends video and audio to a Dacast encoder live channel.
- Dacast Simulcast forwards that existing channel to YouTube using a YouTube ingest URL and stream key.
The encoder is not normally sending directly to YouTube in this arrangement. Dacast is the origin for the live channel, while YouTube is an external destination. That distinction matters because a message saying “YouTube is offline” does not prove that the encoder has stopped sending to Dacast.
Think of the setup as two hops rather than one stream:
| What you observe | Most useful first area to check |
|---|---|
| Dacast Preview and YouTube both stop | Encoder, Dacast ingest URL, local network or source |
| Dacast Preview continues but YouTube stops | Simulcast destination, YouTube URL, key, eligibility or YouTube status |
| YouTube starts and then drops while Dacast remains live | Destination connection, YouTube restrictions or a forwarding problem |
| Only some viewers report buffering | Viewer network, regional connectivity or a shared access network |
| YouTube shows a startup or authentication error | Stream key, destination URL or event configuration |
This is a working diagnosis, not proof of a particular cause. Account settings, timestamps and logs are needed to identify the exact failure. Start by noting the time of a drop and what each checkpoint shows at that moment.
Dacast's Simulcast documentation describes Simulcast as restreaming an existing encoder live channel to an external RTMP destination. It also says the channel must be an encoder live channel rather than an HLS-ingest or VOD Rebroadcast channel, and that the account needs Simulcast credits. Check those conditions if the destination will not start at all.
If you are building a long-running channel from a recorded file rather than producing a live source, first understand the difference in streaming a pre-recorded video as a YouTube live stream. The same distinction helps here: a video file, an encoder, Dacast and YouTube are different parts of the chain.
Compare Dacast Preview with YouTube Live Control Room
Run a controlled test while watching both services. Open the current Dacast channel preview and the relevant YouTube Live Control Room page in separate browser tabs. Do not rely only on a public watch page, because it may lag behind the control room or show a viewer-specific problem.
Start the encoder and wait until Dacast shows the incoming feed. Then watch for the next disconnect. Record four observations:
- whether the encoder still reports an active output
- whether Dacast Preview continues to move and carry audio
- whether YouTube Live Control Room reports incoming data
- whether the public YouTube page is live for a viewer on another connection
If Dacast Preview freezes or ends at the same time as the encoder reports an error, begin with the first hop. Check the current Dacast ingest URL, encoder health and outbound upload connection before changing YouTube credentials.
If Dacast Preview keeps moving while YouTube reports no data or goes offline, the first hop is still active. Move to the Simulcast destination and YouTube settings. Repeatedly restarting the encoder in this situation may interrupt a feed that was successfully reaching Dacast and will not correct a destination problem.
Dacast's multi-destination setup guide recommends checking both the Dacast preview or shared page and the destination page while streaming. Use that comparison as your main troubleshooting test rather than treating every disconnect as an encoder failure.
There is also a timing issue to account for. A destination that has just been added or removed may not appear immediately in every Dacast view. The Dacast API documentation notes that destination information can be temporarily stale or null. Recheck the destination after a short interval before concluding that it was not saved, and avoid making several conflicting changes at once.
Review the Dacast ingest URL after Simulcast changes
If the disconnections began after adding YouTube Simulcast, changing a destination or editing a channel, make this your first configuration check. Dacast's setup guidance warns that the encoder ingest URL changes when a multistream destination is created.
Open the current channel's Encoder Setup in Dacast and copy the URL shown there. Compare it with the URL saved in OBS, your hardware encoder or whichever application is producing the feed. If they differ, replace the old value with the current one and save the encoder configuration.
Do not reuse a URL from another Dacast channel, an old screenshot or a setup that worked before Simulcast was enabled. Dacast's Create Stream reference indicates that the ingest host can vary by region. The URL shown for the current channel is more useful than a remembered host name.
After changing the URL, test the first hop before judging YouTube. Confirm that Dacast Preview receives fresh movement and audio. Then check whether Simulcast forwards that feed to YouTube. This two-stage test tells you whether the URL update restored the encoder-to-Dacast connection or whether a separate destination issue remains.
If your encoder stores a full address in one field and a stream name or key in another, change only the part Dacast identifies as the current ingest URL unless its setup instructions say otherwise. Keep a note of the previous configuration, but do not switch back to it simply because the new setting has not produced a result yet. Allow enough time for the encoder and Dacast to reconnect, then inspect both checkpoints.
For a channel that must run overnight, document the current URL, channel name and encoder profile in one place. This makes it easier to spot an accidental rollback after an update or a restart. It is also useful when another person manages the channel and may otherwise copy an obsolete value.
Verify the YouTube destination URL and stream key
When Dacast stays live but YouTube drops, open the Simulcast destination configuration and verify that the destination is the intended YouTube live event. Check the YouTube ingest URL and stream key together. A valid key connected to the wrong event can look like a connection failure even though the credentials themselves are accepted.
The stream key is a credential, so do not paste it into a public message, screenshot or shared document. If you suspect it has been exposed, create or select the appropriate current key in YouTube Live Control Room and update the Dacast destination. YouTube's encoder troubleshooting guidance recommends obtaining a fresh key when YouTube reports an encoder startup error.
Treat a fresh key as a targeted response, not a universal remedy. It is reasonable when YouTube reports a key, authentication or startup problem. It is not evidence that the key caused a stream which was already running and then disconnected repeatedly. For a midstream failure, keep checking upload stability, encoder output and the two-hop comparison.
Confirm that the Dacast channel is eligible for Simulcast. Dacast documents that the channel must be an encoder live channel and that Simulcast credits are required. If the destination fails to start after configuration changes, check the account's current Simulcast status and any message shown by Dacast rather than repeatedly replacing the YouTube key.
Look for a change in the YouTube event as well. A scheduled event, a reusable stream key and a completed broadcast are not interchangeable in every workflow. Make sure you are looking at the same event whose URL and key are saved in Dacast. If you have several devotional streams, local news loops or study channels, label each event and destination clearly so that a correct key is not paired with the wrong channel.
Check encoder health and upload headroom
Once the current Dacast URL is confirmed, inspect the encoder while the drop occurs. Look at its output status, dropped frames, warnings, CPU or hardware load, available memory and any source errors. If the encoder's local preview freezes or its local recording contains gaps, the problem is before Dacast.
A local recording is especially useful for an overnight test. Let the encoder save the output while it runs. If the recording itself has missing frames, frozen pictures or broken audio at the reported time, investigate the source, storage, encoder settings or computer. If the recording is clean but Dacast Preview drops, focus more closely on the outbound connection and Dacast ingest configuration.
Measure upload capacity, not only download speed. YouTube says the total outgoing bitrate must fit the available upload bandwidth and recommends leaving 20% headroom. This means a connection that appears fast enough in an idle speed test may still be too close to its limit when other people are uploading files, using cameras or backing up devices.
Test under realistic conditions. If the channel uses several cameras, a high-resolution source or another upload running at the same time, include those activities in the test. On a shared office, home or hostel connection, ask what else is using the upload path during the period when the stream drops. YouTube also notes that a connectivity disruption can break a live stream.
If upload capacity is tight, reduce the encoder's bitrate or output resolution, or stop competing traffic. Do not increase the bitrate merely because a stream looks soft. A stable, suitably sized feed is more useful for an always-on channel than a higher setting that leaves no room for network variation.
YouTube's current streaming guidance recommends CBR encoding, RTMP or RTMPS, and a two-second keyframe interval, with no more than four seconds. Its H.264 guidance lists 10 Mbps for 1080p30 and 17 Mbps for 1080p60. Use the row that matches your actual resolution and frame rate, then check that the connection can sustain the chosen bitrate with the recommended headroom. These are YouTube ingestion recommendations, not proof that a Dacast-specific disconnect has one particular cause.
If the source is a looped video, test the transition between files and audio sections. A stream that becomes silent or stops producing frames at the end of a playlist can be mistaken for a network failure. For example, a fireplace channel may remain connected while its audio source becomes quiet, whereas a genuine disconnect will usually show a change in the control room or preview status. The troubleshooting approach in preventing a fireplace stream from going quiet between audio loops is relevant when the picture remains live but viewers report missing sound.
Inspect YouTube Live Control Room and restrictions
YouTube Live Control Room can separate an incoming-data problem from an interruption applied after the feed reaches YouTube. Read the stream-health messages and note whether YouTube reports no data, a degraded input, a stopped broadcast or a policy notice.
Check for copyright and Community Guidelines messages in YouTube Studio. YouTube says a stream can be temporarily interrupted or terminated when third-party content remains after a warning, or when a relevant strike applies. A clean Dacast Preview does not rule out a YouTube-side restriction.
This is also why you should not assume that replacing the stream key will solve every YouTube disconnect. A new key cannot remove a copyright issue, correct an unsuitable channel setting or restore a broadcast that YouTube has stopped for a policy reason. Review the current official YouTube copyright guidance and the notice shown in your own Studio account.
Keep the technical and policy checks separate. If YouTube reports a restriction at the same time that Dacast Preview remains live, preserve the timestamp and message. If there is no notice and YouTube loses incoming data while Dacast remains healthy, return to the Simulcast destination, URL and key, then check whether Dacast reports a forwarding error.
For planned broadcasts, YouTube recommends setting up the encoder at least two hours before an event and starting it at least 15 minutes before airtime. That gives you time to see whether the Dacast preview, YouTube control room and public page agree before viewers arrive. You can also use the live stream scheduling playbook to organise a repeatable pre-broadcast check rather than relying on memory.
Use viewer reports to identify the scope
Viewer reports can tell you whether the failure is shared or local, but they cannot replace the two control-room checks. Ask viewers where they are watching from, whether they are on mobile data or a shared broadband connection, and whether the public page shows the stream as offline or merely buffers.
If people on several independent networks report the same stop at roughly the same time, compare that with Dacast Preview and YouTube Live Control Room. A shared failure across different networks gives more weight to an encoder, destination or YouTube-side problem. YouTube's troubleshooting guidance uses this distinction when discussing errors across different viewer networks versus errors confined to users on a shared network.
If only viewers on one office, campus or household connection are affected, investigate that network before changing the broadcast. A local DNS, firewall, Wi-Fi or bandwidth problem can make a healthy stream appear broken to one group. Ask an affected viewer to test from mobile data, but do not use one successful mobile test to dismiss a separate issue affecting the main audience.
Check from at least one independent connection during a maintenance test. A phone on mobile data can show whether the public page is reachable outside the encoder's broadband connection. For an India-based channel, this can be useful when the encoder, the operator and most viewers share one local ISP, but it still does not establish the root cause by itself.
For an always-on channel, maintain a short incident record: start time, last healthy checkpoint, exact YouTube message, encoder status, Dacast status and affected viewer networks. A record of repeated drops is more useful than a series of unlogged restarts. It also helps support teams compare their logs with your observations.
Make the overnight setup easier to verify
Before a long broadcast, use a representative section of the actual content. Include the normal motion, audio levels, overlays and transitions. A static test image may not expose a source that fails when a playlist changes, while a short moving clip may not reveal an overnight resource problem.
Check the encoder output locally, then Dacast Preview, then YouTube Live Control Room and finally the public watch page. Keep those checkpoints in that order. If you change the Dacast URL, YouTube key and bitrate at the same time, you lose the ability to tell which change affected the result.
YouTube recommends checking the preview before going live, testing failover by stopping the primary source or disconnecting its Ethernet cable, verifying that local archive files are growing, checking access from a mobile device and channel page, and monitoring audio and video quality. Use those as preparation checks, but test failover only when an interruption is acceptable.
If the main problem is that a local computer must stay awake for a recorded loop, a cloud-based YouTube-only service such as StreamNeo removes the need to keep that computer running and can restart a dropped broadcast automatically. It does not diagnose a Dacast Simulcast configuration, and it does not remove the need to check YouTube's current rules, but it is a different operating model when the local encoder is the recurring weak point.
Stop the encoder after ending a scheduled event when your workflow requires that, and confirm that YouTube shows the intended final state. For a continuous channel, document who receives alerts, who can access the Dacast account and where the current encoder profile is stored. Keep stream keys private and remove old destination entries that are no longer used.
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 YouTube disconnect while Dacast stays live?
That pattern points to the second hop rather than proving a fault in the encoder. Check the Dacast Simulcast destination, the YouTube ingest URL and stream key, destination eligibility, Simulcast status and any YouTube Studio message. Confirm that Dacast Preview continues to receive fresh video while YouTube is offline.
What should I check first after adding YouTube Simulcast?
Open the current Dacast channel's Encoder Setup and compare its ingest URL with the one saved in your encoder. Dacast says the URL changes when a multistream destination is created, so update an old saved URL before investigating less specific causes.
Should I create a new YouTube stream key?
Create or refresh the key when YouTube reports a startup, authentication or key error, then update the Dacast destination. A new key is not a general fix for a stream that starts successfully and later drops, so continue checking upload capacity, encoder output and YouTube restrictions for midstream failures.
How can I tell whether viewers or the broadcast are at fault?
Compare reports from viewers on independent networks with Dacast Preview and YouTube Live Control Room. Problems limited to one shared network may be local to those viewers, while simultaneous reports from different networks deserve comparison with the encoder and destination checkpoints.