Please Identify which addons are banned in rejected github bug reports
#1
Currently any banned addon in a debug log results in a bug report being marked invalid, but there's no indication of which addons in the log are banned.
By reporting issues we're trying to help - make it easier for us to comply with this requirement by listing which addons in the debug log are banned - that way we'll be able to remove the offender quickly and update the bug report, rather than the current situation where we have to examine a list (that we may not be able to find quickly) and then painfully identify any offenders.
Reply
#2
Hi,

thanks for taking the time to report issues. In general, you are expected to reproduce all issues on a clean installation (which normally implies no 3rd-party repositories), so the information of which specific add-on is unsupported is neither required nor helpful. There are admittedly cases where you cannot reproduce in a newly set up installation (such as when it concerns a DB upgrade), but that is really the exception to the rule. I think we could improve the message and our issue template in that regard, since currently it does not explicitly state that we expect this.

As for why we do not include this information at the moment, the text is (as you can probably guess) copy&paste to make bug triage more efficient. This process is likely to be further automated in the future, making it even more complicated to put this into the message.
Reply
#3
(2018-12-30, 17:32)davel Wrote: Currently any banned addon in a debug log results in a bug report being marked invalid, but there's no indication of which addons in the log are banned.
Most problem repos/add-ons/module entries will "light up" in orange when the kodi.log is pasted in https://paste.kodi.tv . This coloring is done based on Kodi's banned addons (wiki) page. This list is by no means a complete list, as such add-ons come and go on a regular basis.
Reply
#4
(2018-12-30, 19:04)Klojum Wrote:
(2018-12-30, 17:32)davel Wrote: Currently any banned addon in a debug log results in a bug report being marked invalid, but there's no indication of which addons in the log are banned.
Most problem repos/add-ons/module entries will "light up" in orange when the kodi.log is pasted in https://paste.kodi.tv . This coloring is done based on Kodi's banned addons (wiki) page. This list is by no means a complete list, as such add-ons come and go on a regular basis.  
As well as not having read anything that says the colour coding is indicative of such issues, as far as I can see, the colour coding only occurs after you save the item - which is a bit late in the day!
Reply
#5
(2018-12-30, 18:58)yol Wrote: As for why we do not include this information at the moment, the text is (as you can probably guess) copy&paste to make bug triage more efficient. This process is likely to be further automated in the future, making it even more complicated to put this into the message.
As you have some code that is already matching these texts, and if you're going to automate things further, why does this make it more complicated to add the matched addons to the message (by which I assume you mean more unlikely to be done)?
Go on, do the thing properly. I know infrastructure work is unglamorous, but make life easier for those trying to help improve the product by reporting issues - please Smile
Reply
#6
The list is part of the forum rules (wiki) that everyone who signs up for an account here has to agree to abide by and accept.

Of course whether people actually read them or not before doing so is another matter...
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
#7
Here's a thought. Don't install that junk in the first place
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#8
(2018-12-30, 21:02)DarrenHill Wrote: The list is part of the forum rules(wiki) that everyone who signs up for an account here has to agree to abide by and accept.

That does not really apply to GitHub unfortunately.
(2018-12-30, 19:20)davel Wrote: As you have some code that is already matching these texts, and if you're going to automate things further, why does this make it more complicated to add the matched addons to the message (by which I assume you mean more unlikely to be done)?
Go on, do the thing properly. I know infrastructure work is unglamorous, but make life easier for those trying to help improve the product by reporting issues - please Smile
The automation part is actually only in my head right now, so this is just my personal opinion. In detail, I wouldn't automatically flag logs as invalid. It's also really difficult to do so because people can use all sorts of upload services etc. (not limited to paste.kodi.tv) for their logs. So it's not possible to have some generic code that downloads the log from a GH issue. My automation suggestion would be to have an automatic pre-defined message sent when an issue is labeled INVALID. Also, with including the specific add-ons in the message, we would actually be moving in the wrong direction as far as I am concerned. Because with that we are setting an incentive to *just remove those add-ons*, while what we want is preferably a clean install.
Reply
#9
(2019-01-04, 21:08)yol Wrote:
(2018-12-30, 21:02)DarrenHill Wrote: The list is part of the forum rules(wiki) that everyone who signs up for an account here has to agree to abide by and accept.

That does not really apply to GitHub unfortunately.
(2018-12-30, 19:20)davel Wrote: As you have some code that is already matching these texts, and if you're going to automate things further, why does this make it more complicated to add the matched addons to the message (by which I assume you mean more unlikely to be done)?
Go on, do the thing properly. I know infrastructure work is unglamorous, but make life easier for those trying to help improve the product by reporting issues - please Smile
The automation part is actually only in my head right now, so this is just my personal opinion. In detail, I wouldn't automatically flag logs as invalid. It's also really difficult to do so because people can use all sorts of upload services etc. (not limited to paste.kodi.tv) for their logs. So it's not possible to have some generic code that downloads the log from a GH issue. My automation suggestion would be to have an automatic pre-defined message sent when an issue is labeled INVALID. Also, with including the specific add-ons in the message, we would actually be moving in the wrong direction as far as I am concerned. Because with that we are setting an incentive to *just remove those add-ons*, while what we want is preferably a clean install.      
I can understand why you might want to eliminate reports that include illegal addons, but by insisting on clean installs to reproduce issues you're surely going to alienate people from reporting issues.
Is there something inherently dangerous about the addon interfaces being able to corrupt Kodi, that makes a clean install preferable?
Reply
#10
Some of the banned addons (wiki) have been known to stick their tentacles in all sorts of unexpected places to try and stay in place (and to leave active scripts etc behind running when they are uninstalled). Plus many of them were so badly written that they either made the core app unstable or just plain screwed it up.

We got so fed up with trying to untangle those cases from genuine core bug issues, which is why we request either removal or for heavy infections clean installs.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
#11
There are more reasons to want clean installs than only the banned add-ons, even though they do play a big part as @DarrenHill mentions. You get a new, fresh profile without any leftover cruft from updates, you have a fresh DB, no weird settings, no add-ons at all etc. It just helps a lot to narrow down where the problem lies. And you get reproduction steps that actually work from a clean install - which is all the developers have to go on to reproduce.

In a recent issue we finally got a reporter who claimed that he was quite sure MySQL had nothing to do with the problem to try on a clean install after some discussion, and - surprise, surprise - the issue was not present on a clean SQLite installation and appeared as soon as he put the MySQL DB back in. If he'd started with a clean install, we would have saved a lot of time dancing around the issue. A few devs wasted their time trying to reproduce the issue while it wasn't clear what was causing it and it would have easily been found with a clean install. Just as an example.
Reply
#12
(2019-01-05, 00:16)davel Wrote: Is there something inherently dangerous about the addon interfaces being able to corrupt Kodi, that makes a clean install preferable?

Maybe you did not know, but Kodi add-ons are not sandboxed or anything at all. They are just Python programs that can do basically everything, including formatting your hard drive. So yes, they are absolutely able to corrupt Kodi.
Reply
#13
(2019-01-05, 11:59)yol Wrote:
(2019-01-05, 00:16)davel Wrote: Is there something inherently dangerous about the addon interfaces being able to corrupt Kodi, that makes a clean install preferable?

Maybe you did not know, but Kodi add-ons are not sandboxed or anything at all. They are just Python programs that can do basically everything, including formatting your hard drive. So yes, they are absolutely able to corrupt Kodi.   
 I didn't know, I just suspected that might be the case Sad
Reply

Logout Mark Read Team Forum Stats Members Help
Please Identify which addons are banned in rejected github bug reports0