Local Network Discovery & Auto-Connect

How Auto-Discovery Works

RideStream uses a lightweight, zero-configuration discovery protocol to pair hosts and receivers automatically — no IP address typing required. Instead of a central server, devices talk directly to each other on your local network:

• UDP discovery broadcasts (port 8082): hosts and receivers exchange short discovery messages over UDP broadcast on port 8082. A host looking for clients announces itself; a receiver waiting for a server replies with its device name.
• Subnet scan fallback: when broadcasts are blocked (e.g., by AP isolation), RideStream additionally sends the discovery message to every IP (1–254) in your local subnet as a unicast fallback.
• HTTP polling (:9191/state): receivers also poll candidate hosts over HTTP at port 9191 and connect when a host responds — this is what powers "Wait for Server" and saved-server reconnects.
• Media streaming over HTTP (port 9191): once paired, the receiver streams media from the host's embedded HTTP server on TCP port 9191.

Prerequisites Checklist

For automatic discovery to work, all of these must be true:

• Same network: Host and receiver on the same Wi-Fi SSID and subnet. The receiver must not be using cellular data.
• Peers can talk to each other: Your router must allow client-to-client traffic (see Android section — guest networks and AP isolation block this).
• Broadcast allowed: The network must forward UDP broadcast (port 8082). Some public, enterprise, and hotel/café Wi-Fi networks filter or block it (the subnet-scan fallback may still work).
• Host is running: RideStream must be active in Host Mode on the server device.
• Host firewall: On Windows, the host must allow inbound TCP 9191 (streaming + state) and UDP 8082 (discovery) — see below.
• No VPN: A VPN tunnel usually redirects all traffic and hides the LAN — disconnect it for LAN discovery.

Windows: What Happens by Default & What to Fix

Windows 11 — Default Behavior

Windows classifies every network as Private or Public. The first time you connect to a new Wi-Fi network, Windows 11 shows a popup:

"Do you want to allow your PC to be discoverable by other PCs and devices on this network?"

• If you click Yes, the network is set to Private and network discovery is enabled — auto-discovery generally works right away.
• If you click No or dismiss the prompt, the network stays Public. On Public networks Windows disables inbound discovery by default, so your RideStream host will not be visible to receivers.

How to Enable Discovery in Windows 11 (22H2+)

1. Mark the network as Private:

   Open Settings → Network & internet → Wi-Fi → select your network → toggle Private network (or Ethernet for a cable connection).

2. Turn on Network discovery:

   Go to Settings → Network & internet → Advanced network settings → Network discovery and switch Discoverable to On.

Classic Path (Windows 10 & 11)

The same setting also lives in the Control Panel: Control Panel → Network and Sharing Center → Change advanced sharing settings → (current profile) → select Turn on network discovery → Save changes.

Windows Firewall — the "Allow Access" Prompt

When RideStream first listens on your network, Windows Defender Firewall normally shows a security alert for the app:

"Windows Defender Firewall has blocked some features of this app"

• Tick the Private networks checkbox (and Public networks if you also host on public Wi-Fi) and click Allow access.
• If you previously clicked Cancel, re-allow it: Settings → Privacy & security → Windows Security → Firewall & network protection → Allow an app through firewall → find RideStream → check Private → OK.
• Microsoft Store installs: Store (MSIX) apps get their firewall rules applied automatically at install, so the prompt may not appear — in that case only the network profile/discovery settings above matter.

Manual Firewall Rules

If you prefer explicit rules (or are running a portable build), run PowerShell as Administrator:

netsh advfirewall firewall add rule name="RideStream Host Server" dir=in action=allow protocol=TCP localport=9191
netsh advfirewall firewall add rule name="RideStream Discovery" dir=in action=allow protocol=UDP localport=8082

The TCP 9191 rule allows receivers to stream media from your PC and poll its state. The UDP 8082 rule lets them discover the host automatically via broadcast. The host always listens on port 9191 — there is no custom port setting.

Android: The Network Must Let Peers See Each Other

On Android, RideStream uses the platform's multicast/broadcast support to exchange UDP discovery messages and HTTP polling. These features only run while the device is connected to a Wi-Fi network — they do not work over cellular data.

Beyond that, discovery needs a network that allows peer-to-peer traffic and broadcast/multicast. Not every network does:

• Guest Wi-Fi networks — almost all routers isolate guest clients from each other, so devices on the guest SSID cannot discover or connect to your host.
• AP / Client isolation — many routers (and some mesh systems, often per-SSID) have a setting named "AP Isolation", "Client Isolation", or "Wireless Isolation". When enabled, wireless clients cannot talk to each other even on the same network.
• Public / hotel / café Wi-Fi — usually enforce client isolation and often a captive-portal login; discovery will fail.
• Enterprise (802.1X) networks — many corporate or university Wi-Fi networks filter broadcast/multicast traffic and separate clients, which breaks discovery.
• Separate IoT/VLAN SSIDs — some routers place "smart home" or "guest" SSIDs on a different subnet/VLAN; broadcasts do not cross VLANs by default.

Some Android devices may also fail to run discovery reliably when the Wi-Fi radio is busy (e.g., the phone is itself hosting a hotspot) or under aggressive battery-saver restrictions that block background network access. In every such case the fallback is the same: connect manually by IP.

Manual Connection by IP (When Discovery Isn't Possible)

If auto-discovery is blocked by the network, you can still connect: in the receiver's Streaming Mode dialog use Connect by IP and type the host's local IP address.

Finding the Host's IP — Normal Home/LAN Case

• On Windows: Open Command Prompt and run ipconfig. Look for the IPv4 Address of the active adapter (e.g. 192.168.1.100).
• On Android: Open Settings → Wi-Fi → tap the connected network → IP address.

The Gateway IP Shortcut — When the Host Is a Hotspot

There is one case where the host's IP is easy to find without ipconfig: when the host device is also the Wi-Fi hotspot. In that setup the host is the network gateway, so you can connect using the gateway IP directly:

• Android phone as hotspot: the hotspot gateway is typically 192.168.43.1 (may differ by manufacturer — confirm in the phone's hotspot/tethering settings).
• Windows laptop as hotspot: the Windows Mobile Hotspot gateway is typically 192.168.137.1.

So for a phone hotspot named e.g. CarCinema, passengers' tablets that cannot find the phone via discovery can just enter 192.168.43.1 in Connect by IP. When in doubt, always verify the actual address with ipconfig (Windows) or the host device's network/hotspot settings.

🔧 Discovery Troubleshooting

Next Steps & Related Guides