How to run an iRacing broadcast with a remote crew

Keep iRacing and OBS under one host, split remote work by role, use a low-delay program return, give each person scoped controls, confirm every action and rehearse disconnection. Remote production is a permissions and feedback problem before it is a browser problem. This guide covers distributed league crews; check the known issues before a major event.

What job are you moving off the host PC?

Camera selection

The remote operator needs current timing, the active target, camera controls, manual lock state and confirmation that the host accepted the change.

Graphics

Give show and hide controls for approved overlays, current on-air state and preview where possible. Do not also grant replay or race-control commands by default.

Commentary

Provide program return, live timing, driver identity, incident cues and private talkback. Most commentators do not need production-control rights. The commentator timing desk guide covers what to put on their screen.

Incident review or stewarding

Use a read-only incident feed plus specifically authorised race-admin actions. Keep private review separate from on-air messages, and rehearse the incident and replay handoff before assigning remote roles.

Public live timing

This is a viewer service, not an operator seat. It should be read-only, simple on mobile and isolated from the control channel. See the live timing guide for league broadcasts.

Remote production has four separate paths

• Program video. The picture and audio viewers receive. Remote crew needs a return with known delay, but it does not always need full platform-quality bitrate.
• Live data. Timing, flags, focused car, incidents and session state. This can update separately from the video and should expose stale or disconnected state.
• Control commands. Camera, graphics, replay or race-admin actions sent back to the host. These need permissions, acknowledgement and rate limits.
• Crew communication. Commentary, talkback, steward chat and emergency stop instructions. Keep public and private channels clearly separated.

Trying to force all four paths through one remote desktop session makes every failure harder to diagnose. A video delay is not the same as a rejected control. A lost talkback channel is not the same as stale timing.

The host must remain the authority

The host is connected to iRacing, owns the OBS program feed and can see whether a command actually changed the local session. Remote operators should request actions through an authorised path.

• Host can override immediately. A remote camera or graphic choice must never trap the local producer.
• Every operator has an identity. Shared links make accountability and revocation difficult.
• Access is scoped by role. A commentator does not receive race-admin commands because they asked to see timing.
• Actions receive acknowledgement. The remote UI should show accepted, rejected or timed out, not assume a click happened.
• An emergency freeze exists. The host needs one way to stop remote commands while keeping the local show alive.
• Invites can be rotated. Access for last season’s crew should not remain valid forever.

A practical crew-role matrix

Role	Needs to see	May control	Should not receive by default
Host producer	Everything, including connection and on-air state	All local production controls	Nothing required beyond role policy
Camera operator	Timing, active target, program return	Camera target, group and approved replay navigation	Billing, account and unrelated race admin
Graphics operator	Current overlay and program state	Approved graphics and prepared messages	iRacing admin commands
Commentator	Program, timing, driver and incident context	Normally none, or limited prepared cues	Direct camera, replay and steward controls
Steward	Incident feed, timing and private review	Only explicitly assigned race-admin actions	On-air graphics unless the producer enables them
Viewer	Public timing and stream	Nothing	Every production and race-control action

The remote surface should expose a role’s job and current state, not mirror the entire host desktop.

Delay changes what each role can do

Role	Delay sensitivity	Design response
Live camera operator	Very high	Use current data and a low-delay return; confirm host action quickly
Graphics operator	High for reactive graphics	Show explicit on-air state and avoid blind toggles
Commentator	High for picture matching	Know program delay and align talkback
Incident reviewer	Moderate	Use timestamps and logged session time rather than wall-clock guesses
Public timing viewer	Moderate	Show data freshness and never claim zero delay

Keep remote desktop for recovery

A remote desktop application can be useful when a trusted administrator must repair the host machine. It is a poor default for multiple race-night operators because it exposes the entire desktop, competes for mouse and keyboard, and makes individual permissions difficult.

If you keep remote desktop for emergencies, restrict who can use it, rehearse the connection, disable clipboard or file transfer where appropriate and never let it become the only way to operate the show.

How EDR Broadcast handles the model

EDR Broadcast keeps the Windows host connected to iRacing and OBS. Remote crew is a League feature (A$45 a month or A$486 a year excluding GST, 5 machines): remote browser control, remote stewards and public live timing let crew work from a browser while the host keeps authority over the session.

Before race night, run your exact remote workflow in EDR Broadcast through the rehearsal below, with the number of operators you plan to use, and check what your plan allows on the pricing page. Do not rely on a marketing screenshot for a critical event workflow.

The remote-crew rehearsal

1. Create each operator separately and give only the role intended for race night.
2. Confirm every person can identify the host state, active camera or graphic and program delay.
3. Run normal camera, graphics and incident tasks while the host watches acknowledgements.
4. Disconnect one remote operator during an action, then reconnect and confirm the current state is correct.
5. Have the host stop remote commands and continue the local show.
6. Revoke an operator’s access and confirm the old access no longer works.
7. Finish the session and check that public timing and remote control close cleanly.
8. Write down the fallback: who takes each job if the remote path fails at the green flag.

Frequently asked questions

Can someone control my iRacing broadcast from another country?

Yes, with a remote workflow that sends data and authorised commands to the host. Video return delay and connection quality still affect what roles are practical.

Do remote operators need iRacing installed?

It depends on the product and role. Browser-based controls may not. A synced remote spectator-client workflow does require compatible iRacing access and setup.

Should commentators receive camera controls?

Not by default. Give them program return, timing and talkback first. Add a limited control only when the production plan requires it.

Is remote desktop safe for league production?

It can be secured for trusted emergency administration, but it exposes a broad surface and is not ideal as the normal multi-operator control model.

What happens if a remote operator disconnects?

The host should keep the local show running. The role should reconnect into current state rather than replaying old actions. Test this before the event.

Do EDR Broadcast Free or Pro include remote crew tools?

No. Remote browser control, remote stewards and public live timing are League features. Free covers 1 machine and Pro 2, with no remote crew tools.