How to report an error

1. Provide a short and precise title ("HELP!" is not what we have in mind here)
   • The title may be the most important part of the report as it is read the most. If you want help, do your best to come up with a title that people want to read.
2. Provide a concise description, including the steps needed to reproduce the error. If needed, you can suggest the behavior that you were expecting to see.
   
   • 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 the program works and when it doesn't?
   • How did you expect the program to behave?
   • Can you describe the audio issue? If not, can you enclose or attach a recording of the audio?
3. Provide environment information about your setup
   • Hardware platform (i.e. ARM, X86, VPS, Docker, etc.)
   • Operating system and version (i.e. uname -a). If it is a particular distribution (Ubuntu, Debian, Arch, etc.), say so.
     
4. Note the application version and the build timestamp
   • 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!
5. Provide your actual configuration files (redacted of personal and password information)
   • 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 config files in the message, enclose/attach them. It makes our job easier.
   • You may have multiple versions of a file (transcoders, for instance, have multiple Analog_Bridge.ini files)
6. Provide your log 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/attach 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.
   • Sometimes a very verbose version may be asked for and you would need to set the logLevel to 1.
7. PLEASE avoid sending screenshots
8. Follow up
   • Once a developer says a bug has been fixed, please re-test the issue and make sure it REALLY has been fixed.
   • Did we fix the bug and cause 3 more? Oops!