Ravnur Media Services (RMS) is designed to handle diverse production environments - varying encoder configurations, network conditions, and stream quality levels. If the stream is not behaving as expected, the cause is typically outside the platform: encoder setup, network path, or event configuration.
This page helps you identify and resolve issues at each stage of the live event lifecycle.
Overview
A live event moves through the following states: Stopped → Starting → Running → Stopped.
Normally, you start the event, wait a moment for it to provision, connect your encoder, and the stream runs without stalls or gaps. When the event is stopped - either manually or when it reaches the configured time limit - the live archive becomes available for playback immediately.
If something behaves differently at any point, this page can help you diagnose it. Issues are organized by the stage of the lifecycle in which they appear:
- Startup failures cover cases where the event never reaches a healthy playback state - for example, encoder connection failures or ingest configuration problems.
- Mid-stream failures cover issues that appear after the stream has been running successfully - the event is in Running state, playback was working, and something changed. This includes stream interruptions and playback degradation.
- Post-processing failures cover issues that appear after the event is stopped, when the live archive should be available but is missing, incomplete, or not behaving as expected.
To use this page, identify which stage the event reached and go to the corresponding section.
Player behavior is based on RavPlayer, the player RMS is tested and validated against. If you are using a different player, symptoms may vary, but the API signals, such ashealthDescription, apply regardless of which player you use.
Startup failures
Startup failures occur when the event is in Running state, but the stream has not yet reached viewers. Running state means resources are allocated and the ingest endpoint is active - it does not mean a healthy stream is being received. The most common cause is encoder misconfiguration: incorrect ingest credentials or unsupported encoding settings make up the majority of failed startup cases.
When diagnosing a startup issue, the Live events - Get status operation is your primary signal. Its healthDescriptions field reflects actual ingest activity and indicates whether the stream is ready for playback, even if the event is already in a Running state.
When a healthy stream is received, healthDescriptions fills with ingest details including codec, resolution, bitrate, and connection metrics, which you can use to confirm that the stream is being received and that the manifest is ready for playback.
The table covers common startup issues and how to resolve them:
| Issue | Details | What to do |
|---|---|---|
| The encoder does not connect and returns the hostname/server error. |
Invalid ingest URL. Encoder is pushing to an incorrect ingest link. As a result, the encoder does not connect to the server. |
Retrieve the correct ingest URL from Live event - Get. Verify both the ingest link ( For the expected URL format per |
healthDescriptions: no value.Player message: 'Waiting for stream data...'. |
Invalid stream key The encoder uses the wrong stream key. As a result, the live event does not receive any signal. |
Retrieve the correct stream key from Live event - Get. Verify both the ingest link (url) and the stream key (accessToken) used by the encoder. |
Encoder connects, but no ingest reaches the event.healthDescriptions: no value.Player message: 'Waiting for stream data...'. |
The encoder connects but sends no valid data. RMS accepts the connection but rejects the stream due to an unsupported codec or resolution. | Validate encoder settings against the Encoder setup guide. |
| The encoder cannot connect to the RTMPS ingest. healthDescriptions: no value. |
If network restrictions are in place, a proxy or WAF may be blocking the connection or breaking the RTMPS TLS handshake. | Check proxy/WAF configuration: disable TLS inspection for RTMPS traffic, exclude the ingest endpoint from proxy rules, and ensure outbound TCP is open on the required ports, see Live ingest protocols: RTMP, SRT, RTSP. |
The event is running, but nothing appears on the player.healthDescriptions: includes the following logs -isSourceOnline: false, sourceConnectionsCount: 0. |
No live output or streaming locator was created, so there is no playback path. When a live event is created via the RMS Console, the required resources, such as live output, asset, and streaming locator, are created automatically. When using the API directly, these must be created manually before the event can serve playback. |
Ensure a live output with an attached asset and a streaming locator has been created before starting the event. See Live streaming quickstart for the full setup sequence. |
healthDescriptions returns "Live manifest is not available.". |
Ingest has started, but the playback manifest is not yet generated. Common during startup, while packaging is still initializing. | Query the Live events - Get status endpoint to confirm ingest is active. If ingest is healthy, wait briefly and retry playback. If the issue persists after ingest is confirmed healthy, open the encoder settings, disable b-frames, and set the keyframe interval to a fixed value of 2 seconds. Restart the stream after applying the changes. |
Mid-stream failures
Failures may appear while the event is in Running state and ingest is active - unlike startup failures, the stream reached the player successfully before the issue occurred. Common causes include encoder instability and network drops.
To diagnose a mid-stream issue, refer to the Live events - Get status operation once again.
Check the following fields in healthDescriptions:
-
isSourceOnline:-
false→ ingest has stopped (encoder likely disconnected). -
true→ ingest is active; proceed with further checks.
-
-
videoBitrateandvideoFps:- both
0→ no active input (stream not being received). - non-zero → ingest is receiving data.
- both
The table below covers common mid-stream issues and how to resolve them:
| Issue | Details | What to do |
|---|---|---|
| Playback is active but unstable - stalls, gaps, or audio issues. High CPU load on the machine. |
The stream is being ingested (healthDescriptions contains active stream data with videoBitrate > 0 and videoFps > 0). Playback starts but behaves incorrectly - video stalls, audio loses sync, or audio is distorted. |
Follow the Encoder setup guide. Check CPU and GPU usage on the encoding machine and reduce load if needed. Verify network stability between the encoder and ingest endpoint. |
| Ingest drops mid-stream. Player message: "Waiting for stream data...". healthDescriptions: no value. |
The encoder disconnected. Ingest stopped, and all stream metrics returned to zero. The encoder may reconnect automatically, but playback stays interrupted until ingest is restored. | Open the encoder software and check whether the connection status shows an error or a disconnect. Restart the encoder and re-establish the connection to the ingest endpoint. If disconnects happen repeatedly, check for packet loss or bandwidth drop on the encoder machine's network interface. |
| The event stops unexpectedly (without manual action). | The event transitions to Stopped on its own. No encoder or API action triggered the stop. RMS stops a live event automatically only when the maximum event duration is reached. For trial accounts, this limit is 15 minutes. |
Open RMS Console > Settings > Service Connectors > Live Streaming to check the duration limit that applies to your account. For trial accounts, upgrade to a production deployment to remove the restriction. For production deployments, adjust the maximum event duration before the next stream. |
| Stream latency is too high | Latency is the delay between what the encoder sends and what the viewer sees. Standard latency for RMS live events is 20 seconds or more. Low latency mode reduces this significantly. | If low latency is a requirement, create a new event with the low latency option enabled. Verify your setup is compatible before creating the event. See the Live streaming compatibility matrix - low latency is not supported for all event configurations. Before configuring the encoder for low latency, see Low latency encoding requirements. |
| High resource consumption | RMS bills and consumes resources for the event in Running state - regardless of whether the encoder is connected or sending data. Stopping the encoder does not stop resource consumption. | Stop the live event when the stream is not in use. If you do not need adaptive bitrate output, use a passthrough event type - it consumes fewer resources than an ABR event. |
| The video is blurry, pixelated, or the quality is unstable | The ingest stream bitrate is too low for the selected resolution, or the encoder is dropping frames due to resource or network constraints. The stream remains active, but output quality is degraded. | Verify that the encoder is not CPU-overloaded during streaming - reduce background load on the machine if needed. Check that your ingest bitrate meets the minimum for your event type: for passthrough, match the bitrate to your intended output quality; for ABR 720p and ABR 1080p, see ABR output ladders. If quality remains poor with correct settings, switch the encoding preset to P5 for higher output quality. |
Post-processing failures
Post-processing refers to the steps RMS completes automatically after a live event reaches the Stopped state: stopping the event causes the live output - the component that captures the inbound stream - to stop writing. RMS then finalizes the output asset, the storage container where the content was written during the event.
Once finalized, the content is available as a live archive: a seekable, on-demand version of the stream that viewers can rewind and watch from any point, just as they could during the live broadcast.
The live archive is accessible through the same streaming locator used during the event; the HLS and DASH manifests update automatically. An MP4 file also appears in the output asset once finalization completes.
The table below covers cases where this sequence does not complete as expected:
| Issue | Details | What to do |
|---|---|---|
| Playback of a live archive works, but only a single quality (no ABR) | Expected behavior for passthrough live events. Only one quality level is recorded in the live archive. | Start transcoding the output asset - apply a multiple-quality preset. |
| MP4 file not yet available, but playback works | The live archive is still being finalized. The HLS/DASH manifest is ready and streaming works, but the MP4 file has not yet appeared in the asset. Finalization takes longer for high-resolution, high-bitrate, or extended-duration streams - typically no longer than the stream duration itself. |
Wait and check the asset again after some time. If playback is working, the live archive is intact, and the MP4 will appear once finalization completes. |
| Output asset exists but contains no recorded files; playback doesn't work | In rare cases, the output asset is present after the event ends but contains no content - playback URLs return nothing. | Before contacting support, confirm that your encoder was actively sending data during the event. If no signal is received, no live archive will be available. If ingest was active and the output asset is still empty, contact Ravnur support with the live event name and the time the event was stopped. Reaching out within 2 days gives the best chance of a successful recovery. |
Didn't find your case or the issue persists? Ravnur support can help.