Kodi Community Forum

Full Version: An open letter to responsible script guys at XBMC
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
I absolutely love the idea about plugins since they blend in with all the skins realy nice, and i dont need to have some butt ugly old style gui showing up when i need to run addons.

However much i like plugins i have serious doubt's as to how much
they can ever become anything else than a feature for developers and geeks.

During the latest period i have tried alotta plugins and scripts with the result that only a handfull of all the scripts floating around seems to work, if i in addition remove the ones i had to "fix" searching these forums there is even fever who runs out of the box.

Offcourse one problem for alotta streaming scripts is offcourse that they will break often due to that the providers change theyr web pages and api's.
Another problem is that some scripts get released and then the author leaves the project and it's dead until someone else pick it up.

Trying to find out wich plugins that works on wich OS'es is a nightmare as it is now.

I don't mean to come to this forum just to nag about stuff not working but i would really like to think what team xbmc thinks for the future of plugins/addon scripts. Will it ever become a stable feature of xbmc ?

Atleast i bellive that there should be a "public" plugin/addon downloader that comes as default with xbmc. This downloader/installer should only install scritps that is tested to work on all plattforms. If this means like only 3 plugins then that is better then a large list of 50 plugins and only 3 really works.
And for those geeks amongst us who wants to they could configure this installer to also get scripts that is "untested". Much in the same way as we today use apt-get from different sources - stable or daily builds.

Basically: We need to have a SVN for 100% stable workings scripts.

Just my two cents...
Are you volunteering to moderate this list of working addons? And not get bored of it in two weeks?

The problem stems from 1) no one wants to sit around testing plugins they don't use and 2) 90% of who complain about the plugin situation never bother to do bug reports (I don't know about you... haven't bothered to check).

Edit: Sorry if that is harsh but really a dedicated QA team of knowledgeable users is the only way to do handle this... that or automated testing, which would require a rewrite of everything that has been written already.
There is a addons installer being worked on. And belive me I have given this long thoughts. And still I have no good solution to how we could maintain a list of working addons.

First option: As simple as it sounds, letting the user flag/report a non working addon from with either the addon or the installer. This would however give loads of false reports because of any of the following scenarios: user errors, wrong xbmc version, bad installation, network issues etc.

Second option: Have a group that test and approves addons on regular basis. This has been tested and there isn't anyone that has maintained such a list for a longer period than a couple of weeks.


I have tried to take some steps into easing this with the new installer.

There will be a manditory descriptive xml in it will be several helpful items:

