Network issues

If Dropped Frames (Network) increases in OBS statistics, the connection to the server cannot sustain the chosen bitrate or is unstable. This counter differs from rendering and encoding skips. Start with OBS log analysis and unstable bitrate checks. See the OBS troubleshooting guide for network frame drops.

Check the StreamVi server

Open the selected project's main page and click RTMP & Key.

Click Run ping tests. Compare several servers' latency. Ping measures response delay; choosing a bitrate also requires an upload-speed check.

Click Speed Test in the server's row.

Wait for completion and review the upload graph in the speed test result. Compare sustained speed, rather than a single peak. Repeat checks under similar conditions when comparing servers.

Check the bitrate

In OBS, open Settings → Output and check the bitrate. Leave headroom below sustained upload speed and account for platform limits. If a test shows 22 Mbps, a 30,000 Kbps stream already exceeds the measured speed. Lower the bitrate and check the network frame-drop counter again. One speed-test result does not guarantee a stable long broadcast. See OBS recommendations.

An external speed test and a StreamVi test may use different servers. A high result to another server does not itself confirm connection quality to the selected ingest server. Next, copy a suitable server's address into your streaming application; see Starting a broadcast.

Collect a route trace

If the issue recurs, collect a trace to the StreamVi server while it happens. In PingPlotter, enter the ingest server's hostname or IP without the stream key, then start measuring. Record the error time to compare it with the OBS log.

Check the final server's result first, then compare intermediate hops. A missing reply from one intermediate hop does not itself prove video-data loss: routers may handle diagnostic requests differently. Check whether the issue continues at later hops and the destination. See PingPlotter's explanation.

This example shows 36.8% at intermediate hop 15, while the table shows no loss at subsequent hops or the final server. The screenshot therefore does not establish that hop 15 is losing the video stream. This single screenshot also cannot establish the cause of a latency change or a prolonged outage.

Send results to support

Provide the ingest server, issue time, configured bitrate and test results. Attach the trace and log if support requests them. If your PingPlotter version offers Share → Create Share Page, you can send a link to the result.

Before sending, check that the materials contain no stream keys or other sign-in data. See What to send support.