> ## Documentation Index > Fetch the complete documentation index at: https://docs.streampixel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting > Diagnose stream quality, connection, and audio issues — with or without the Web SDK. This page covers the issues most users hit when streaming through Streampixel — blurry streams, connection failures, audio problems, and stalled builds. Click any item below to expand it. If you're using the Web SDK and need help with SDK-specific code (Webpack polyfills, singleton initialization, codec ID resolution, etc.), see the [SDK troubleshooting guide](/resources/web-sdk/guides/troubleshooting). ## Think Streampixel is down? If multiple streams stop working at once, or if you suspect a wider outage, check before debugging your own setup: Visit [status.streampixel.io](https://status.streampixel.io). It shows live health for every Streampixel service. * **Degraded** or **Down** — our team is already aware and working on it. The status page is the canonical place for incident updates; no need to file a ticket. * **All systems operational** — the issue is likely on your side. Continue with the troubleshooting steps below, or raise a ticket if you've already ruled out the common causes. Log into the [dashboard](https://dashboard.streampixel.io), go to **Support**, and raise a ticket with the relevant topic. Our team responds within the published SLA — and almost instantly for critical events. ## Stream quality **Symptom:** The stream connects but looks soft, blocky, or pixelated — especially during motion. Pixelation usually means the encoder is compressing harder than you'd like. Walk this checklist before tuning settings. **1. Pull live stats from the player.** Press T + 5 together while the stream is focused to open the stats panel. Three numbers tell you most of what you need to know: | Stat | Healthy range | What it means if high | | ------------------------------------- | --------------- | ------------------------------------------------------------------- | | **RTT** | \< 80 ms | Wrong region, or viewer is far from the stream worker | | **Packet Loss** | \< 1% | Network congestion, Wi-Fi interference, or UDP being blocked | | **Video Quantization Parameter (QP)** | low / mid range | Encoder is compressing hard — bitrate capped or network constrained | Ask viewers to share these values when they report quality issues. Stats beat intuition. **2. Check the network path.** If RTT is high or packet loss is non-zero, the network is the bottleneck — no encoder setting will fix it. Confirm: * The viewer's network allows **UDP 3478** outbound. Blocked UDP is the single most common cause of blurry, choppy streams. See [Network requirements](/resources/concepts/network-requirements). * The viewer is on the closest available region to your project. * The viewer is on Wi-Fi 5 GHz or wired, not 2.4 GHz Wi-Fi or congested cellular. **3. Tune the encoder (only if the network is clean).** If stats show a clean network but QP is still high, the encoder is hitting its compression ceiling. Open **Project Settings → Resolution** and try: * **Lower Max QP** — caps how aggressively the encoder is allowed to compress. * **Raise Maximum bitrate** — gives the encoder more bits to spend on quality. Lowering Max QP forces the encoder to keep quality high. On a constrained network this can cause **frame drops** instead — the encoder runs out of bandwidth and skips frames rather than compressing them. Tune in small steps and watch FPS. Start from the [recommended use-case presets](/resources/quick-start-guide/resolution-settings#recommended-settings-by-use-case) and adjust from there. **Symptom:** Inputs take noticeably long to register, or the stream feels delayed even though the picture is sharp. **Solutions:** * Check RTT in the stats panel (T + 5). Anything above \~100 ms means the viewer is far from the stream worker — pick a region closer to your audience. * On viewer devices: prefer wired Ethernet or 5 GHz Wi-Fi. 2.4 GHz Wi-Fi and cellular both add 30–80 ms. * For interactive use cases, opening **UDP ports 10000–60000** outbound enables a direct peer connection to the rendering node, which is lower latency than the relay path. See [Network requirements](/resources/concepts/network-requirements#about-the-optional-udp-10000-60000-range). * If your Unreal scene is rendering below 60 fps on the worker, no network tuning will fix it. Profile in Unreal Insights. For a deeper checklist, see [Performance tuning](/resources/recipes/performance-tuning). **Symptom:** The stream connects but the video area is black or empty. **Solutions:** * Confirm the project is **active** in the dashboard. * Confirm a build is currently live (Builds tab → "Current Live Build" status). * Reload the page once. Some browsers fail to attach the video element on first load. * If you're embedding via iframe, verify the parent page allows the iframe and isn't blocking autoplay. **Symptom:** Stream is playing but there's no sound. **Solutions:** * Browser autoplay policy blocks audio until the user interacts with the page. Click anywhere on the stream first — many browsers will then start audio automatically. * Check the player's volume controls and make sure both video and audio elements are unmuted. * Confirm the Unreal project actually emits audio (test the packaged build locally before uploading). **Symptom:** Your packaged build runs fine, but in-scene videos don't play once it's streaming on Streampixel. The most common cause is that media files weren't placed in the folder Unreal expects when packaging. They need to be inside `Content/Movies/` in your Unreal project — anywhere else and they won't be included in the cook, even if they reference correctly in the editor. **Solutions:** * Move all `.mp4` / `.mov` files into `Content/Movies/` and re-point your **File Media Source** assets to the new path. * Re-package the build and re-upload. * See [Playing media files](/resources/additional-unreal-engine-features/playing-media-files) for the full setup. ## Connection issues **Symptom:** The stream is stuck on "Sharpening Pixels & Buffing the Details", "Establishing WebRTC connection…", or never gets to a video frame. Almost always a network restriction — typically a firewall blocking WebRTC. **Solutions:** * **Confirm UDP port 3478 is open outbound.** This is the primary media path. If blocked, WebRTC will try TCP fallback, but some networks block that too. * Try the same stream from a different network (mobile hotspot, home Wi-Fi). If it works there, the corporate / hospital / hotel firewall is the culprit. * Verify WebRTC isn't disabled at the browser policy level. Some enterprise browsers turn it off. * Share the [Network requirements](/resources/concepts/network-requirements) page with the network admin — it lists every port and Twilio IP range to allow-list. **Symptom:** On iOS / Android, the stream disconnects when the user switches to another app. This is intentional. Streampixel disconnects after **60 seconds** of the browser tab being hidden to free up GPU resources. If the user comes back within 60 seconds, the stream continues. After that, they'll need to reconnect. ## Input issues **Symptom:** Mouse and keyboard work fine on a desktop browser, but on a phone or tablet, taps and gestures do nothing in the streamed app. Almost always means your Unreal project doesn't have logic to handle **touch events** — only mouse events. The browser is sending taps as touch input, and your project is ignoring them. **Quick fix (no Unreal changes):** Enable **Fake Mouse Touch** in **Project Settings → Input** ([Input & UI controls](/resources/quick-start-guide/frontend-settings)). This converts touch gestures into synthetic mouse events on the way to Unreal, so your existing mouse-handling logic works on touch devices. **Proper fix:** Add native touch handling to your Unreal project (`OnTouchStarted`, `OnTouchMoved`, `OnTouchEnded` in your Pawn or HUD). This gives you multi-touch, pinch, and other gestures that single-pointer mouse emulation can't reproduce. Don't enable **Fake Mouse Touch** if your Unreal project already handles touch natively — you'll get duplicate or conflicting input. **Symptom:** Tapping an editable text box in the streamed app on a phone or tablet doesn't bring up the device keyboard. From **UE 5.3 onwards** this is automatic — Streampixel detects when an editable text widget gets focus and shows an input popup that triggers the on-screen keyboard. If it's not happening: * Confirm you're on UE 5.3 or later. Older versions don't ship the auto-bridge. * Confirm **Keyboard** input is enabled in **Project Settings → Input**. * On iOS, the first interaction must be a real user tap — auto-focusing a field on load won't open the keyboard. Full details: [Virtual keyboard for text input](/resources/additional-unreal-engine-features/virtual-keyboard). ## Build issues If a build hasn't moved past `Queued`, `Downloading Files`, or any other state for a long time, see [Build lifecycle → When a build sits longer than expected](/resources/concepts/build-lifecycle#when-a-build-sits-longer-than-expected). Most cases are normal queueing or archive retrieval; anything past 2 hours is worth a support ticket. Before opening a support ticket about a build that misbehaves on Streampixel, try the same packaged `.exe` on a **different local machine** — a colleague's laptop, a different desktop, anything that isn't your dev machine. If the build is broken on the second machine too, it's a packaging problem (missing assets, dependencies installed only on the dev box, hardcoded paths). Fix it locally before re-uploading. If the build runs fine locally on multiple machines but fails on Streampixel, that's something we should look at — share the project ID, build name, and what specifically is failing, and we'll dig into the worker side. ## Still stuck? If [status.streampixel.io](https://status.streampixel.io) shows everything as operational and the steps above didn't help, raise a ticket from the [dashboard](https://dashboard.streampixel.io) → **Support**. Include: * The project ID and (if relevant) build name * The stream URL the viewer was using * A screenshot of the stats panel (T + 5) showing RTT, Packet Loss, and Video Quantization Parameter * The viewer's browser, OS, and network type (corporate / home / cellular) That's enough for us to reproduce most issues without back-and-forth. We respond within the published SLA, and almost instantly for critical events. ## Next Ports and IP ranges to allow-list for clean streaming. Hit your latency, FPS, and bitrate targets. What each disconnect code means and how to handle it. Web SDK-specific issues — Webpack, singleton init, codec IDs.