- minor version of xbmc required to run the addon.
- what platforms it runs on (shouldn't need to be platform specific in general).
- contact info to the author.
- skinnable or not.
- translatable or not.

Also we are continiosly trying to improve xbmc's python to be more adjusted towards multiple platforms, one example being the new special:// paths.

If you have any constructive ideas or suggestion, I am more than willing to take those into consideration.
How about making the bug-reporting easy for people? In other words, what about some kind of thing that allows us to file reports from WITHIN XBMC? Or a simple "send bug report about this" menu item (on the top-level, where 'plugin settings' or 'set media type' would be seen in XBMC). If XBMC could have a 'debug' mode that can be entered into on a per-plugin basis without much fuss (automatically sending the log to the relevant people), you would have a far more significant flood of bug reports.
Blittan addressed that above: The problem is false positives due to pebkac - obviously the new installer is being designed to prevent that.

Whether we have user-reporting of problems or not, we will still need a dedicated set of QA people to act on reports, in addition to a regular testing schedule.

Cheers,
Jonathan
Two additional suggestions. XBMC for Windows currently checks OpenGL version and pops up a warning stating when the version isn't high enough. Creating such a check for XBMC revision would solve a lot of the user error problems. I have no idea how easy that would be, but it would solve the revision issue. The pop up could say something like "Your version of XBMC is out of date. Please update to a more recent build or wait to use this plugin until the next stable release."

Plugin creators would want to be included in an add-ons installer would then be required to append some kind of minimum working revision number to the program code, which XBMC would then parse, check against its own revision number, and decide whether to issue a warning.

I am no programmer, have no idea how to do this, and am not offering to try, but it's an option.

Second, I'm willing to volunteer my time as a QA team member, if that is ever required. I guess that's not really a suggestion, but I like the idea of going down the route the Iphone and, before that, the Linux (Ubuntu?) installer, where there is a main repository of awesome apps that requires no additional legwork to install.
w3__ Wrote:How about making the bug-reporting easy for people? In other words, what about some kind of thing that allows us to file reports from WITHIN XBMC? Or a simple "send bug report about this" menu item (on the top-level, where 'plugin settings' or 'set media type' would be seen in XBMC). If XBMC could have a 'debug' mode that can be entered into on a per-plugin basis without much fuss (automatically sending the log to the relevant people), you would have a far more significant flood of bug reports.

That is one thought I've had, but that means we would be spammed with false reports due to bad installs, wrong configs, faulty sites, networkconnections etc. The idea is really good, but lacks in lots of areas. We could ofcourse do that in some way and send the report to the author of the addon. But I am not satisfied with the amount of bad/false reports it would generate. More consideration is required before attempting such an approach.

natethomas Wrote:Two additional suggestions. XBMC for Windows currently checks OpenGL version and pops up a warning stating when the version isn't high enough. Creating such a check for XBMC revision would solve a lot of the user error problems. I have no idea how easy that would be, but it would solve the revision issue. The pop up could say something like "Your version of XBMC is out of date. Please update to a more recent build or wait to use this plugin until the next stable release."

Plugin creators would want to be included in an add-ons installer would then be required to append some kind of minimum working revision number to the program code, which XBMC would then parse, check against its own revision number, and decide whether to issue a warning.

I am no programmer, have no idea how to do this, and am not offering to try, but it's an option.

Second, I'm willing to volunteer my time as a QA team member, if that is ever required. I guess that's not really a suggestion, but I like the idea of going down the route the Iphone and, before that, the Linux (Ubuntu?) installer, where there is a main repository of awesome apps that requires no additional legwork to install.

The revision is checkable today and is used in some addons. This would be great if every author used it. Also if they preserved some kind of backwards compability in the script, not relying on the user having the belleding edge svn, but tried and keep functions so atleast the latest stable release is covered.

Glad to hear you would vounteer to such a team, might get inhandy Smile
blittan Wrote:That is one thought I've had, but that means we would be spammed with false reports due to bad installs, wrong configs, faulty sites, networkconnections etc. The idea is really good, but lacks in lots of areas. We could ofcourse do that in some way and send the report to the author of the addon. But I am not satisfied with the amount of bad/false reports it would generate. More consideration is required before attempting such an approach.

OK -- Maybe this is solvable in a different way. For example, why not use the OpenPasteBin API when this "run in debug mode" is entered into. The log would go there automatically and then XBMC would display the hashcode (additionally it could automatically copy the pastebin URL to the clipboard in non-XBMC builds).

Then it would be up to the reporter -- and there would be no flooding. But there would absolutely be more reporting?
So were you thinking like a context menu item for "Paste Debug Log"? Where it would sent to a site like pastebin and just give the user an address of the log?
Well yes, that's my suggestion for a compromise from what I originally suggested. Pasting plus displaying the hash on screen (ie - 'm6472fc80' for http://pastebin.com/m6472fc80)
Blittan:

Is their going to be code change within xbmc to support descriptive xml ? I prefer that xbmc do this, then plugin themselves. Let the plugin developers worry about other stuff. Here are some more additions to list on the xml :

1) Country -> What country it works on ..
2) SVN Repositiory to get files from ...

I take it we are going to have the ability to install/remove plugins ?

I was thinking of having XBMC log something to the server when ever we get a plugin script error. After 100 times, the plugin becomes disabled until the author fixes the issue ..
w3__ Wrote:OK -- Maybe this is solvable in a different way. For example, why not use the OpenPasteBin API when this "run in debug mode" is entered into. The log would go there automatically and then XBMC would display the hashcode (additionally it could automatically copy the pastebin URL to the clipboard in non-XBMC builds).

Then it would be up to the reporter -- and there would be no flooding. But there would absolutely be more reporting?

