The title may be the most important part of the report as it is read the most. If you want help, make a title that people want to read.
Bug hunting is time consuming work. If you want a bug to get fixed, make sure you give enough information to reproduce the problem. What did you do? Was there something different between when it works and when it does not? What did you expect it to do? Can you describe the audio issue? If not can you enclose a recording of the audio?
The version and build timestamp are found in the log file when the app is launched. Please make sure you are not reporting a bug that has already been fixed!
In order to reproduce the issue, we will need to re-create your environment. Your configuration files are the key element. MMDVM_Bridge.ini, DVSwitch.ini and Analog_Bridge.ini are needed at a bare minimum. Please do not just paste them in the message, enclose them. It makes our job easier. You may have multiple versions of a file (transcoders have multiple Analog_Bridge.ini files)
Log files are the other artifact that helps us debug an issue. What did the app do with a specific input? Was there an error? What happened before the error occurred? The log files tell us this and more. Your log files may appear in several directories. There are default locations, but your ini files can change that. You should enclose your log files in the message. The log level is important to our debugging efforts. For most things, a logLevel of 2 is sufficient detail to debug the problem. However, sometimes a very verbose version may be asked for and you would need to set the logLevel to 1.
Once a developer says a bug has been fixed, please re-test and make sure it REALLY has been fixed. Did we fix the bug and cause 3 more? Oops!