Official add-on repository

XBMC includes an interface to browse remote repositories from where add-ons can be retrieved. The model is similar to the way many current Linux distributions work, whereby there is a main repository that is the default, and additional ones may be added by the user. XBMC has two official repositories that are included by default (XBMC.org Add-ons and XBMC.org PVR Add-ons) and are maintained by the XBMC team (Team XBMC). This page outlines how to submit your add-on to the official repositories and keep it up to date.

1 The repositories

1.1 XBMC.org Add-ons

Browsing add-ons can be done from within XBMC through the built-in add-ons browser. From here you can install any add-on that is listed in the XBMC.org official repository. For the time being each version of XBMC will have its own repo which contain only add-ons that are compatible with that specific version of XBMC. Manually installing add-ons is possible but remember to check if these are compatible for your XBMC version.

XBMC uses Git to manage the official repository. See below for the list of git repositories that comprise it. This information is only useful for Team XBMC members who have repository pushing rights. You should not do any pull requests using these repositories. This is merely for information purpose only.

 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/plugins
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/scrapers
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/screensavers
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/scripts
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/skins
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/visualizations
 git clone git://xbmc.git.sourceforge.net/gitroot/xbmc/webinterfaces

All current add-ons can be downloaded as ZIP files from the repository server. Feel free to see which ones there are and perhaps you they might give you some ideas for creating your own. These are also great examples for getting started and see how things are done in more extensive add-ons.

1.2 XBMC.org PVR Add-ons

For more info on PVR see here: PVR

1.3 Repo Branches

For each version of XBMC there will be a specific branch of the XBMC.org add-on repository. As development progresses for the next version of XBMC, a repository for that next version will also be made. These repositories are automatically selected depending on which version of XBMC (stable or development) that the user is using. When the development XBMC repository is open we ask that add-on developers still maintain versions of their add-ons for the stable XBMC repository until that next development version of XBMC is released and becomes the new stable. When both repositories are open add-on developers will need to follow submission and update procedures individually to be in both. It is highly recommended to take advantage of the development XBMC repository so that your add-on is prepared for the next version of XBMC.

2 Repository Submission Guidelines - Please Read Before Submitting Your Addon

Because maintaining such a large repository is a large task, we have set some guidelines for inclusion. Please ensure that these guidelines are met before submitting request to be added. In order to be considered for the official repository, the following guidelines must be met:

• All addons must be developed as described on the Add-on development page.
• You must include a license file (named LICENSE.txt). We recommend the CC-BY-SA 3.0 for skins and the GPL v2+ for others, but most copyleft licenses will suffice.
• All files must be free and legal to distribute.
• The add-on must not violate any known copyright laws - if in doubt, let us know and we'll look into it for you.
• All source files must be included. No pre-compiled files or skins will be allowed.
• You acknowledge that you are the maintainer of your addon, but the XBMC team reserves the right to update or remove it at any time as we deem necessary.
• If a new stable XBMC is going to be released no new submissions are accepted to the repository for the previous version. This will start from when the first release candidate (RC) of the new version is released. Only fixes and updates will be accepted and processed for the previous version (e.g. if the current stable is 12.0 no updates are allowed for 10.1 anymore).

2.1 Updates

Keep in mind that add-ons in the official repository should be considered stable. This means that they should be well-tested before you submit them for inclusion. Because they are for stable users, they should avoid being updated too often. If your add-on is in rapid development, and features are constantly being added, hold off until you have hit a good stopping point and tested the current version.

This means that you should not submit a request every time you change your code. If you are submitting updates more than once per week something is wrong. Once per month is probably a better goal, barring unforeseen conditions (like a content source changing its paths).

2.2 General requirements

• All strings used by add-ons must be localized, no hard-coded language strings should ever be used
• All paths should be treated as case-sensitive, so that they work on all OSs and filesystems.
• All paths and files should be lower-case due to the previous point (except for README / COPYING / LICENSE.txt that should be upper-case).
• The following file-types are not allowed: .so .dll .pyo .exe .xbt .xpr Thumbs.db <binary files>
• All text files should use UNIX end-of-line

2.3 Requirements for skins

• The file size must be sane. There is no hard limit, but a 100mb skin is pushing it.
• No mods. Mods are great, and pop up frequently in the forums. But they are only confusing to non-forum-goers. This can be vague, each is evaluated on its own merit.

