Troubleshooting

Connection problems

The status indicator does not reach Connected, or reaches it and then drops back. The state of the indicator and when the failure happens usually narrow the cause. Most connection issues sit at the network or OS layer.

• Device not powered or not on the network. Confirm the device is on and its network indicator is lit. From the Pixelrush machine, try pinging the IP address; if ping fails, the problem is at the network or device level, not in Pixelrush.
• Device still initializing. If the indicator is stuck on Connecting shortly after powering the device on, give it time to finish booting before the handshake can complete — typically up to a minute for ATEM switchers and HyperDeck recorders.
• Wrong IP address. If the indicator stays on Error or never reaches Connected, the configured address may not match the device. Open Settings → Connections and click the connection row to edit it. Confirm the IP address matches the one set on the device itself.
• Wi-Fi or wireless instability. If the handshake never completes, or the connection drops every few minutes, packet loss on a wireless link is a common cause. Move to wired Ethernet between the Pixelrush machine and the network switch.
• DHCP lease changed. If a connection that was working stops working, or drops mid-show, the device may have received a new DHCP address. Assign a static IP in the device's setup utility, or configure a DHCP reservation, and update the address in Pixelrush if it changed.
• Different subnets or blocked routing. The Pixelrush machine and the device must be on the same local network segment, or have routing between them that allows the protocol's traffic. If your setup uses VLANs or separate switches, confirm with whoever maintains the network that traffic is allowed.
• Firewall blocking traffic. A persistent failure to connect can also mean the operating system firewall or a network firewall is dropping packets between the two devices. Verify both ends permit the connection. See Best practices for network setup guidance.
• Device connection limit reached. Some devices cap simultaneous control connections at a small number — for example, ATEM switchers typically accept around five clients, and some HyperDeck firmwares accept only one. If the indicator is stuck on Connecting, or a connection that worked previously will not re-establish, another control surface or piece of software may already be holding a slot. Close any other apps talking to the device, then disable and re-enable the Pixelrush connection.
• Network congestion. If the connection reaches Connected but drops periodically, heavy traffic on a shared switch can be dropping packets. Isolate the Pixelrush machine and the device on a dedicated network switch or VLAN where possible.
• Traffic routed through the wrong interface. If the machine has multiple network interfaces that can both reach the device's subnet, the OS may send traffic over the wrong one — typically appearing as a connection that fails or is unstable despite a healthy-looking wired link. Edit the connection and set Network Interface from Auto to your production interface. See Pin connection network interfaces in Best practices.
• Network or routing configuration changed. If a previously working connection stops working without any intentional change on the Pixelrush side, a router restart, firmware update, or IT change may have altered routing, firewall rules, or VLANs. Re-verify the path between the two devices.
• Sleep or power management. If drops correlate with periods of inactivity, the operating system may be putting the machine, the network interface, or the app to sleep. Enable Keep Computer Awake in Settings → General — Pixelrush will hold a wake lock for as long as the app is running, regardless of the system's own sleep settings. On laptops, also check System Settings → Battery → Options and confirm the machine is not configured to sleep aggressively on battery. See Prevent the computer from sleeping in Best practices.

For any of the above, disabling and re-enabling the connection forces a clean reconnect attempt and clears stale state. Open Settings → Connections, select the three-dot menu next to the connection name, choose Disable, wait two seconds, then choose Enable. If the connection recovers, the underlying issue was transient.

Timecode

Timecode problems show up as a display that stays blank, flickers, or updates with values that don't match the source. The shape of the failure usually points at the signal path, the audio interface, system permissions, or the framerate configuration.

