Reporting bugs

Problem	Repository
Client UI, device capture, playback, or crash	Fancy Mumble client issues
Starling service, storage, configuration, or deployment	Starling issues
Incorrect or missing documentation	Docs issues

Capture the controls that matter

For an audio issue, show the selected devices, activation mode, and processing/transmission choices. For a connection issue, show the exact error and the address/port fields with private values redacted. For a share issue, show the sender preview and viewer stats. A screenshot of the whole desktop often hides the important control at an unreadable size.

Copy this evidence template

Client version / build:
Server version and deployment:
OS version; relevant audio/video device and driver:
Time of reproduction, including timezone:

Steps (starting from the current state):
1.
2.

Expected result:
Actual result and exact error:
How often it happens:

Working comparison:
One change that was tested:
Result before / after that change:

Audio: local sample result; Continuous result; UDP versus TCP result.
Share: sender preview; affected viewers; delivery mode; stats.
Connection: resolved address; TCP probe; login/certificate error.

Attachments: relevant screenshots and logs for the same time window.

Use the applicable evidence lines and remove the rest. Include exact version strings rather than “latest.” Describe a working comparison even when it is on the same device—for example another channel, another capture source, or the same call using TCP.

Obtain logs

Follow Collect useful logs to enable file output and export the current .log.zst archive. Turn on logging before reproducing the issue. For a server problem, attach the failing service’s logs and restart/exit status. Keep the reproduction short enough to identify in those logs.

Review attachments for credentials, private URLs, certificate keys, and other members’ messages before making them public. Report separate failures in separate issues unless the reproduction shows they share the same cause.