• All skins must be 100% valid XML. You should validate your code before submitting. Windows users can use the Notepad++ plugin for this.
• Skins must not include any scripts or plugins. If you need a script, submit it separately and depend on it.
• Any themes must be in a subfolder of the themes/ in the skin root. This is to ensure that TexturePacker picks them up correctly.
• Due to a bug in TexturePacker, all graphics files should have a resolution of at least 4x4.
• All paths should be treated as case-sensitive, so that they work on all OSs and filesystems.
• If you want to have some images outside of Textures.xbt, then make sure you place those images outside of the media/ folder and reference them using special://skin/backdrops/* or similar. This is most useful for backgrounds - it keeps the size of the packed textures down. Any images you have in the media/ folder will be placed in Textures.xbt in the official repository.
• All skins starting with Frodo must have a fanart.jpg included in the root dir. This must be a 1280x720 or 1920x1080 sized jpeg image.
• All skins starting with Eden must have a _screenshots folder included in the root dir and filled with 5-10 reasonably sized 1280x720 jpeg screenshots. For ex: skin.sample/_screenshots/screenshot01.jpg
• Note that .xbt files will be generated automatically for skins so you do not include this in your request.

2.3.1 Optional support

This is optional and should not block inclusion in official repo.

• mouse support
• touchscreen support
• karaoke dialogs
• peripheral dialogs
• pvr support

2.3.2 Basic sanity checks

Here's a list of what basic sanity checks are done by repo maintainer on each submission.

Basic file checks:

• all .xml files must pass xml validation
• all .xml/.txt must have unix style EOL's
• don't use a BOM at the start of your files
• file permissions: files should not be marked as executable
• filenames must have correct encoding (check your studio logos for corrupt filenames)

Things that must be included:

• addon.xml must contain correct and valid info / versioning
• LICENCE.txt must be present
• icon.png must be present (256x256)
• fanart.jpg must be present (1280x720 or 1920x1080)
• _screenshots folder must be present, containing max. 10 .jpg screenshots (1280x720)

Things that can't be included:

• no .xbt files
• no scripts included
• don't include unneeded files (.pdf, .doc, thumbs.db, etc...)
• no licensed fonts / background images / anything

Code checks:

• all labels must be localized
• code should be case-sensitive
• skins should not create warning/errors in the logfile, this can be a lot of things:

• invalid includes
• undefined actions
• unable to evaluate condition
• undefined vars
• can't focus 'id'

2.4 Requirements for scripts and plugins

• os.getcwd() is depreciated, please use getAddonInfo('path') instead
• all special:// paths should be translated using xbmc.translatePath("special://foo/bar")
• All scripts starting with Eden must have a fanart.jpg included in the root dir with a 1280x720 / 1920x1080 sized jpeg screenshot.
• Direct editing of the XBMC database is not allowed. You must use JSON RPC for this.
• Directly using analytics (Google Analytics for example) from with addons is not allowed. This should be handled server side by using user-agent.

2.5 Requirements for scrapers

• scraper must return the following minimum information: movie title, year, plot, cast, poster, fanart
• use 'chain function' for calling functions in common scrapers
• remove the depreciated XML tags from the scraper header in case you use a scraper editor made for pre-Dharma versions of XBMC

3 Submitting a Compliant Add-on to the XBMC.org Repo

After you have read the above repository guidelines and made sure your addon is compliant with them, you may begin the submission process using the following steps.

3.1 The mailing list

We ask that all Add-on authors subscribe to the Add-ons Mailing List. This is done for several reasons.

• This is where all updates and important information will be announced.
• This way we can contact you regarding your add-ons if necessary.
• You can see what other devs are requesting to be added so you know if possibly you need to check compatibility of the add-on you depend on.
• You may find new and interesting add-ons this way on which you can get inspiration from or may depend on.

All pull requests should be sent to this list so that repo maintainers will be notified that you want to add of update your add-on. They will do a sanity check if all seems ok and you are following the XBMC guidelines for add-ons. If any issues or questions arise they will contact you through the e-mail you registered with. Once all checks out fine your add-on is added to repo and you will receive a confirmation e-mail that it is added.

To un-subscribe from the mailinglist follow the same link as Add-ons Mailing List and there's the option to unsubscribe at the bottom

3.2 How to submit your add-on and subsequent updates

In order to submit your addon, you must send a request that we add or update your add-on to the Add-ons Mailing List (We call this a "pull request."). Each request will require a version bump in the addon.xml. We ask that you also keep a changelog.txt up to date so that users may easily see what has changed.

Note that .xbt files will be generated automatically for skins so you do not include this in your pull request.

There are several ways to request that we add or update your add-on. Please preface threads using the following conventions:

3.3 Example e-mail

Subject:

 [Git Pull] my cool plugin

Body:

 *addon -   my.cool.plugin
 *version - 1.1.0
 *url - git://some.where.git
 *revision - a241345a
 *branch - master
 *xbmc version - frodo

You have to do separate pull requests for each repository (Eden, Frodo/Gotham). At this moment Frodo and Gotham share the same repo so donig one request for Frodo/Gotham is enough. At this moment Frodo and Gotham share the same repo so donig one request for Frodo/Gotham is enough.

4 See also

• Add-ons
• Category:All add-ons
• 3rd party add-on repositories

Development:

• Add-on development
• Python development
• Skinning
• Add-on repositories