A Castr YouTube stream that keeps disconnecting can fail on more than one part of the journey. First find out whether the source feed is disappearing before it reaches Castr, or whether Castr is still receiving it while YouTube stops receiving or starting the broadcast.
At the next interruption, note the time and check whether the Castr preview stopped as well. That one observation gives you a useful starting point, although it does not prove the cause by itself.
Map the two connection legs
There are two separate connections to examine:
- Your encoder or streaming software sends the source to Castr.
- Castr sends that incoming stream to YouTube.
The first leg includes the computer running OBS or another encoder, the local network, the upload connection, and the route to Castr's ingest server. The second includes the Castr destination configuration and YouTube's live-streaming flow.
This distinction matters because changing a YouTube stream key will not repair an encoder that has stopped sending. Equally, reducing your encoder bitrate will not correct a disabled YouTube destination or an unfinished Go Live step.
Use the Castr preview as an observation point. If the preview and input health stop at the same time as the public broadcast, begin with the encoder, source network, and ingest path. If the preview remains active while YouTube is missing the stream or has stopped the broadcast, inspect the destination and YouTube setup first. This is a practical inference from the separate source preview and destination controls, not a guaranteed diagnosis.
Castr's own Help Center guidance says that many quality problems originate with the source encoder or streaming software rather than Castr. Treat that as general vendor guidance, not as proof that your particular disconnect starts at the source. The useful question is what the available evidence shows during your interruption.
For a channel that loops prerecorded material, it can also help to separate a source-file problem from a transport problem. The guide on keeping a YouTube playlist streaming when one video fails covers a different failure mode, but the same principle applies: identify which part has actually stopped before rebuilding the whole setup.
Check what stopped at the moment of failure
Do not begin by changing several settings together. The next time the stream disconnects, write down the clock time, the programme or file that was playing, whether the Castr preview was live, and what YouTube showed. A short note such as “preview stopped at 02:14, bitrate fell first, YouTube still showed live” is more useful than “it disconnected overnight”.
Castr's setup documentation exposes a preview and stream statistics. Its health charts can be viewed during a live session and, according to Castr's Help Center as listed in March 2026, can also be reviewed for a past session. Castr says session data is retained for 10 days, so inspect or save the relevant information promptly rather than waiting for the next failure.
Compare these observations:
| Observation | What it may suggest | Next place to investigate |
|---|---|---|
| Castr preview disappears | The source, local connection, or input path may have failed | Encoder, upload capacity, ingest server, and protocol |
| Preview remains live but YouTube is absent | The destination or YouTube start flow may need attention | Castr destination settings and YouTube Studio |
| Bitrate falls sharply before the drop | The source may not be delivering a steady stream | Encoder load and upload stability |
| Frame drops rise before the drop | The encoder or connection may be struggling | CPU use, source settings, and network path |
| YouTube shows an error while Castr remains healthy | The destination may be rejecting or not starting the feed | Stream key, destination state, and Go Live page |
These are clues rather than rules. A stable preview does not establish that YouTube is healthy, and a preview failure does not identify whether the computer, Wi-Fi, router, ISP, or Castr ingest route is responsible.
YouTube's official live-streaming troubleshooting guidance is worth checking alongside Castr's charts because the platform may display a destination-side message that is not visible in the encoder.
Check the encoder and streaming software
Open the encoder configuration and confirm that it is still sending to the intended Castr endpoint. If you use OBS, check the service or custom server entry, stream key, output mode, bitrate, keyframe interval, encoder, and audio settings. Do not paste a stream key into the article, a support ticket, or a screenshot that will be shared publicly.
Castr's troubleshooting guide, published 18 March 2026, gives the following starting recommendations for a source encoder:
- H.264 video
- AAC audio
- Constant bitrate, or CBR
- A 2-second keyframe interval
- 30 FPS, or 60 FPS when the connection supports the higher bitrate
- 128 Kbps stereo audio
The same Castr guidance lists 3,500–6,500 Kbps for 1080p video and 2,500–4,000 Kbps for 720p. These are Castr's starting recommendations as listed on its site in March 2026, not universal requirements for every YouTube stream. A devotional image loop, a camera scene, and a detailed gaming replay do not place the same demand on an encoder.
Look at the encoder's own statistics during a test. A high CPU load, rendering lag, skipped frames, or an encoder that pauses can make the source unstable before Castr has a chance to deliver it onwards. If you are looping video in OBS, the advice on reducing CPU usage when looping videos for YouTube may help you examine the local workload without changing the destination configuration.
Then compare Castr's bitrate and frame-rate charts around the interruption. Castr says a flat bitrate graph is characteristic of CBR in its troubleshooting guidance. A sudden bitrate fall can indicate a connection problem, while frame drops may indicate that the encoder or connection is struggling. Neither pattern identifies the exact component, but the timing helps distinguish a source-side event from a destination event.
Change one setting at a time. For example, if you are using 60 FPS but have no reason to need it, test 30 FPS at a suitable bitrate. If the source is already using CBR, do not switch to variable bitrate simply because a disconnect occurred. Record the original setting so that you can reverse the test.
Review source network and input stability
Castr recommends broadcaster upload capacity of at least 1.5 times the stream bitrate. Its example is a 5,000 Kbps stream requiring at least 7,500 Kbps, or 7.5 Mbps, of upload capacity. This is a source-upload recommendation from Castr's Help Center as listed in March 2026. It is not the same as the download speed recommended for viewers watching the broadcast.
The margin is needed because a connection can test well for a moment and still become unreliable when another device uploads photos, joins a video call, syncs cloud files, or sends security-camera footage. Pause competing upload activity during a controlled test, and check whether the issue happens only at busy times.
Where practical, connect the broadcaster by Ethernet rather than Wi-Fi. Wireless interference, signal changes, and latency spikes can affect a continuous upload even when ordinary browsing appears normal. A Cat6 Ethernet cable may be useful if your computer and router can be connected directly. The cable only enables a wired connection; it cannot correct encoder settings, a bad key, a destination error, or every problem on the network.
Restarting a router may clear a temporary local problem, but it is not a diagnosis. If the stream fails again, note whether the failure affected other internet activity and whether the encoder recovered by itself. For a channel running from India or another location with variable evening congestion, compare the source statistics at different times rather than relying on one speed test.
Castr also recommends choosing an ingest server close to the broadcaster. A distant ingest point can add latency and increase the chance of packet loss. If your dashboard allows you to select the server, make a note of the current choice before testing a nearer alternative. A change that appears helpful in one short test still needs to be run for the expected event duration.
Inspect Castr's connection diagnostics
Use Castr's input preview, stream statistics, and health charts together. The preview answers whether Castr is visibly receiving the source. The charts add timing information: did bitrate flatten, fall, or stop, and did frame drops increase before the interruption?
Review both a live test and the past session where the disconnect occurred, if the data is still available. Castr lists 10 days of session-data retention in its Help Center as of March 2026. Save screenshots with the time visible, but hide stream keys, private URLs, and other credentials.
If the source remains stable but Castr reports an input problem, test the ingest path rather than immediately rebuilding the YouTube destination. Castr documents RTMP or RTMPS, SRT, and WHIP source modes in its setup guidance. When an RTMP source remains unstable, Castr suggests trying SRT, which it describes as intended for unreliable networks and packet-loss recovery.
A protocol change is a controlled experiment, not a guaranteed repair. It may require a different source configuration, and it can introduce a new configuration error. Keep the original RTMP details, confirm the new endpoint carefully, and compare the charts under similar content and network conditions.
If your channel must continue while you investigate, plan continuity separately from diagnosis. Castr's setup guide describes an encoder-level backup using a second encoder and a file-level backup using a backup VOD. It says backup must be configured while the stream is disabled and that enabling it changes stream keys. Check the current dashboard instructions before changing a production stream, and do not treat backup as evidence about the original fault.
For owners considering a different operating model, software for streaming prerecorded videos to YouTube Live explains why the source computer, file, and platform hand-off should be assessed separately.
Check the YouTube destination status
Castr documents two YouTube connection methods: an API connection, or a YouTube server and stream key. Confirm which method your destination uses before following instructions written for the other one.
Castr's setup guidance recommends keeping the added destination off while the stream source is offline, then turning it on when the encoder source is live. This avoids asking the destination to start from an empty input. In YouTube Studio, confirm that the intended stream is selected and that the broadcast is actually started rather than merely configured.
For a server-and-key connection that does not start, Castr's older reconnect guidance suggests deleting and re-adding the destination, replacing the stream key, and remaining on YouTube's Go Live page to start the broadcast. That article was published in 2022, so labels and screen layouts may have changed. Check the current YouTube Help instructions for creating a live stream before making a production change.
Do not rotate a working key casually. If you replace it, update the source configuration and any backup encoder that uses the old value. A key is sensitive information, so keep it out of screenshots and support conversations unless the recipient specifically provides a secure method and asks for it.
A useful controlled test is to confirm the encoder feed in Castr with destinations off, then enable an unlisted or private YouTube broadcast. Monitor Castr Input Health while watching the YouTube status. Castr recommends rehearsing privately or unlisted and running the test for the expected event duration, rather than declaring success after a short preview.
If the Castr preview stays healthy while YouTube fails, record the YouTube message, the destination method, the time, and whether the broadcast was waiting on the Go Live action. This evidence is more useful than repeatedly restarting the encoder.
Try reversible settings checks and retest
Once you have captured the original state, test the least disruptive change first. Keep the test private or unlisted where appropriate, and use the same programme content that normally causes trouble. A setting that survives a short menu loop may still fail after several hours.
A sensible order is:
- Remove competing uploads and use a wired connection if available.
- Confirm CBR, the intended keyframe interval, and a bitrate within Castr's starting range for your resolution.
- Reduce frame rate from 60 FPS to 30 FPS if the higher frame rate is not necessary for the content.
- Check the selected Castr ingest server and test a nearer one if the dashboard provides that choice.
- If RTMP remains unstable, test SRT with the source settings documented by Castr.
- With the source live, enable the YouTube destination and complete the current Go Live flow.
Do not change resolution, frame rate, bitrate, protocol, stream key, and destination method all at once. If the stream then survives, you will not know which change mattered. If it fails, you will have more possible mistakes to undo.
Run the test for the duration you actually need. A 24/7 devotional or ambience channel should test beyond the first song or file transition. A local news loop should include a scheduled hand-off if one is part of the normal workflow. Keep an eye on Input Health, bitrate, frame drops, and the YouTube status rather than watching only the public player.
If a long test is stable, restore one original setting at a time only if you need to identify the cause. If it fails again, return to the last known-good configuration and preserve the charts. StreamNeo can remove the need to keep a personal computer running for a YouTube-only uploaded-video stream, but it does not remove the need to check the source file, channel settings, and YouTube's current requirements.
Collect details for support
Contact Castr or YouTube support with a concise timeline. Include the date and time with your time zone, the exact symptom, whether the Castr preview stopped, the destination method, encoder software and version, protocol, resolution, frame rate, video and audio bitrate, and whether the source used wired or wireless networking.
Attach relevant health-chart screenshots or exported data if available. Mark the point of the disconnect and include the bitrate and frame-rate behaviour immediately before it. Redact stream keys, passwords, private URLs, personal contact details, and anything else that could be used to access the channel.
Say what you already tested and what changed. “RTMP failed at 02:14, preview stopped, wired test at the same settings failed again” is actionable. “Castr keeps disconnecting” gives the support team much less to work with.
If the preview stayed live, state that clearly and include the YouTube error or status message. If the destination was added through an API connection rather than a server and key, say so. The team may need to investigate different parts of the setup depending on that distinction.
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
Does a Castr disconnect always mean my internet is the problem?
No. The failure may involve the encoder, local network, Castr input or destination configuration, or YouTube's live flow. Check whether the Castr preview and input health stopped before assigning the fault to any one part.
Should I change the stream key first?
Only if the evidence points towards a destination or key problem, and only after recording the current configuration. If Castr's preview is also failing, changing the YouTube key is unlikely to address the source-side symptom. Keep the new key private and update every encoder or backup that uses it.
Is SRT guaranteed to stop frequent disconnections?
No. Castr suggests SRT as a protocol to test when an RTMP source remains unstable, particularly on unreliable networks. It still requires correct configuration and a source connection that can send the stream.
How long should I test before calling the stream stable?
Test for the expected event duration and include normal file or programme transitions. Castr recommends monitoring Input Health during the rehearsal, preferably with a private or unlisted YouTube broadcast. A short preview cannot establish that an overnight or always-on stream will remain connected.