• ATEM timecode display freezes between events. A known firmware quirk on some ATEM models. Recorded cuts are still timestamped accurately. See Known issues on the ATEM hardware page.
• LTC signal problems. A blank, frozen, or flickering timecode display often points at the LTC signal itself rather than software or configuration. Patch the cable to a monitor briefly — you should hear the distinctive buzzing tone, confirming the source is running and the cable is seated at both ends. Check the audio interface meters: a level too low to decode is a common cause; see Set the right audio gain for LTC in Best practices for the target window. If the display flickers in cycles, inspect the cable — XLR is more reliable than 3.5 mm TRS over any distance, and runs near power or lighting dimmer packs can introduce ground loops or noise that a DI box can resolve.
• Wrong audio input or channel selected. If the LTC connection shows Connected but the timecode display stays blank, Pixelrush may be listening to the wrong input or channel. Open Settings → Connections, edit the LTC connection, and confirm the selected audio input and channel match the physical input receiving LTC. If the audio interface was recently changed or reconnected, re-select it here.
• Framerate mismatch on the LTC connection. If timecode is updating but the numbers don't match what you expect — frames count too fast or too slow, or the hour/minute boundary rolls over at the wrong moment — the framerate configured in Pixelrush does not match the framerate embedded in the LTC signal. Open Settings → Connections, edit the LTC connection, and set Framerate to match the source.
• Microphone permission not granted (macOS). macOS gates all audio input — including line-level LTC — behind the microphone permission. If it has not been granted to Pixelrush, the connection can still appear in the Connected state, but no samples reach the decoder and the timecode display stays blank. Open System Settings → Privacy & Security → Microphone, enable Pixelrush, and restart the app. See also Proactively grant permissions in Best practices.
• Audio interface dropping samples. If timecode flickers but the cable and signal look healthy, the audio interface itself may be unstable. Low-quality USB interfaces can drop samples under CPU load. Try a different interface, or reduce CPU load on the Pixelrush machine.

Missing cuts

The cut list has fewer cuts than the show had. Some or all cuts from a portion of the show are absent.

• Transitions returning to the same source. Pixelrush only records when the program output changes. If a cut or transition ends on the original source, the cut will not appear in Pixelrush.
• Wrong video bus selected. The session is currently scoped to the bus you picked at session start. Pixelrush captures every connected bus continuously, so cuts from the bus the director was actually using are still in the data. Open the session, switch its Video Bus to the correct one, and the cut list re-populates from the existing capture data — no re-recording needed.
• Connection dropped during the show. Cuts made while the connection was down are not recoverable. The cut list will have a gap covering the outage window. See Best practices for network setup guidance that prevents this.

Synchronization issues

Cuts in the EDL don't line up with the picture in your editor. The shape of the offset usually points to one of a few likely causes.

• Framerate mismatch on the LTC connection. A steadily growing offset over the course of the show often means the framerate configured on the LTC connection does not match the source — for example, 30 configured against a 29.97 source produces roughly 0.1% drift. To resolve, open Settings → Connections, edit the LTC connection, and set Framerate to match the source.
• Fixed latency in the signal path. If every cut is off by the same number of frames and the error does not grow over time, this is likely fixed latency somewhere between the switcher and the recorders — typically a frame synchronizer, capture card, or similar device that delays the recorded picture by a known number of frames relative to the cut event. To correct it, compare a known cut in the EDL against the same frame in your editor and count the difference in frames. Open the session and enter that value in its Frame Offset field; every cut in subsequent EDL exports will shift by that amount.
• Audio interface clock drift (LTC). If the framerate setting is correct but cuts still drift apart over the course of the show, the audio interface capturing LTC may be running slightly off its nominal sample rate, causing the decoded timecode to drift relative to real time. The rate of growth is typically much smaller than with a framerate-config mismatch. To resolve, switch to an interface with a more stable clock, or one that can lock to external word clock or house sync. A frame offset at export cannot correct this kind of drift, since the error is different at every cut.
• Network jitter. If the offset wanders unpredictably (a few frames late in one place, on time elsewhere, early somewhere else), variable latency between the switcher and Pixelrush is a likely cause — often from a congested or Wi-Fi network. Variable drift cannot be corrected after the fact.