Screen-share problems

Test with one sender and one viewer. Record whether the sender’s local preview contains the expected window before changing server settings.

No source, permission error, or wrong window

Open Change source in the share menu and choose the intended screen or window again. Check the sender’s OS capture permission. On a Wayland desktop, confirm that the screen-capture portal opens and that a source was accepted; selecting a window in another application does not grant this application’s portal request.

Compare sharing a simple application window with sharing the whole desktop. If one source fails and the other works, report the application and capture type. Protected video can intentionally appear black; it is not a relay configuration test.

Sender sees the picture; viewer does not

Ask a second viewer to try the same share. Open Stats for Nerds from the share menu and record the available transport and stream counters, plus whether they change. Capture the visible error rather than describing every blank view as a capture failure.

Comparison	Where to investigate
No sender preview	Sender capture permission, source selection, or capture backend.
Preview works; all remote viewers fail	Advertised delivery mode, server media endpoint, and network reachability.
One viewer fails; others work	That viewer’s network, decoding/rendering backend, and logs.
Same-LAN viewers work; off-network viewers fail	Private/loopback advertised addresses, NAT, and firewall rules.
Picture arrives but is cropped	Compare Fit, Fill, and 1:1. These are display modes, not transport repairs.

For a Starling relay, the owner should inspect:

docker compose ps screenshare
docker compose logs --since=10m screenshare

Check the screenshare service’s advertised public_url and UDP listener against the actual public IP, published port, and host/cloud firewall. A localhost or private address cannot be reached by arbitrary remote members. Screen-share media uses its own UDP listener; opening only the Mumble voice port does not establish media reachability. See Media relay and Ports and networking.

If the client advertises peer-to-peer delivery instead, investigate reachability between sender and viewer. Do not treat relay settings as active merely because a relay exists on the server.

Freezes, high delay, or poor quality

Compare a smaller capture source or lower Stream Quality while keeping the same viewer and network. Record whether only playback freezes or the sender preview also stops. Include the available stats and hardware/driver information. A successful low-resolution test suggests a capacity or encoding/decoding issue; it does not prove which machine is responsible.

Before reporting, include sender/receiver OS and versions, source type, delivery mode, local-preview result, same-LAN/off-network result, number of affected viewers, stats screenshot, and matching client/server log timestamps.