HOW-TO:Submit a bug report
|HOW-TO:Submit a bug report|
So, you think you've found a bug? Great! Thanks for being proactive enough to make it this far. If you want to ensure that your report gets attention from the right people it is paramount that you answer the following questions. Please read this document in its entirety before continuing on your adventure.
1 Has the bug been reported already?
Duplicate bug reports only clutter the communications channels with the developers. Keeping the discussion in one place not only makes the topic easy to follow but centralizes all details for easier review. Before posting your bug report, it is important to ensure that you haven't been beat to it. There are two places to look, the Kodi Forum and Github Tracker. Both have a search button. Please use it! If you find a thread on the forum or issue on the bug tracker, please read through it and add any new information that you can provide. "Me too" and "bump" posts don't really help the matter without additional details, so please refrain.
2 Ok, so my bug is new. Now what?
Now that you have made sure that your problem is unique, it is time to open a dialog with the community. Where to do this is a question of your certainty that the problem is in fact a bug. Keep in mind that reporting the bug puts some responsibility on you to answer any questions a developer may have. You may want to consider "subscribing" to your forum thread (you'll be CC'd updates automatically by the bug tracker) and ensure that your registered email is one that you keep track of!
2.1 Yes! This must be a bug!
If you are sure that you're dealing with a bug, (crash, hang, failed playback, corruption, etc) please go straight to the Github Tracker and create a new issue. Be sure to fill in as information as possible, use your best judgement.
2.2 Hrm...I think this is a bug...
If the problem is more one of behaviour you didn't expect, please start in the forums first. Kodi has many features, with these features comes design decisions. It is very possible that the behaviour you expect is not that which the developer envisioned. There is also a possibility that the feature is very complicated at the code level and that the behavior you expect would be very difficult or impossible to create. Regardless, bouncing your ideas off of forum users (most developers are forums users too!) to confirm and clarify before opening a issue on the Github Tracker. You may be opening a feature request instead! ;)
3 Right, so what information do you guys need?
Regardless of where you're posting your report, if you expect someone to take interest in it, they will expect details from you. Don't forget, we're doing this stuff in our free time, too! Post as much of this stuff as you can upfront. We'd rather spend our time fixing problems than digging for details. If you need further help obtaining something, feel free to ask (then come back and update the wiki!).
3.1 Debug log
A debug log is ESSENTIAL to any and all bug reports. Debug logs are disabled by default; first, you must simply enable debugging. Without it your report stands a good chance of being overlooked. It provides nearly all of the information about what was going on and what you were doing in the application. The log file also contains some of the details you'll need to fill out a new issue on the Github Tracker. So it might pay to glance through it yourself.
3.2 Detailed instructions to reproduce
To actually solve your problem, we need to be able to reproduce it. The more descriptive the instructions, the better chances are that they'll work for others screenshots go a long way in some cases use sites like imgur, snaggy or postimage. Sit down and reproduce the problem a few times, first, to make sure you understand it. If the problem is "random," enable debugging during normal use. Restart the application often to keep the log file short. The more time you spend isolating the problem, the quicker a developer will be able to reproduce and fix it. Please take your time with this step!
3.3 Sample file
If your problem has to do with playback of video, audio or subtitles, or display of a picture a sample file will go far in getting it fixed. The file should be as small as possible while still reproducing the issue. There are several audio/video cutting applications available (just google it until someone makes a list here). For posting/attaching bigger files, you'll have to use a file hosting site like MediaFire or Dropbox
3.4 Crash report
If Kodi has crashed, there are good odds that a crash report is available. How these are handled is platform dependent.
- iOS will always create a Crashreporter log if any application crashes. These are found in /var/mobile/Library/Logs/CrashReporter/*.plist
- The file will be in your user's home directory or the working directory if Kodi was launched from a terminal. It will be named "kodi_crashlog-[DATE]-[TIME].log" and contain some system information at the top, followed by a stack trace and the contents of Kodi.log. If you didn't have debugging enabled at the time, please enable it and recreate the problem. This feature was added in SVN revision 22194 and relies on the gnu debugger GDB being installed to work.
- Mac OS X
- OS X will always create a Crashreporter log if any application crashes. These are found in /Users/username/Library/Logs/CrashReporter/CrashReporter.log where 'username' is the login username. For the Apple TV 1, the 'username' is 'frontrow'.
- The file will be in the same location as the debug log and named "Kodi_crashlog-[DATE]-[TIME].dmp". The dmp files will need to be uploaded to a location for download, as it's not a readable file. Moreover, we also ALWAYS require the kodi.pdb file (which is located next to the kodi.exe file) for total debugging. The pdb files are only available for test builds and releases.
4 Where do I create a bug report?
As per Devcon 2018, Team Kodi has decided to switch to a Github Tracker for administrating bugs/issues/projects for the Kodi application, and to get the open issues more visible to outside developers. Currently almost no one follows what happens on trac.kodi.tv, and things tend to simply get buried over time.
Moving it to a Github Tracker will get it all in one single place in order to better handle, and whatever we as Team Kodi feel are certain goals that might be interesting for outsiders to work on. Getting rid of "trac" will also save us from a big maintenance burden.