Trust me, there will be a flood of reports, although the idea is good, we need a way of filtering out the false reports somehow. One way is letting xbmc itself monitor if python crashes and if it does, report it. And also have the ability to report addons broken due to changes to the site it parses (for addons getting content from webpages).

Let's look at some facts, the current userbase of xbmc (roughly estimated is I would say around 1-1,5 million users). If for instance 2% reports an addon-error, this would generate 20000-30000 reports. I am sure there will not be anyone willing to go through all those reports.

CrashX Wrote:Blittan:

Is their going to be code change within xbmc to support descriptive xml ? I prefer that xbmc do this, then plugin themselves. Let the plugin developers worry about other stuff. Here are some more additions to list on the xml :

1) Country -> What country it works on ..
2) SVN Repositiory to get files from ...

I take it we are going to have the ability to install/remove plugins ?

I was thinking of having XBMC log something to the server when ever we get a plugin script error. After 100 times, the plugin becomes disabled until the author fixes the issue ..

There is no need for code changes, since the installer will be written in python. Adding country to the list is a pretty good idea, but is it really needed if it is stated within the description of the plugin.

The idea of disable the addon after an amount of errors, is a really good idea. But as I've stated before, we need a real solution for filtering out bad reports.
blittan Wrote:Trust me, there will be a flood of reports, although the idea is good, we need a way of filtering out the false reports somehow. One way is letting xbmc itself monitor if python crashes and if it does, report it. And also have the ability to report addons broken due to changes to the site it parses (for addons getting content from webpages).

I guess it would be possible to have the errors sent to a common server that analyse the log and updates the status on the script. The status must be based on platform, xbmc version, script version, type of error, error log ++ and the total number of errors reported with those data.
If you base the flagging on a good algorithm, it should be easy to see if there's a problem and what kind of problem it is.
The developers must have access to change the flag when fixed, and it probably should be a way to report working scripts as well to make the reports more accurate.

It's not waterproof, it requires a lot of work from system designers and script developers, it requires a server to handle the requests, and it was the first solution I thought of, but I think it might work if it's well designed.
MeediOS had a web based repository of plugins, each plugin had a "does this work" vote for it that any user registered on the forums (example). Users voted yes or no and the totals were added together to form a decision if it was working or not.

A module plugin was then written that could check against the web repository and update plugins from inside the GUI. It could filter updates, new, working, development status and categories of plugins.

Mods/admins on the website could also flag a plugin abandoned or non working. The plugin author could also flag a plugin to show it was alpha/beta/stable which helped show users its status. The number of downloads was also tracked centrally so people could quickly find the most popular plugins. The last thing was an automaticly generated link to the wiki so instructions were put in a standard place and format.

The system worked really well and was successful because it was integrated with the forums and website logins, there were over 550 plugins at last count. The PHP code is open source and could potentially be modified for XBMC plugins assuming a "packager" program was released to give each plugin an ID and standard XML description file.
blittan Wrote:There is no need for code changes, since the installer will be written in python. Adding country to the list is a pretty good idea, but is it really needed if it is stated within the description of the plugin.

The idea of disable the addon after an amount of errors, is a really good idea. But as I've stated before, we need a real solution for filtering out bad reports.

Sounds good as long as plugin developers don't have anything extra.

Actually it is up to plugin developers to file bad or good reports. We can enforce what are valid reports to submit .. ie file not found ..

zag2me Wrote:MeediOS had a web based repository of plugins, each plugin had a "does this work" vote for it that any user registered on the forums (example). Users voted yes or no and the totals were added together to form a decision if it was working or not.

A module plugin was then written that could check against the web repository and update plugins from inside the GUI. It could filter updates, new, working, development status and categories of plugins.

Mods/admins on the website could also flag a plugin abandoned or non working. The plugin author could also flag a plugin to show it was alpha/beta/stable which helped show users its status. The number of downloads was also tracked centrally so people could quickly find the most popular plugins. The last thing was an automaticly generated link to the wiki so instructions were put in a standard place and format.

The system worked really well and was successful because it was integrated with the forums and website logins, there were over 550 plugins at last count. The PHP code is open source and could potentially be modified for XBMC plugins assuming a "packager" program was released to give each plugin an ID and standard XML description file.

Looks good WinkWink
Pages: 1 2 3 4