Official Kodi Wiki - User contributions [en]

Addon.xml

2014-04-27T00:34:39Z

Jmarshall: /* How versioning works */

{{mininav|[[Development]]|[[Add-on development]]}}
 
{{frodo updated}}

= Introduction =

Every skin, script, or plugin in XBMC contains an <code>addon.xml</code> file which describes the add-on, providing credits, version information and dependencies. Below, we will explain how this file is structured and which elements must be used to create an add-on for XBMC. You can also consult the examples at the end to see how this file is laid out depending on if you are developing a skin or script/plugin.

Every <code>addon.xml</code> file has the same basic structure:

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon id="your.addon.id" name="Your Add-on" version="1.2.3" provider-name="You">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
</requires>
<extension point="xbmc.python.pluginsource" library="addon.py">
<provides>video</provides>
</extension>
<extension point="xbmc.addon.metadata">
<summary lang="en">Your add-on's summary</summary>
<description lang="en">Your add-on's description</description>
<disclaimer lang="en"></disclaimer>
<language></language>
<platform>all</platform>
<license></license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>

There are a few important things to note in the above sample:

* The <code><addon></code> element must be present, and be the root node. It presents data about the add-on package as a whole.
* Inside the <code><addon></code> element is a <code><requires></code> element, listing all the dependencies that this add-on needs in order to function.
* Then there are one or more <code><extension></code> elements, each of which describes a part of XBMC that the add-on extends.
* Finally, there is a specific <code><extension></code> element that extends <code>"xbmc.addon.metadata"</code>. This describes the add-on to the user.

= Elements =

== <addon> ==

The <code><addon></code> element has 4 attributes, all required: <code>id</code>, <code>version</code>, <code>name</code>, and <code>provider-name</code>. For example:

<source lang="xml">
<addon id="script.hello.world" name="Hello World" version="0.0.1" provider-name="Dev1, Dev2">
</source>

=== id attribute ===

The id attribute is the unique identifier used for this add-on. It must be unique, and must use only lowercase characters, periods, underscores, dashes and numbers. This identifier is also used as the name of the folder that contains the add-on, so for ease of searching, we suggest you use something like <type>.<uniquename>.

=== version attribute ===

The version attribute is used by XBMC to determine whether updates are available. This should be use a version scheme like <code>x.y.z</code> (major.minor.patch). For example: <code>version="0.0.1"</code>. Generally, you'll start with a version of <code>0.y.z</code> for test releases and once you feel it is ready for a full release, you'd bump the version to <code>1.0.0</code>.

==== How versioning works ====

* <code>2.2.9</code> is newer than <code>2.2.1</code>
* <code>2.2.10</code> is newer than <code>2.2.1</code>
* <code>2.3.0</code> is newer than <code>2.2.9</code>
* <code>2.2.1</code> is newer than <code>2.2.1~alpha</code>
* <code>2.2.1</code> is newer than <code>2.2.1~beta</code>
* <code>2.2.1~beta</code> is newer than <code>2.2.1~alpha</code>
* <code>2.2.1~beta3</code> is newer than <code>2.2.1~beta2</code>
* <code>2.2.1~beta10</code> is newer than <code>2.2.1~beta1</code>

{{tip|Text should only be added for a beta version. In other cases version number should only contain numbers.}}

=== name attribute ===

The name attribute is the name of the add-on as it appears in the UI. This should be in English where it makes sense for it to be so, and is not translatable.

=== provider-name attribute ===

The provider-name attribute is used as the author field. This could be a team of authors or a single author. If the add-on is maintained by multiple people please separate them with a comma (<code>,</code>).

== <requires> ==

The <code><requires></code> element contains one or more <code><import></code> elements which specify which other add-ons this particular add-on requires, and which version of those add-ons it requires. These add-ons may be part of XBMC itself, or may be parts of other third-party add-ons.

XBMC will only allow the add-on to be run if suitable versions of the (non-optional) add-ons on which this add-on depends are installed. When a user installs your add-on from an online repository via XBMC's add-on manager, XBMC attempts to resolve these dependencies, and install anything that your add-on relies on first. The dependency must be provided with the minimum version number your script/skin requires.

=== Examples ===

Here is a sample <code><requires></code> block that imports two required modules and one optional one:

<source lang="xml">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
<import addon="script.module.elementtree" version="1.2.7"/>
<import addon="script.module.simplejson" version="2.0.10" optional="true"/>
</requires>
</source>

Here's another example, which will only install on OpenELEC:

<source lang="xml">
<requires>
<import addon="os.openelec.tv" version="2.0" optional="false"/>
</requires>
</source>

== <import> ==

Each <code><import></code> element describes one dependency for an add-on, with two required attributes: <code>addon</code> and <code>version</code>. There is also an optional attribute called, fittingly, <code>optional</code>.

If your add-on relies on other third-party add-ons, XBMC will automatically install them as well, provided they are available on an existing add-on repository. If they aren't available on any existing repository, the user must install the other add-ons themselves. Note that you need to include any Python libraries you need directly in your add-on; these can't be loaded with an <code><import></code> element, since XBMC wouldn't know what to do with them.

=== addon attribute ===

The <code>addon</code> attribute specifies the id of the required add-on, e.g. <code>script.module.elementtree</code>.

=== version attribute ===

The <code>version</code> attribute specifies the minimum version of the required add-on to be installed.

==== Dependency versions ====

Each different XBMC version might require you to use a higher version of the <code>xbmc.*</code> add-on dependencies to control on which version of XBMC the add-on can be installed.

{| class="prettytable" border="1"
|+ Current versions
! XBMC version !! xbmc.python !! xbmc.gui !! xbmc.json !! xbmc.metadata !! xbmc.addon
|-
| Dharma 10.1 Deprecated|| 1.0 || 2.11 || 2.0|| 1.0 || 0.1
|-
| Eden 11.0 || 2.0 || 3.0 || 4.0 || 1.0 || 11.0
|-
| Frodo 12.0 & 12.1 & 12.2 || 2.1.0 || 4.0.0 || 6.0.0 || 2.1.0 || 12.0.0
|-
| Gotham 13.0 || 2.14.0 || 5.0.1 || 6.6.0 || 2.1.0 || 12.0.0
|}

=== optional attribute ===

The dependency may be made optional by setting the <code>optional</code> attribute to <code>true</code>. This will only install the dependency when the add-on actually needs it. Even if this dependency is missing, the add-on can still be installed.

== <extension> ==

The <code><extension></code> element describes the technical aspects of this add-on. It will have at least a point attribute which will give the part of XBMC that the add-on extends. For instance, the <code>addon.xml</code> file for the Confluence skin extends the <code>xbmc.gui.skin</code> part of XBMC. All available extension points are given below.

The various extension points that XBMC provides are given in the list below.
{| class="prettytable"
!Extension point
!Add-on Category
|-
|<code>[[Add-ons for XBMC (Development)#addon.xml|xbmc.gui.skin]]</code>
|Skin
|-
|<code>xbmc.gui.webinterface</code>
|Web interface
|-
|<code>[[Add-ons for XBMC (Developement)#Repository Add-on|xbmc.addon.repository]]</code>
|''None''
|-
|<code>[[HOW-TO:_Automatically_start_addons_using_services|xbmc.service]]</code>
|Services
|-
|<code>xbmc.metadata.scraper.albums</code>
|Album information
|-
|<code>xbmc.metadata.scraper.artists</code>
|Artist information
|-
|<code>xbmc.metadata.scraper.movies</code>
|Movie information
|-
|<code>xbmc.metadata.scraper.musicvideos</code>
|Music video information
|-
|<code>xbmc.metadata.scraper.tvshows</code>
|TV information
|-
|<code>xbmc.metadata.scraper.library</code>
|''None''
|-
|<code>xbmc.ui.screensaver</code>
|Screensaver
|-
|<code>xbmc.player.musicviz</code>
|Visualization
|-
|<code>[[Plugin Sources#What XBMC requires for your add-on|xbmc.python.pluginsource]]</code>
|Music Add-ons (audio) / Picture Add-ons (image) / Program Add-ons (executable) / Video Add-ons (video)
|-
|<code>[[Script Sources#What XBMC requires for your add-on|xbmc.python.script]]</code>
|Music Add-ons (audio) / Picture Add-ons (image) / Program Add-ons (executable) / Video Add-ons (video)
|-
|<code>xbmc.python.weather</code>
|Weather
|-{{Gotham row}}
|<code>[[Script Subtitles#What XBMC requires for your add-on|xbmc.python.subtitles]]</code>
|'''([[:Category:Gotham feature|Future Gotham removal]])''' Subtitles
|-{{Gotham row}}
|<code>xbmc.subtitle.module</code>
|'''([[:Category:Gotham feature|Future Gotham addition]])''' Subtitle service module
|-
|<code>[[Script Lyrics#What XBMC requires for your add-on|xbmc.python.lyrics]]</code>
|Lyrics
|-
|<code>[[Script Library#What XBMC requires for your add-on|xbmc.python.library]]</code>
|''None''
|-
|<code>xbmc.python.module</code>
|These don't show up in the addon browser and are purely as support for other scripts.
|-
|<code>xbmc.addon.video</code>
|Video Add-ons (video)
|-
|<code>xbmc.addon.audio</code>
|Music Add-ons (audio)
|-
|<code>xbmc.addon.image</code>
|Picture Add-ons (image)
|}

Add-ons that don't correspond to a specific add-on category can not be installed by users. These are usually supporting or shared add-ons that are installed automatically by the add-ons that require them.

=== xbmc.python.pluginsource ===
{{See also|Plugin Sources}}

The most common extension point that will be used by plugin addon developers is <code>xbmc.python.pluginsource</code>.

==== library attribute ====

The <code><extension point="xbmc.python.pluginsource"></code> element has an extra attribute: <code>library</code>. This is the name of the Python script (startup script) that will be run when the add-on is activated. This file must exist in the root of your add-on directory.

==== <provides> element ====

The extension has an additional child element named <code><provides></code>, which contains a whitespace separated list of <code>image</code>, <code>video</code>, <code>audio</code>, and/or <code>executable</code>. This determines in what area (or context) of the XBMC system your addon will make itself visible in:

{| class="prettytable"
!Provides
!Appears in
|-
|<code>image</code>
|Pictures
|-
|<code>audio</code>
|Music
|-
|<code>video</code>
|Video
|-
|<code>executable</code>
|Programs
|-
|''(blank)''
|Not visible
|}

==== Example ====

<source lang="xml">
<extension point="xbmc.python.pluginsource" library="gpodderxbmc.py">
<provides>audio video</provides>
</extension>
</source>

=== xbmc.addon.metadata ===

This special extension point ''must'' be provided by all add-ons, and is the way that your add-on is described to users of the XBMC add-on manager.

==== Required elements ====

There are several elements that this should contain and all are compulsory (except the broken tag). Each of the elements below must always be present in English as a minimum.

Many of these elements can be translated into multiple languages and should be added once for each supported language. See the [[List of language codes (ISO-639:1988)]] for possible language strings. If there's no <code>lang</code> attribute for a translatable element, it defaults to English. However, even for English, adding the <code>lang</code> attribute is recommended.

===== <summary> =====

One or more <code><summary></code> elements provide a short summary of what the add-on does. This should be a single sentence. It may be translated into multiple languages.

<source lang="xml">
<summary lang="en">Hello World script provides some basic examples on how to create your first script.</summary>
</source>

===== <description> =====

One or more <code><description></code> elements provide a more detailed summary of what the add-on does. It may be translated into multiple languages.

<source lang="xml">
<description lang="en">Hello World script provides some basic examples on how to create your first script
and hopefully will increase the number of XBMC users to start creating their own addons.</description>
</source>

===== <platform> =====

The <code><platform></code> tag specifies which platforms (operating systems, hardware) this add-on runs on. Many add-ons will run on all platforms, so <code>all</code> is an option. If the platform tag is missing, we assume the add-on runs on all platforms. A combination of these is also possible. Currently available options are:

* <code>all</code>
* <code>linux</code>
* <code>osx</code>
* <code>osx64</code>
* <code>osx32</code>
* <code>ios</code>
* <code>windx</code>
* <code>wingl</code>
* <code>android</code>

<source lang="xml">
<platform>all</platform>
</source>

===== <language> =====

The <code><language></code> elements indicate the language(s) of the ''content'' provided by your add-on. It applies to plugins, scripts, scrapers etc. This allows browsing the add-on list by language. When there is no specific language provided in your content, leave it blank.

<source lang="xml">
<language>en de fr</language>
or
<language></language>
</source>

===== <license> =====

The <code><license></code> element indicates what license is used for this add-on.

<source lang="xml">
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
</source>

===== <forum> =====

The <code><forum></code> element provides the forum thread URL for this specific add-on. Leave this blank if there is no forum thread.
<source lang="xml">
<forum>http://www.myaddonwebsite.com/forum.php?thread=12345</forum>
</source>

===== <website> =====

The <code><website></code> element provides the website URL for this specific add-on.

<source lang="xml">
<website>http://www.myaddonwebsite.com/</website>
</source>

===== <nowiki><source></nowiki> =====

The <code><nowiki><source></nowiki></code> element provides the URL for the source code for this specific add-on.
<syntaxhighlight lang="xml" enclose="div">
<source>http://github.com/someone/myaddon</source>
</syntaxhighlight>

===== <email> =====

The <code><email></code> element provides the email address of the author if he wishes to do so for this specific add-on. Here are two examples of how you can make it look (the second one it harder for spambots to use). This can be left blank if you do not want to make your email address public.
<source lang="xml">
<email>foo@bar.com</email>
or
<email>foo at bar dot com</email>
</source>

===== <disclaimer> =====

One or more <code><disclaimer></code> elements that indicate what (if any) things the user should know about the add-on. There is no need to have a disclaimer if you don't want one, though if something requires settings, or only works in a particular country then you may want to state this here. It may be translated into multiple languages.

<source lang="xml">
<disclaimer lang="en">Feel free to use this script. For information visit the wiki.</disclaimer>
</source>

===== <broken> =====

The <code><broken></code> tag will mark the add-on as broken in the XBMC repo and provide the reason why. You don't need to do a version bump for this to work. However a bump is recommended as you could also add this to the changelog.

<source lang="xml">
<broken>deprecated</broken>
</source>

== Skin specific elements ==
=== Overview ===
{| class="prettytable"
| '''defaultresolution'''
| Default resolution folder for this skin. This is the base directory that all window xml file requests will fall back to.
|-
| '''defaultresolutionwide'''
| Default widescreen resolution folder for this skin. This is the directory that all window xml file requests from widescreen resolutions (1080i, 720p, 480p 16x9, NTSC 16x9 and PAL 16x9) will fallback to. If the file isn't found in this window, then it'll fall back to the <defaultresolution> folder.
|-
| '''defaultthemename'''
| Default theme name. Currently set to: Default.
|-
| '''effectslowdown'''
| A multiplier that is applied to all <animation> effect lengths in the skin. Useful to slow down all animations globally so that you can better configure timings and see interactions between animating controls.
|-
| '''debugging'''
| When set to true, it'll display onscreen debug information (xml filename, mouse position and focused control type and name) in the skin.

|-
| '''res'''
| Support for arbitrary skin resolutions.
|}

=== How window xml files are found ===

XBMC can run in many differing resolutions, and a skin should try and cater to all these resolutions. The easiest way is to develop for one specific resolution and make sure that all controls contain <width> and <height> tags. That way, XBMC can scale the controls to the new screen resolution.

However, you may choose to develop alternative window xml files for differing resolutions (such as for HDTV resolutions, or for widescreen versus 4x3 resolutions).

The order that XBMC looks for it's skin files are as follows:

# It first looks in the current screenmode folder (one of 1080i, 720p, NTSC16x9, NTSC, PAL16x9 or PAL)
# If the current screenmode is 1080i, it then looks in the 720p folder.
# If the current screenmode is a widescreen mode (1080i, 720p, NTSC16x9, PAL16x9) then it looks in the <defaultresolutionwide> folder.
# Finally, it looks in the <defaultresolution> folder.

This allows you to just put any window files that do not require special treatment for 16x9 resolutions etc. in the <defaultresolution> folder, preventing needless repetition.

= Examples =

== addon.xml for skins ==

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8"?>
<addon
id="skin.confluence"
version="2.1.3"
name="Confluence"
provider-name="Jezz_X, Team XBMC">
<requires>
<import addon="xbmc.gui" version="4.0.0"/>
</requires>
<extension
point="xbmc.gui.skin"
defaultthemename="textures.xbt"
debugging="false"
effectslowdown="0.75">
<res width="1280" height="720" aspect="16:9" default="true" folder="720p" />
</extension>
<extension point="xbmc.addon.metadata">
<summary lang="en">Confluence skin by Jezz_X. (XBMC's default skin)</summary>
<description lang="en">Confluence is the default skin for XBMC 9.11 and above. It is a combination of concepts from many popular skins, and attempts to embrace and integrate their good ideas into a skin that should be easy for first time XBMC users to understand and use.</description>
<disclaimer lang="en">Confluence is the default skin for XBMC, removing it may cause issues</disclaimer>
<platform>all</platform>
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>
One thing to note is that all tag names are lower case. XML tag names are case sensitive!

== addon.xml for scripts/plugins ==

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon
id="script.artwork.downloader"
name="Artwork Downloader"
version="12.0.12"
provider-name="Martijn">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
<import addon="xbmc.json" version="6.0.0"/>
<import addon="xbmc.addon" version="12.0.0"/>
<import addon="script.module.elementtree" version="1.2.7"/>
<import addon="script.module.simplejson" version="2.0.10" optional="true"/>
<import addon="script.common.plugin.cache" version="1.3.0"/>
</requires>
<extension point="xbmc.python.script" library="default.py">
<provides>executable</provides>
</extension>
<extension point="xbmc.service" library="service.py" start="login"/>
<extension point="xbmc.addon.metadata">
<summary lang="en">Downloads Artwork for TV shows, Movies and Musicvideos in your library</summary>
<description lang="en">Downloads all available artwork for TV shows, Movies and Musicvideos in your library. Check the options for supported artwork[CR]Artwork sources:[CR]www.fanart.tv[CR]www.thetvdb.com[CR]www.themoviedb.org[CR]Remark:[CR]Check your skin to see what type of artwork is supported![CR]Each TV Show/Movie must have its own folder![CR]Skin integration:[CR]See readme file</description>
<disclaimer lang="en">For bugs, requests or general questions visit the Artwork Downloader thread on the XBMC forum.</disclaimer>
<language></language>
<platform>all</platform>
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>

= Schema Definition =

The XML schema definition for <code>addon.xml</code> is located [https://github.com/xbmc/xbmc/blob/master/addons/xbmc.addon/metadata.xsd here].

[[Category:Add-on development]]
[[Category:Skin development]]

Addon.xml

2014-04-27T00:33:39Z

Jmarshall: /* How versioning works */

{{mininav|[[Development]]|[[Add-on development]]}}
 
{{frodo updated}}

= Introduction =

Every skin, script, or plugin in XBMC contains an <code>addon.xml</code> file which describes the add-on, providing credits, version information and dependencies. Below, we will explain how this file is structured and which elements must be used to create an add-on for XBMC. You can also consult the examples at the end to see how this file is laid out depending on if you are developing a skin or script/plugin.

Every <code>addon.xml</code> file has the same basic structure:

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon id="your.addon.id" name="Your Add-on" version="1.2.3" provider-name="You">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
</requires>
<extension point="xbmc.python.pluginsource" library="addon.py">
<provides>video</provides>
</extension>
<extension point="xbmc.addon.metadata">
<summary lang="en">Your add-on's summary</summary>
<description lang="en">Your add-on's description</description>
<disclaimer lang="en"></disclaimer>
<language></language>
<platform>all</platform>
<license></license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>

There are a few important things to note in the above sample:

* The <code><addon></code> element must be present, and be the root node. It presents data about the add-on package as a whole.
* Inside the <code><addon></code> element is a <code><requires></code> element, listing all the dependencies that this add-on needs in order to function.
* Then there are one or more <code><extension></code> elements, each of which describes a part of XBMC that the add-on extends.
* Finally, there is a specific <code><extension></code> element that extends <code>"xbmc.addon.metadata"</code>. This describes the add-on to the user.

= Elements =

== <addon> ==

The <code><addon></code> element has 4 attributes, all required: <code>id</code>, <code>version</code>, <code>name</code>, and <code>provider-name</code>. For example:

<source lang="xml">
<addon id="script.hello.world" name="Hello World" version="0.0.1" provider-name="Dev1, Dev2">
</source>

=== id attribute ===

The id attribute is the unique identifier used for this add-on. It must be unique, and must use only lowercase characters, periods, underscores, dashes and numbers. This identifier is also used as the name of the folder that contains the add-on, so for ease of searching, we suggest you use something like <type>.<uniquename>.

=== version attribute ===

The version attribute is used by XBMC to determine whether updates are available. This should be use a version scheme like <code>x.y.z</code> (major.minor.patch). For example: <code>version="0.0.1"</code>. Generally, you'll start with a version of <code>0.y.z</code> for test releases and once you feel it is ready for a full release, you'd bump the version to <code>1.0.0</code>.

==== How versioning works ====

* <code>2.2.9</code> is newer than <code>2.2.1</code>
* <code>2.2.10</code> is newer than <code>2.2.1</code>
* <code>2.3</code> is newer than <code>2.2.9</code>
* <code>2.3.0</code> is newer than <code>2.2</code>
* <code>2.2.1</code> is newer than <code>2.2.1~alpha</code>
* <code>2.2.1</code> is newer than <code>2.2.1~beta</code>
* <code>2.2.1~beta</code> is newer than <code>2.2.1~alpha</code>
* <code>2.2.1~beta3</code> is newer than <code>2.2.1~beta2</code>
* <code>2.2.1~beta10</code> is newer than <code>2.2.1~beta1</code>

{{tip|Text should only be added for a beta version. In other cases version number should only contain numbers.}}

=== name attribute ===

The name attribute is the name of the add-on as it appears in the UI. This should be in English where it makes sense for it to be so, and is not translatable.

=== provider-name attribute ===

The provider-name attribute is used as the author field. This could be a team of authors or a single author. If the add-on is maintained by multiple people please separate them with a comma (<code>,</code>).

== <requires> ==

The <code><requires></code> element contains one or more <code><import></code> elements which specify which other add-ons this particular add-on requires, and which version of those add-ons it requires. These add-ons may be part of XBMC itself, or may be parts of other third-party add-ons.

XBMC will only allow the add-on to be run if suitable versions of the (non-optional) add-ons on which this add-on depends are installed. When a user installs your add-on from an online repository via XBMC's add-on manager, XBMC attempts to resolve these dependencies, and install anything that your add-on relies on first. The dependency must be provided with the minimum version number your script/skin requires.

=== Examples ===

Here is a sample <code><requires></code> block that imports two required modules and one optional one:

<source lang="xml">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
<import addon="script.module.elementtree" version="1.2.7"/>
<import addon="script.module.simplejson" version="2.0.10" optional="true"/>
</requires>
</source>

Here's another example, which will only install on OpenELEC:

<source lang="xml">
<requires>
<import addon="os.openelec.tv" version="2.0" optional="false"/>
</requires>
</source>

== <import> ==

Each <code><import></code> element describes one dependency for an add-on, with two required attributes: <code>addon</code> and <code>version</code>. There is also an optional attribute called, fittingly, <code>optional</code>.

If your add-on relies on other third-party add-ons, XBMC will automatically install them as well, provided they are available on an existing add-on repository. If they aren't available on any existing repository, the user must install the other add-ons themselves. Note that you need to include any Python libraries you need directly in your add-on; these can't be loaded with an <code><import></code> element, since XBMC wouldn't know what to do with them.

=== addon attribute ===

The <code>addon</code> attribute specifies the id of the required add-on, e.g. <code>script.module.elementtree</code>.

=== version attribute ===

The <code>version</code> attribute specifies the minimum version of the required add-on to be installed.

==== Dependency versions ====

Each different XBMC version might require you to use a higher version of the <code>xbmc.*</code> add-on dependencies to control on which version of XBMC the add-on can be installed.

{| class="prettytable" border="1"
|+ Current versions
! XBMC version !! xbmc.python !! xbmc.gui !! xbmc.json !! xbmc.metadata !! xbmc.addon
|-
| Dharma 10.1 Deprecated|| 1.0 || 2.11 || 2.0|| 1.0 || 0.1
|-
| Eden 11.0 || 2.0 || 3.0 || 4.0 || 1.0 || 11.0
|-
| Frodo 12.0 & 12.1 & 12.2 || 2.1.0 || 4.0.0 || 6.0.0 || 2.1.0 || 12.0.0
|-
| Gotham 13.0 || 2.14.0 || 5.0.1 || 6.6.0 || 2.1.0 || 12.0.0
|}

=== optional attribute ===

The dependency may be made optional by setting the <code>optional</code> attribute to <code>true</code>. This will only install the dependency when the add-on actually needs it. Even if this dependency is missing, the add-on can still be installed.

== <extension> ==

The <code><extension></code> element describes the technical aspects of this add-on. It will have at least a point attribute which will give the part of XBMC that the add-on extends. For instance, the <code>addon.xml</code> file for the Confluence skin extends the <code>xbmc.gui.skin</code> part of XBMC. All available extension points are given below.

The various extension points that XBMC provides are given in the list below.
{| class="prettytable"
!Extension point
!Add-on Category
|-
|<code>[[Add-ons for XBMC (Development)#addon.xml|xbmc.gui.skin]]</code>
|Skin
|-
|<code>xbmc.gui.webinterface</code>
|Web interface
|-
|<code>[[Add-ons for XBMC (Developement)#Repository Add-on|xbmc.addon.repository]]</code>
|''None''
|-
|<code>[[HOW-TO:_Automatically_start_addons_using_services|xbmc.service]]</code>
|Services
|-
|<code>xbmc.metadata.scraper.albums</code>
|Album information
|-
|<code>xbmc.metadata.scraper.artists</code>
|Artist information
|-
|<code>xbmc.metadata.scraper.movies</code>
|Movie information
|-
|<code>xbmc.metadata.scraper.musicvideos</code>
|Music video information
|-
|<code>xbmc.metadata.scraper.tvshows</code>
|TV information
|-
|<code>xbmc.metadata.scraper.library</code>
|''None''
|-
|<code>xbmc.ui.screensaver</code>
|Screensaver
|-
|<code>xbmc.player.musicviz</code>
|Visualization
|-
|<code>[[Plugin Sources#What XBMC requires for your add-on|xbmc.python.pluginsource]]</code>
|Music Add-ons (audio) / Picture Add-ons (image) / Program Add-ons (executable) / Video Add-ons (video)
|-
|<code>[[Script Sources#What XBMC requires for your add-on|xbmc.python.script]]</code>
|Music Add-ons (audio) / Picture Add-ons (image) / Program Add-ons (executable) / Video Add-ons (video)
|-
|<code>xbmc.python.weather</code>
|Weather
|-{{Gotham row}}
|<code>[[Script Subtitles#What XBMC requires for your add-on|xbmc.python.subtitles]]</code>
|'''([[:Category:Gotham feature|Future Gotham removal]])''' Subtitles
|-{{Gotham row}}
|<code>xbmc.subtitle.module</code>
|'''([[:Category:Gotham feature|Future Gotham addition]])''' Subtitle service module
|-
|<code>[[Script Lyrics#What XBMC requires for your add-on|xbmc.python.lyrics]]</code>
|Lyrics
|-
|<code>[[Script Library#What XBMC requires for your add-on|xbmc.python.library]]</code>
|''None''
|-
|<code>xbmc.python.module</code>
|These don't show up in the addon browser and are purely as support for other scripts.
|-
|<code>xbmc.addon.video</code>
|Video Add-ons (video)
|-
|<code>xbmc.addon.audio</code>
|Music Add-ons (audio)
|-
|<code>xbmc.addon.image</code>
|Picture Add-ons (image)
|}

Add-ons that don't correspond to a specific add-on category can not be installed by users. These are usually supporting or shared add-ons that are installed automatically by the add-ons that require them.

=== xbmc.python.pluginsource ===
{{See also|Plugin Sources}}

The most common extension point that will be used by plugin addon developers is <code>xbmc.python.pluginsource</code>.

==== library attribute ====

The <code><extension point="xbmc.python.pluginsource"></code> element has an extra attribute: <code>library</code>. This is the name of the Python script (startup script) that will be run when the add-on is activated. This file must exist in the root of your add-on directory.

==== <provides> element ====

The extension has an additional child element named <code><provides></code>, which contains a whitespace separated list of <code>image</code>, <code>video</code>, <code>audio</code>, and/or <code>executable</code>. This determines in what area (or context) of the XBMC system your addon will make itself visible in:

{| class="prettytable"
!Provides
!Appears in
|-
|<code>image</code>
|Pictures
|-
|<code>audio</code>
|Music
|-
|<code>video</code>
|Video
|-
|<code>executable</code>
|Programs
|-
|''(blank)''
|Not visible
|}

==== Example ====

<source lang="xml">
<extension point="xbmc.python.pluginsource" library="gpodderxbmc.py">
<provides>audio video</provides>
</extension>
</source>

=== xbmc.addon.metadata ===

This special extension point ''must'' be provided by all add-ons, and is the way that your add-on is described to users of the XBMC add-on manager.

==== Required elements ====

There are several elements that this should contain and all are compulsory (except the broken tag). Each of the elements below must always be present in English as a minimum.

Many of these elements can be translated into multiple languages and should be added once for each supported language. See the [[List of language codes (ISO-639:1988)]] for possible language strings. If there's no <code>lang</code> attribute for a translatable element, it defaults to English. However, even for English, adding the <code>lang</code> attribute is recommended.

===== <summary> =====

One or more <code><summary></code> elements provide a short summary of what the add-on does. This should be a single sentence. It may be translated into multiple languages.

<source lang="xml">
<summary lang="en">Hello World script provides some basic examples on how to create your first script.</summary>
</source>

===== <description> =====

One or more <code><description></code> elements provide a more detailed summary of what the add-on does. It may be translated into multiple languages.

<source lang="xml">
<description lang="en">Hello World script provides some basic examples on how to create your first script
and hopefully will increase the number of XBMC users to start creating their own addons.</description>
</source>

===== <platform> =====

The <code><platform></code> tag specifies which platforms (operating systems, hardware) this add-on runs on. Many add-ons will run on all platforms, so <code>all</code> is an option. If the platform tag is missing, we assume the add-on runs on all platforms. A combination of these is also possible. Currently available options are:

* <code>all</code>
* <code>linux</code>
* <code>osx</code>
* <code>osx64</code>
* <code>osx32</code>
* <code>ios</code>
* <code>windx</code>
* <code>wingl</code>
* <code>android</code>

<source lang="xml">
<platform>all</platform>
</source>

===== <language> =====

The <code><language></code> elements indicate the language(s) of the ''content'' provided by your add-on. It applies to plugins, scripts, scrapers etc. This allows browsing the add-on list by language. When there is no specific language provided in your content, leave it blank.

<source lang="xml">
<language>en de fr</language>
or
<language></language>
</source>

===== <license> =====

The <code><license></code> element indicates what license is used for this add-on.

<source lang="xml">
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
</source>

===== <forum> =====

The <code><forum></code> element provides the forum thread URL for this specific add-on. Leave this blank if there is no forum thread.
<source lang="xml">
<forum>http://www.myaddonwebsite.com/forum.php?thread=12345</forum>
</source>

===== <website> =====

The <code><website></code> element provides the website URL for this specific add-on.

<source lang="xml">
<website>http://www.myaddonwebsite.com/</website>
</source>

===== <nowiki><source></nowiki> =====

The <code><nowiki><source></nowiki></code> element provides the URL for the source code for this specific add-on.
<syntaxhighlight lang="xml" enclose="div">
<source>http://github.com/someone/myaddon</source>
</syntaxhighlight>

===== <email> =====

The <code><email></code> element provides the email address of the author if he wishes to do so for this specific add-on. Here are two examples of how you can make it look (the second one it harder for spambots to use). This can be left blank if you do not want to make your email address public.
<source lang="xml">
<email>foo@bar.com</email>
or
<email>foo at bar dot com</email>
</source>

===== <disclaimer> =====

One or more <code><disclaimer></code> elements that indicate what (if any) things the user should know about the add-on. There is no need to have a disclaimer if you don't want one, though if something requires settings, or only works in a particular country then you may want to state this here. It may be translated into multiple languages.

<source lang="xml">
<disclaimer lang="en">Feel free to use this script. For information visit the wiki.</disclaimer>
</source>

===== <broken> =====

The <code><broken></code> tag will mark the add-on as broken in the XBMC repo and provide the reason why. You don't need to do a version bump for this to work. However a bump is recommended as you could also add this to the changelog.

<source lang="xml">
<broken>deprecated</broken>
</source>

== Skin specific elements ==
=== Overview ===
{| class="prettytable"
| '''defaultresolution'''
| Default resolution folder for this skin. This is the base directory that all window xml file requests will fall back to.
|-
| '''defaultresolutionwide'''
| Default widescreen resolution folder for this skin. This is the directory that all window xml file requests from widescreen resolutions (1080i, 720p, 480p 16x9, NTSC 16x9 and PAL 16x9) will fallback to. If the file isn't found in this window, then it'll fall back to the <defaultresolution> folder.
|-
| '''defaultthemename'''
| Default theme name. Currently set to: Default.
|-
| '''effectslowdown'''
| A multiplier that is applied to all <animation> effect lengths in the skin. Useful to slow down all animations globally so that you can better configure timings and see interactions between animating controls.
|-
| '''debugging'''
| When set to true, it'll display onscreen debug information (xml filename, mouse position and focused control type and name) in the skin.

|-
| '''res'''
| Support for arbitrary skin resolutions.
|}

=== How window xml files are found ===

XBMC can run in many differing resolutions, and a skin should try and cater to all these resolutions. The easiest way is to develop for one specific resolution and make sure that all controls contain <width> and <height> tags. That way, XBMC can scale the controls to the new screen resolution.

However, you may choose to develop alternative window xml files for differing resolutions (such as for HDTV resolutions, or for widescreen versus 4x3 resolutions).

The order that XBMC looks for it's skin files are as follows:

# It first looks in the current screenmode folder (one of 1080i, 720p, NTSC16x9, NTSC, PAL16x9 or PAL)
# If the current screenmode is 1080i, it then looks in the 720p folder.
# If the current screenmode is a widescreen mode (1080i, 720p, NTSC16x9, PAL16x9) then it looks in the <defaultresolutionwide> folder.
# Finally, it looks in the <defaultresolution> folder.

This allows you to just put any window files that do not require special treatment for 16x9 resolutions etc. in the <defaultresolution> folder, preventing needless repetition.

= Examples =

== addon.xml for skins ==

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8"?>
<addon
id="skin.confluence"
version="2.1.3"
name="Confluence"
provider-name="Jezz_X, Team XBMC">
<requires>
<import addon="xbmc.gui" version="4.0.0"/>
</requires>
<extension
point="xbmc.gui.skin"
defaultthemename="textures.xbt"
debugging="false"
effectslowdown="0.75">
<res width="1280" height="720" aspect="16:9" default="true" folder="720p" />
</extension>
<extension point="xbmc.addon.metadata">
<summary lang="en">Confluence skin by Jezz_X. (XBMC's default skin)</summary>
<description lang="en">Confluence is the default skin for XBMC 9.11 and above. It is a combination of concepts from many popular skins, and attempts to embrace and integrate their good ideas into a skin that should be easy for first time XBMC users to understand and use.</description>
<disclaimer lang="en">Confluence is the default skin for XBMC, removing it may cause issues</disclaimer>
<platform>all</platform>
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>
One thing to note is that all tag names are lower case. XML tag names are case sensitive!

== addon.xml for scripts/plugins ==

<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon
id="script.artwork.downloader"
name="Artwork Downloader"
version="12.0.12"
provider-name="Martijn">
<requires>
<import addon="xbmc.python" version="2.1.0"/>
<import addon="xbmc.json" version="6.0.0"/>
<import addon="xbmc.addon" version="12.0.0"/>
<import addon="script.module.elementtree" version="1.2.7"/>
<import addon="script.module.simplejson" version="2.0.10" optional="true"/>
<import addon="script.common.plugin.cache" version="1.3.0"/>
</requires>
<extension point="xbmc.python.script" library="default.py">
<provides>executable</provides>
</extension>
<extension point="xbmc.service" library="service.py" start="login"/>
<extension point="xbmc.addon.metadata">
<summary lang="en">Downloads Artwork for TV shows, Movies and Musicvideos in your library</summary>
<description lang="en">Downloads all available artwork for TV shows, Movies and Musicvideos in your library. Check the options for supported artwork[CR]Artwork sources:[CR]www.fanart.tv[CR]www.thetvdb.com[CR]www.themoviedb.org[CR]Remark:[CR]Check your skin to see what type of artwork is supported![CR]Each TV Show/Movie must have its own folder![CR]Skin integration:[CR]See readme file</description>
<disclaimer lang="en">For bugs, requests or general questions visit the Artwork Downloader thread on the XBMC forum.</disclaimer>
<language></language>
<platform>all</platform>
<license>GNU GENERAL PUBLIC LICENSE. Version 2, June 1991</license>
<forum></forum>
<website></website>
<email></email>
<source></source>
</extension>
</addon>
</syntaxhighlight>

= Schema Definition =

The XML schema definition for <code>addon.xml</code> is located [https://github.com/xbmc/xbmc/blob/master/addons/xbmc.addon/metadata.xsd here].

[[Category:Add-on development]]
[[Category:Skin development]]

Artwork/Cache

2014-03-15T09:25:25Z

Jmarshall: /* The future */

{{mininav|[[Development]]}}

{{cleanup}}

XBMC maintains a local texture cache for thumbs and fanart, to allow fast loading of these images so that skins can show off your media in the best way possible.

All textures that XBMC loads, with the exception of textures that are provided directly by the skin, are cached to the userdata/Thumbnails folder. 

== Art for library items ==
As of XBMC v12:

The art URL's associated with library items are stored in the art table inside the video or music databases. These store the original URL to the art (e.g. from http://themoviedb.org, http://thetvdb.com, or http://theaudiodb.org). This means that central databases store where the art is obtained from, and multiple clients then just keep a local thumbnail cache as described below.

== The caching procedure ==
The caching procedure utilizes both copies (possibly scaled down) of the original texture, saved in .jpg or .png format, an (optional) fast loading .dds version of those images, and an SQL database that maintains the local cache.

The cache operates primarily on an "as and when needed" basis. i.e. textures are cached when they're first requested to be loaded. In addition, however, in some places textures may be cached before they're immediately needed, such as in the scanning routines. In either case, the main caching procedure starts with an image URL. We cache as follows:

1. We generate a CRC (hash) of the URL. (see [[Thumbnails#Sample Code|Code Samples]] on how to calculate CRC values) 
2. We cache the image, reducing it in size if required, to a local file with the given CRC. It's cached as a PNG or JPG based on whether transparency is required. 
3. We generate a hash of the image, based on size and modified date, that we can use to check whether the original image has changed or not. 
4. We store these details, along with information on when the image was cached in the SQL database Textures.db.

== Loading textures ==

When loading a texture, XBMC basically just has a URL to the image. Given a particular URL, we load the texture as follows:

1. We first check to see whether the image is provided by the skin. If so, we load it directly. 
2. We then check to see whether the URL is from our thumbnail cache. If it is, we skip to step 5. 
3. If not, we look up to see whether this image is in our texture cache by querying the SQL database. If it is, we swap the URL to the cached version and skip to step 5. 
4. If it's not in the cache, we cache the image as outlined above. 
5. We then additionally check if a "fast loading" version (.dds) of the texture exists. If it does, we swap the URL to the fast loading version. 
6. We load the image. 
7. We (optionally) generate a "fast loading" version (.dds) of the texture, if it doesn't already exist. 
8. We update the texture database with access times to the texture (allowing us to clear the texture cache out of images that are rarely used). 
9. If it's been at least 24 hours since the texture was last loaded, we check whether or not the cached version needs to be refreshed from the original image. If so, we cache the image as outlined above.

== DDS artwork ==

XBMC uses the compressed format DXT1 or DXT5 in the form of a .dds file. These are GPU-friendly compressed formats which allow for very fast loading of textures. It comes at the disadvantage of a loss in quality - DXT compression can in some cases be very bad quality. XBMC uses libsquish which is reasonably optimal at compressing the images. In the future XBMC may use DXT5 in the YCoCg colour space which is the same size as DXT5 (i.e. 8bits/pixel) but is visually close to being lossless. For now, if XBMC deems the quality isn't quite good enough to use DXT1 or DXT5, we use ARGB (i.e. 32bits/pixel) which can result in some very large images on disk. On systems with slow disk access, these may take longer to load than .jpg or .png versions.

The generation of .dds versions of the artwork is automatic if you have set the <useddsfanart> advancedsetting. DDS versions are generated in step 7 above. Even if you haven't set the advanced setting, XBMC will still load .dds versions of the textures if they're available, so on slower systems you may wish to generate .dds versions offline and place them in the texture cache directly.

== The future ==

The texture cache in the future will be auto-cleaning, i.e. textures that are stale will automatically be cleaned out to save disk space. Also, the music and video artwork will be moved to the new system. This will allow the cached versions of these images to be updated whenever the original image changes (eg you replace the fanart with a different version).

In addition, the texture cache will be updated to automatically tell the image control that it needs to refresh itself. Currently if the texturecache detects that a new version of an image is available (whether it be a .dds version or an updated copy of the original image that has since changed) then all that happens is the new version gets re-cached. Thus, you only see the new version of an image once you view it a second time after any change (this allows the image to be free'd from memory and reloaded from the freshly updated version).

== How to refresh the cached image of an icon ==

There is an image like ''/home/x/.xbmc/addons/my.lovely.addon/icon.png'' . After changing that file, the old image is still visible in XBMC. To solve this we need to remove the actual thumbnail file from the filesystem and its reference in the DB:

# Get the thumbnail path to remove the file from the filesystem
$ sqlite3 .xbmc/userdata/Database/Textures6.db "SELECT cachedurl FROM texture WHERE url = '/home/x/.xbmc/addons/my.lovely.addon/icon.png';"
6/6a643bff.png

This ''6/6a643bff.png'' is the cached image under ''/home/x/.xbmc/userdata/Thumbnails''. So: you need to remove from your filesystem ''/home/x/.xbmc/userdata/Thumbnails/6/6a43bff.png"

# Remove the image->cached image link in the DB
$ sqlite3 .xbmc/userdata/Database/Textures6.db "DELETE FROM texture WHERE url = '/home/x/.xbmc/addons/my.lovely.addon/icon.png';"

Next time XBMC needs the image, it will recreate the thumbnail.

:{{highlight|'''Remarks:'''|bordered=yes|color=lime}} "Textures'''6'''.db" '''number/version''' Increases with newer XBMC versions.

[[Category:Thumbnails]]
[[Category:Development]]
[[Category:XBMC Manual]]

Artwork

2014-03-15T09:24:27Z

Jmarshall:

{{cleanup}}
An impressive feature of XBMC is its ability to display custom '''thumbnails''' (also known as an "icon") on most items displayed. You can assign thumbnails to folders, programs, music, videos, bookmarks, and of course pictures. You can choose to let XBMC automatically download thumbnails for music-albums and video/movies from the internet or you can create your very own custom thumbnails. You can also download custom thumbnails that others have created.

When talking about movies the terms "Cover Art", "Posters" (term used on [http://thetvdb.com/ TheTVDB]) and "Folder Image" are all used to refer to the '''same''' thing we are talking about here. In the XBMC world Thumbnail is the generic term that encompasses all of those things, so don't get confused.

{{Note|Despite what the term Thumbnail implies, thumbnails in XBMC are NOT necessarily small images in terms of resolution or size on disk. A Thumbnail in XBMC can be a 800 x 1200 pixel image with a file size of over 300 Kilobytes for example, but typically thumbnails are restricted to smaller sizes than that due to performance concerns.}} 

== Custom Thumbnails ==
You can easily create your very own user-defined thumbnails on your computer with image tools like Adobe Photoshop, Paint Shop Pro, Paint.NET or even Paint in Windows. You can alternatively download thumbnails that others have created on the internet.
Then you simply have to rename those thumbnails and transfer/copy them to the right location and XBMC will display them. Use JPG or PNG (with transparency) image-format, and size of the picture to anything from 128x128 to 256x256 in pixel size, (the larger the image is the better it will look on a good display but at the same time large thumbnails loads slower). On a non-HDTV displays a image that is approx 100x140 is recommended for video/movies thumbnails (which is the size that is most common on [http://www.imdb.com/ IMDb]), and approx 75x75 for music-albums (which is the default size on [http://www.allmusic.com allmusic.com]). For 720p/1080i HDTV displays a size of approx 182x256 for video/movies thumbnails, and approx 200x200 for music-albums (such music-albums can be found on [http://www.allmusic.com allmusic.com]).

==== Thumbnail Cache ====
:''see also:'' '''[[ThumbnailCache]]''' for a thorough description of the '''thumbnail cache''' 

XBMC will cache all thumbnails to [[userdata]]\Thumbnails\ using the '''CRC''' of the path of the file or folder as a filename. That is the first location XBMC will generally look for a thumbnail for a given item. 

In order for your custom thumbnail to show, you may have to delete the cached thumbnail.

When thumbnails are cached they may be scaled down from the source image. How much they are scaled down depends on a setting that you can control using the [[Advancedsettings.xml#.3Cthumbsize.3E|<imageres>]] tag in [[advancedsettings.xml]].

If you are running XBMC on a very high resolution display and you have Movie cover art, for example, that is displayed as a very large image onscreen with the skin and layout that you are using, then you may want to adjust the <imageres> tag to increase the display quality of your thumbnails.

Be aware, however, that increasing the size of cached thumbnails obviously carries an implied disk space usage, and possible XBMC performance penalty, with it.

== Wide banner icons ==
{|
[[File:Wideview_tvshows.png|500px|right|Wide view for TV shows|thumb]]
Some of the most visually appealing forms of thumbnails are [[wide banner icons]]. They are an integral part of the XBMC look and feel and are used for the TV shows [[Video library|library]]. 
With different adjustments to the [[XBMC Skinning Manual|skin]] [[w:XML|XML]] files, you may disable title names or stack one icon on top of another. 
To show wide banner icons switch to Wide or 'Media info 2' view. XBMC will remember what view you have for each folder. Thus you can keep your TV shows in Wide and your Movies in [[FanArt|Fanart]].
:* [[Wide banner icons#Sources for wide banner icons|Sources for wide banner icons]]
|}
{{-}}

== Thumbnails for individual items in a single directory ==
Name the icon file the same as the file you would like it to display for with a -poster.jpg or -poster.png extension ie: ''Transformers.avi, Transformers-poster.jpg''. This is particularly useful for using custom thumbnails for movies.

'''Example:'''
Movies\path\'''moviename.avi'''
Movies\path\'''moviename-poster.(jpg/png)'''
Movies\path\'''moviename.jpg'''

== Folder Thumbnails ==
{|
| valign="top" |
If you store each of your media files in separate subfolders to keep things organized, you can also make the folder have a custom thumbnail image. To do this you either need to save your JPG/PNG thumbnail as folder.jpg and place it inside your movie/album folder, or you can save it as <foldername>deprecated and place it at the same level as the folder in the directory tree.
* Remember, XBMC first checks for <foldername>.jpg before checking for folder.jpg.
* Some documentation suggests that folder.jpg can be used. In general folder.jpg is superior as it is detected during a scan, i.e. XBMC will correctly use folder.jpg but not folder.jpg.
* Note that folder.jpg '''must''' be named .jpg, even if it is a .png format image.

 
'''Examples:'''
Movies\path\'''foldername'''\
Movies\path\'''foldername.jpg'''
or
Movies\path\moviename\'''folder.jpg'''
Music\path\album\'''folder.jpg'''

Now your media folder will have a lovely custom thumbnail-image.

You can via [[advancedsettings.xml]] change the default filename of the image that XBMC uses for music folders. See the [[advancedsettings.xml#<musicthumbs>|<musicthumbs>]] tag. for more information.
|
[[File:Files.myvideos.jpg|right|500px]]
|}

== Program Thumbnails ==
In order to display the image displayed for a game, emulator or application, simply rename the desired image '''default.jpg''' and place it in the folder where the corresponding default.XBE is located.

== Music Thumbnails ==
Music Thumbnails are assigned as part of a multi-tier process. First, the Tag Reader runs and caches any embedded art using the album name and album artist (or song artist, if that is all that is available). If the album name or artist is unavailable, it is cached using the path name of the song. This assumes, of course, that you have tag reading enabled. 
You can also use "Get Thumb" to download the album thumbnail from [http://www.allmusic.com allmusic.com (AMG)] for a specific album/folder or do a scan of all your music files in all shares. 
Thumbnails also get downloaded when you rip AudioCD's to your XBMC device (which is described in the [[Ripping CDs]] section). 
Recommended is that you store each of your music-albums or artists in a separate subfolder to keep things organized. You can also of course make the folder have a custom thumbnail image. 
 
{|
|
[[File:mymusic.jpg|right|500px]]
| valign="top" |
:{{Note|Running a scan automatically enables 'tag reading' so everything can be cached. Once a scan is run, all your files and their associated thumbnails are stored in the database.}}
:The Album Information dialog (available from the context menu) will allow you to choose between the cover art available for download from [http://www.allmusic.com allmusic.com] and any user-defined thumbnail you may have.
:Press the "Get Thumb" button to bring up a choice of the local thumbnails you have, the currently assigned thumbnail and the [http://www.allmusic.com allmusic.com] thumbnail. 
|}
'''The code which assigns thumbnails to files runs and assigns thumbnails in the following order:'''

;1) Cached Album Thumbnail
:This is all the embedded album art read by the tag reader and cached using the album name and album artist.
;2) Cached filename.jpg
:This includes an embedded thumbnail cached with the fully qualified name.
;3) Remote filename.jpg
:This is a filename.jpg on a remote share/folder which is then cached.
;4) Cached folder.jpg
:This is a folder.jpg which is cached based off the folder path.
;5) Remote folder.jpg
:This is a folder.jpg on a remote share/folder which is then cached.
;6) Remote foldername.jpg
:This is a foldername.jpg on a remote share/folder which is then cached. 

'''Examples:'''

In this example audiofilename.mp3 will use audiofilename.jpg as thumbnail:
Music\path\'''audiofilename.mp3'''
Music\path\'''audiofilename.jpg'''

The same goes for playlists, cue-sheets, SHOUTcast, and [[HOW-TO: Play Internet Streams|internet-stream files]], example:
Music\path\'''audioplaylistname.m3u'''
Music\path\'''audioplaylistname.jpg'''
Music\path\'''cuelistname.cue'''
Music\path\'''cuelistname.mp3'''
Music\path\'''cuelistname.jpg'''
Music\path\'''shoutcastlinkname.pls'''
Music\path\'''shoutcastlinkname.jpg'''
Music\path\'''audiostreamname.strm'''
Music\path\'''audiostreamname.jpg'''

::Music fanart
{{see also|FanArt#Music_FanArt_in_XBMC}}

== Video Thumbnails ==
You can either use your own custom thumbnails or XBMC can retrieve video thumbnails from the internet via [[How To use Scrapers|scrapers]] and cache them locally. 
'''XBMC applies thumbnails to video files in the following order:'''
{|
| valign="top" |
;1) Cached Thumbnail
Thumbnails are cached to UserData\Thumbnails\Video using the CRC of the path of the file or folder.
 
;2) User-Defined Thumbnail 
'''For files:'''

XBMC looks for '''<filename>-poster.(jpg/png)''' in the folder containing the media files and uses that as the thumbnail.
Note: <filename>.jpg will supersede '''<filename>-poster.(jpg/png)''' (result of Eden backward compatibility)

The thumbnail is cached the first time it is read. 

{{redv|Deprecated:|If movie.jpg is in the same folder it will override any other thumbnail and will be used as the thumbnail for all movie files in that folder.}}

'''For folders:'''

XBMC checks inside the movie folder for the following files in this order: 
*'''<filename>-poster.(jpg/png)'''
*'''poster.(jpg/png)'''
*'''folder.jpg'''
{{redv|Deprecated:|XBMC first checks for <foldername>.jpg in the parent folder of the movie folder being processed.

If no <foldername>.jpg exists in the parent folder XBMC then checks inside the movie folder for folder.jpg (by default) or any other thumbnail source file names you've specified in the <dvdthumbs> tag in [[AdvancedSettings.xml]].}}

'''For TV series specifically:'''

{{redv|Deprecated:|The thumbnail image can be either a Poster type image OR a Banner type image. A Poster is longer than it is wide in aspect and a Banner is much wider than it is long in aspect.

The same rules apply regarding file naming conventions and by default XBMC will look for folder.jpg for BOTH Posters AND Banners despite the fact that the naming convention might seem
counter intuitive in the case of Banners.

Note: Deprecated as of Frodo <dvdthumbs> is no longer part of advancedsettings.xml - Again, you can use the <dvdthumbs> element in advancedsettings.xml to override the default thumbnail file name that XBMC looks for to make things more meaningful for TV series. If, for example, you
prefer to use Banners you would probably want to set the <dvdthumbs> element in advancedsettings.xml to remove folder.jpg from the search filter and add banner.jpg to the search filter as follows:

<dvdthumbs>
<remove>folder.jpg|Folder.jpg|folder.JPG|Folder.JPG</remove>
<add>banner.jpg|Banner.jpg|banner.JPG|Banner.JPG|cover.jpg|Cover.jpg|cover.JPG|Cover.JPG</add>
</dvdthumbs>

The above example will make XBMC ignore all variants of folder.jpg when searching for thumbnails but recognise multiple variants of banner.jpg and cover.jpg and import those instead.
}}
{{note|<code>TV series:</code>}}

There is a special case with TV Series where, if you choose to use Banners as your primary thumbnails, you also need Posters in some areas of the UI depending on which skin you are using.

The Aeon Nox skin, which is extremely popular, has a very nice View mode called BannerPlex for example. If you are using that View as your TV Series View, your primary thumbnails for your TV series will
be Banners BUT there are still places where you need to supply a Poster, like the "TV show information" screen that is accessible from the context menu for a Series. In that screen you need a Poster image for the big area on the left that takes up a third of the screen. By default the Banner thumbnail that XBMC imported will be stretched vertically to fill that area and it looks horrible.

As of Frodo, XBMC will import Banners and Posters.

{{redv|Deprecated:|Fortunately there is a special exception to this rule for TV Series where XBMC will also recognise and import a file called poster.jpg over and above the default thumbnail image.

For this reason you should NEVER name your primary thumbnail images poster.jpg and you should NEVER modify the <dvdthumbs> element in advancedsettings.xml to make it search for variants of poster.jpg.

Effectively, you should consider the file name poster.jpg to be a reserved file name in XBMC that is used specifically to solve the Banner / Poster combo issue as described further below.}}

Certain skins, like Aeon Nox, typically provide an option in the settings for the View itself that allows you to explicitly stipulate that a poster file should be used for those areas where a Poster type image is applicable.

In Aeon Nox, the setting is on the slide out menu on the left of the screen when you are viewing your series. If you have the BannerPlex view activated and you slide out that menu, then go to
"Viewtype settings", then look under "GENERAL OPTIONS", you will find an option labelled "Use 'poster.jpg' for poster style viewtypes". If you turn that on, then any poster.jpg that you have in your folders
when you import your media from disk will be used where a poster type image is appropriate.

{{note|However, that regardless of any settings, poster.jpg will NOT be used as the All Seasons image. For that you MUST provide a season-all.(jpg/png) file. A quick workaround to this problem is to copy an existing poster.jpg file and rename it to season-all.(jpg/png). That will actually work and import fine.}}

|
[[File:Files.videos.thumbnails.WSCR.jpg|right|500px]]
|}

==== Examples for User-Defined Video Thumbnails ====
;Single Video File
The following example "videofilename.avi" will now use the thumbnail "videofilename-poster.(jpg/png)".
Movies\path\'''videofilename-poster.(jpg/png)'''
Movies\path\'''videofilename.avi'''
Note that '''videofilename.jpg''' is old Eden terminology, but WILL supersede '''videofilename-poster.(jpg/png)''' which is the standard for Frodo and later versions of XBMC.

;Multi Part (Stacked) Video Files
This may not be Frodo terminology, but '''''should''''' still work
You can either use the filename of the first file in the stack or the name of the stack, so for:
Movies\path\'''moviename-CD1.avi'''
Movies\path\'''moviename-CD2.avi'''
Either of the below would work:
Movies\path\'''moviename-CD1.jpg'''
Movies\path\'''moviename.jpg'''

;Movies in Folders
{{redv|Deprecated:|If [[Set Content (Video Library)|content]] has been set to Movies, movie.jpg will override any other thumbs for media in that folder.}} 
In the following example "videofilename.avi" will now use the thumbnail "poster.(jpg/png)".

Movies\path\'''poster.(jpg/png)'''
Movies\path\'''videofilename.avi'''
Note that movie.jpg will supersede '''poster.jpg''' due to Eden backward compatibility

;TV Shows
TV\showfolder\'''poster.(jpg/png)'''
or
TV\showfolder\'''banner.jpg'''
{{redv|Deprecated:|See [[http://wiki.xbmc.org/index.php?title=Userdata/advancedsettings.xml#.3Cdvdthumbs.3E <dvdthumbs>]] in [[http://wiki.xbmc.org/index.php?title=Userdata/advancedsettings.xml advancedsettings.xml]] }}

;TV Show Season Thumbnails
As of Frodo, XBMC can use either posters OR banners as the Season thumbnail. In the following example, the thumbnail will be used for the appropriate season in the [[Video Library]] season node. Where xx is 01, 02 etc.
TV\showfolder\'''seasonxx-poster.(jpg/png)'''
or
TV\showfolder\'''seasonxx-banner.(jpg/png)'''

;TV Show Specials
TV\showfolder\'''season-specials-poster.(jpg/png)'''
or
TV\showfolder\'''season-specials-banner.(jpg/png)'''

;For the all seasons item:
TV\showfolder\'''season-all-poster.(jpg/png)'''
or
TV\showfolder\'''season-all-banner.(jpg/png)'''

;Fanart
Movies in Folders:
Movies\path\'''fanart.(jpg/png)'''
TV Series:
TV\showfolder\'''fanart.(jpg/png)'''
TV Season:
TV\showfolder\'''seasonxx-fanart.(jpg/png)'''
TV Season All:
TV\showfolder\'''season-all-fanart.(jpg/png)'''
TV Specials:
TV\showfolder\'''season-specials-fanart.(jpg/png)'''

;[[Extra fanart|Extra Fanart Page]]

Movies\path\'''extrafanart\fanart1.jpg'''
Movies\path\VIDEO_TS\'''extrafanart\fanart1.jpg''' *Special case if using DVD Video structure
TV\showfolder\'''extrafanart\fanart1.jpg'''

The concept of extra fanart exists in XBMC for some skins whereby you can have more than one fanart image for a movie or TV show.
If you have more than one fanart image any fanart image after the main one (fanart.jpg) must be named using sequential numbering.

e.g. fanart1.jpg, fanart2.jpg and so on.

Extra fanart must be put into a sub-folder of the movie or TV show folder called '''extrafanart'''.

For those skins that support extra fanart you must turn on the "Enable Extrafanart" option and then you will see the different fanart images display as a repeating slideshow with a 10 second delay between each image.

;Playlist and [[HOW-TO: Play Internet Streams|internet-stream file]] examples
Playlists\path\'''videoplaylistname.pls'''
Playlists\path\'''videoplaylistname.jpg'''
Streams\path\'''videostreamname.strm'''
Streams\path\'''videostreamname.jpg'''

;Actor thumbnails
You can add actor thumbnails to any movie or TV show by adding an '.actors' folder in the corresponding movie / TV show / Episode directory. You may need to use the command line to create this directory in Windows. 
The folder can then contain actor images using the following naming convention: 
Videos\path\.actors\'''actor_name.jpg''' (spaces replaced with underscores)
Movies\Movie1\.actors\'''actor_name.jpg''' (spaces replaced with underscores)
Movies\Movie1\VIDEO_TS\.actors\'''actor_name.jpg''' (spaces replaced with underscores) *Special case if using DVD Video structure
TV Shows\TV Show 1\.actors\'''actor_name.jpg''' (spaces replaced with underscores)

== Picture Thumbnails ==
'''XBMC applies thumbnails to picture files in the following order:'''

;1) Cached Thumbnail
:Thumbnails are cached to UserData\Thumbnails\Pictures using the CRC of the path of the file or folder.

;2) Images
:EXIF thumbnail in JPEG images are then read. If no EXIF thumbnail is available, XBMC will load the image and generate a thumbnail from the image. These are then cached.

;3) Folders
:<MyHolidayPictures>\folder.jpg is checked first. If that file doesn't exist, XBMC will generate a thumbnail from up to 4 random images inside that folder.

== Thumbnails for Sources ==
You can change the thumbnail displayed for a source by editing '''UserData\sources.xml'''. 
{{note|Source thumbnails have to be in a folder on the local XBMC device harddrive!}}
;Simply modify your source as shown:
<pre><nowiki>
<source>
<name>Music</name>
<path>xbms://192.168.1.100:1400/Music/</path>
<thumbnail>F:\Apps\XBMC\thumbs\shares\thumb.png</thumbnail>
</source>
</nowiki></pre>

== Auto switch to icon Mode ==
XBMC tries to automatically switch to ''Large Icon'' [[General Navigation#View|view]] when the ''View Mode'' is set to ''Auto'' in the [[Settings]]. It first checks if the skin has ''Large Icon'' view, failing that switches to ''Icon'' view. If neither is available it goes for ''List View''. 
'''The rules are as follows:'''

==== [[Programs Settings#Files|Programs]] ====
Auto switches to Icon view when 50% of all the items (files and folder) have thumbs.

==== [[Pictures Settings#General|Pictures]] ====
Auto switches to Thumbs view when the list contains more than 25% files. (In the case of Pictures, all items have thumbs as they are generated upon entering the folder.)

==== [[Videos Settings#General|Videos]] ====
Auto switches to Thumb view when 50% of all the items (files and folder) have thumbs.

==== [[Music Settings#Files|Music]] ====
Auto switches to Thumb view when the list contains at least 75% folders and at least 50% of them have thumbs. (Remember that playlist files like m3u, pls, etc, are treated as folders by default)

[[Category:Thumbnails]]
[[Category:Scraper]]
[[Category:Video Library]]
[[Category:Music Library]]
[[Category:XBMC Manual]]
{{frodo updated}}

Archive:Team Kodi/Members

2013-10-16T21:30:25Z

Jmarshall:

{{mininav|[[Team XBMC]]}}
{{notice|'''PLEASE DON'T E-MAIL OR PM ANYONE DIRECTLY ABOUT SUPPORT! INSTEAD USE THE [[XBMC:Community Portal|COMMUNITY FORUM]] OR [[XBMC:Community Portal|IRC-CHANNELS]]!'''}}

<section begin=intro />Team XBMC is the formal group of people who develop and maintain [[XBMC]], the [http://xbmc.org XBMC websites], and/or other supporting roles.<section end=intro />

'''''This list is likely incomplete, so give us a nudge if we forgot you'''''
{{TOCright}}
=Active members=

==XBMC Foundation Voting Board Members and Non-Voting Officers==
{{Main|XBMC Foundation}}
{{#lst:XBMC Foundation|intro}}
{{#lst:XBMC Foundation|Foundation members}}

==Project Managers==
*[[User:Pike|Pike]] - The Bossman
*[[User:theuni|theuni]] - Business Relation Manager
*[[User:Natethomas|Natethomas]] - Community Manager
*[[User:Martijn|Martijn]] - GitHub Project Manager

==Liason==
*[[User:theuni|theuni]] - All Around PR Stunts

==Developers (General)==
*abelier - video decoding
*[[User:alanwww1|alanwww1]] - Translations, Intel related stuff
*[[User:Alcoheca|Alcoheca]]
*[[User:AlTheKiller|AlTheKiller]] - Fixer of broken things, build system
*[[User:amet|amet]]
*[[User:Anssi|Anssi]]
*[[User:Arnova|Arnova]] - Curl/webdav filesystem(s), general bug fixes
*[[User:bobo1on1|bobo1on1]] - Video Playback, General Bugfixes
*[[User:Chadoe|Chadoe]] - last.fm, general bug fixes
*[[User:opdenkamp|opdenkamp]] - PVR, EPG
*[[User:dteirney|dteirney]] - MythTV Integration
*[[User:elupus|elupus]] - XBMC video player (DVDPlayer) god
*[[User:firnsy|firnsy]] - Database
*[[User:Fneufneu|Fneufneu]] - BSD Developer
*[[User:freezy|freezy]] - Android Remote Developer
*[[User:garbear|garbear]]
*[[User:gnif|gnif]] - Audio, Audio Engine
*[[User:jfcarroll|jfcarroll]] - swig integration, binary addon developer
*[[User:Jmarshall|Jmarshall]] - Jedi-Master
*JoeTheFox - iPhone Remote Developer
*[[User:Malard|Malard]] - Web
*[[User:Memphiz|Memphiz]] - vfs, zeroconf, AirPlay and general stuff
*[[User:Montellese|Montellese]] - JSONRPC
*night199uk - Music library
*[[User:olympia|olympia]] - scraper developer/repo maintainer
*[[User:phi2039|phi2039]] - Audio, Assembly, and anything that sounds like it might be challenging...
*[[User:pieh|pieh]] - General code tinkering
*[[User:taxigps|taxigps]]
*[[User:Topfs2|Topfs2]] - JSONRPC, ARM, power, storage, dbus
*[[User:the_alien|the_alien]] - Android Remote Developer
*[[User:VDRfan|VDRfan]] - General
*[[User:Herrnst|Herrnst]] - LCD display coding
*[[User:Voyager|Voyager]] - hunting bugs in library, dvdplayer etc.
*[[User:ulion|ulion]]

==Developers (Linux)==
*[[User:AlTheKiller|AlTheKiller]]
*[[User:Amejia|Amejia]] - Debian, etc.
*[[User:Anssi|Anssi]]
*[[User:Arnova|Arnova]]
*[[User:bobo1on1|bobo1on1]]
*[[User:davilla|davilla]]
*[[User:opdenkamp|opdenkamp]]
*[[User:Erhnam|Erhnam]] - XBMCFreak creater, Live Distro developer
*[[User:firnsy|firnsy]]
*[[User:l.capriotti|l.capriotti]] - LiveUSB Distro
*[[User:malloc|malloc]]
*[[User:monkeyman 67156|monkeyman 67156]]
*[[User:Phaeodaria|Phaeodaria]]
*[[User:sraue|sraue]] - OpenELEC.tv Developer
*[[User:Topfs2|Topfs2]]
*[[User:VDRfan|VDRfan]]
*[[User:FernetMenta|FernetMenta]] linux, video, windowing, pvr etc developer
*[[User:wsnipex|wsnipex]] Linux PPA
*[[User:fritsch|fritsch]] Linux, XVBA, grAEken, helping with Hammer, User Support, OpenELEC

==Developers (Mac and iOS)==
*[[User:Beenje|Beenje]] - PowerPC (PPC) specialist
*[[User:davilla|davilla]]
*[[User:gimli|gimli]]
*[[User:Jmarshall|Jmarshall]]
*[[User:Memphiz|Memphiz]] - dark side padawan
*[[User:ulion|ulion]]

==Developers (Windows)==
*[[User:a11599|a11599]] - primarily windows video and dxva
*[[User:blinkseb|blinkseb]]
*[[User:bobo1on1|bobo1on1]]
*[[User:Chadoe|Chadoe]]
*[[User:CrystalP|CrystalP]]
*[[User:jhsrennie|jhsrennie]]
*[[User:Jmarshall|Jmarshall]]
*[[User:tiben20|tiben20]] - butcher by day, coder by night
*[[User:WiSo|WiSo (aka wsoltys)]]
*[[User:DDDamian|DDDamian]]
*[[User:DanielaE|DanielaE]]
*[[User:Voyager|Voyager]] - general Windows, hunting bugs in library, dvdplayer etc.
*[[User:Koying|Koying]] Windows, Android, mysql

==Developers (ARM)==
*[[User:davilla|davilla]]
*[[User:McGeagh|McGeagh]]
*[[User:Phaeodaria|Phaeodaria]]
*[[User:Topfs2|Topfs2]]

==Skinners / Graphic-artists==
*da-anda - graphics
*[[User:freezy|freezy]]
*[[User:Jezz_X|Jezz_X]] - Team skinner & Project Manager of the [http://sourceforge.net/projects/xboxmediacenter XBMC Skinning Project]
*[[User:ronie|ronie]]
*[[User:tree_jammer|tree_jammer]] - graphics

==Addon Developers==
*[[User:Clumsy|Clumsy]]
*[[User:opdenkamp|opdenkamp]] - PVR, EPG
*[[User:Jmarshall|Jmarshall]] - on an as-needed basis
*[[User:Martijn|Martijn]] - python addons

==Q/A Testers==
*[[User:keith|keith]] - QA for iOS and OSX projects
*[[User:kricker|kricker]]
*[[User:alanwww1|alanwww1]] - QA for Intel HW, VAAPI
*[[User:Gabbott|Gabbott]]

==Website services==
*[[User:Clumsy|Clumsy]] - Forum Moderator
*da-anda - Forum administration
*[[User:DonJ|DonJ]] - Server and Mirror Contact
*[[User:joebrady|joebrady]] - Forum Moderator
*[[User:Gamester17|Gamester17]] - Moderates a little bit of everything
*[[User:Ned Scott|Ned Scott]] - Wiki and forum Moderator
*[[User:Prae5|Prae5]] - Forum Moderator
*[[User:Sho|Sho]] - WIKI Structure Guru
*[[User:Zag|Zag]] - Add-on Frontend, Website, General Community Stuff

==Google Summer of Code 2012==
:''See also: http://www.google-melange.com/gsoc/org/google/gsoc2012/xbmc ''
*Alasdair Campbell (Alcoheca) - Improved UPnP serving and client
**Joakim Plate (elupus) - Mentor
*Andres Mejia (amejia) - XBMC Test Suite
**Bob van Loosen (bobo1on1) - Mentor
*Montellese - Advanced Library Filtering in XBMC
**Jonathan Marshall (jmarshall) - Mentor
*topfs2 - Clean scraping API
**spiff - Mentor
*Nathan Betzen (natethomas) - GSoC admin

=Inactive members=

==Project Founders (All Retired)==
*[[User:Frodo|Frodo]] - now [http://www.team-mediaportal.com MediaPortal] head programmer/founder
*[[User:RUNTiME|RUNTiME]] - now [http://www.runtime360.com runtime360.com] & [http://www.runtime360.com/projects/transcode-360/ Transcode 360]
*[[User:d7o3g4q|d7o3g4q (a.k.a. Duo Egaq)]] M.I.A. (Missing In Action)

==Developers (Currently Inactive or Retired)==
*[[User:MaestroDD|MaestroDD]] - Mac OS X, and Apple TV
*[[User:wattazoum|wattazoum]] - XBMC for Linux packaging specialist
*[[User:AreaScout|AreaScout]]
*[[User:oldnemesis|oldnemesis]]
*[[User:motd2k|motd2k]]
*[[User:Rudd|Rudd]]
*[[User:Alwinus|Alwinus]] - XBMC PVR Frontend Programmer
*[[User:Kraqh3d|Kraqh3d]]
*[[User:C-Quel|C-Quel]]
*[[User:Agathorn|Agathorn]]
*[[User:Tut-ankh-amon|tut-ankh-amon]]
*[[User:nad|nad]] - [[WebServerHTTP-API|XBMC HTTP API Mastermind]]
*[[User:MrC|MrC]] - XBMC Visualisation/Screensaver Mastermind
*[[User:c0diq|c0diq]] - UPnP (Universial Plug And Play) Mastermind
*[[User:Yuvalt|Yuvalt]] - XBMC Linux port specialist
*[[User:Vulkanr|Vulkanr]] - XBMC Linux and Mac port specialist
*[[User:D4rk|D4rk]] - XBMC Linux and Mac port specialist
*[[User:Bobbin007|Bobbin007]]
*[[User:Tslayer|Tslayer]]
*[[User:GeminiServer|GeminiServer]] - Low-level Hardware Guru
*[[User:Darkie|Darkie]]
*[[User:Forza|Forza]] - M.I.A. (Missing In Action)
*[[User:Butcher|Butcher]]
*[[User:Ysbox|Ysbox]]
*[[User:Guybrush|Guybrush]] - M.I.A. (Missing In Action)
*[[User:Kreet|Kreet]] - M.I.A. (Missing In Action)
*[[User:monkeyhappy|monkeyhappy]] - M.I.A. (Missing In Action)
*[[User:elan|elan (a.k.a. leafmuncher)]] - XBMC for Mac port specialist
*[[User:LiquidIce629|LiquidIce629]] - [[The Web Interface|XBMC Web GUI control-interface]] ([http://www.cliqklabs.com/xbmcwebgui/ Website])
*[[User:Spiff|Spiff]]

==Skinners / Graphic-artists (Retired)==
*[[User:CHI3f|CHI3f]] - XML Guru and all round Good Guy
*[[User:SmokeHead|SmokeHead]] - Photoshop Guru (Missing In Action)
*[[User:Chokemaniac|ChokeManiac]] - Project Mayhem

==Python Scripters (Retired/Inactive)==
*[[User:Voinage|Voinage]] - Python Plugin coder
*[[User:rwparris2|rwparris2]] - Python Plugin coder
*[[User:Nuka1195|Nuka1195]] - Python Script coder

==Web Services (Retired/Inactive)==
*[[User:Granqvist|Granqvist]] - Web Developer
*[[User:blittan|blittan]] - Web and Python Developer

==Testers (Retired/Inactive)==
*[[User:DDay|DDay]] - [http://forums.xbox-scene.com/index.php?showforum=180 Xbox-Scene.com Forum Mod God]
*[[User:TeknoJuce|TeknoJuce]] CrAzY Canuck
*[[User:Modhack|Modhack]] - French Guru [http://manuel.xboxmediacenter.fr .fr manuel]
*[[User:Donno|Donno]] - 1337 d00d
*[[User:SandmanCL|SandmanCL]] - Quality Assurance
*[[User:ShortySco|ShortySco]] - Quality Assurance
*[[User:Scape|sCAPe]] - Beta-Tester

==#XBMC (FreeNode) IRC Support==
*[[User:Bizzeh|Bizzeh]] - Mr. Hater ("I want to be in all sections") ([http://www.bizzeh.com Blog])
*[[User:Cocoliso|Cocoliso]] - Spanish
*[[User:DOS4GW|DOS4GW]] - Multi-lingual
*[[User:Jedi79|Jedi79]]
*[[User:MattAAron|MattAAron]]
*[[User:No1CaNTeL|No1CaNTeL]]
*[[User:xLoial|xLoial]] - Seasoned newbie

==Forum and Online Manual (WIKI) Moderators (Retired/Inactive)==
*[[User:Dankula|Dankula]] - WIKI Editor
*[[User:Loto_Bak|Loto_Bak]] - Al'round support man
*[[User:nimbles|nimbles]]
*[[User:No_Good|No Good]]

[[Category:Team-XBMC]]
[[Category:Team XBMC specific notes]]

Archive:Google Summer of Code/2012

2013-10-16T21:28:35Z

Jmarshall:

{{mininav|[[Development]]|[[:Category:Google Summer of Code]]}}

{{outdated|This page describes last years event. For the 2013 Google Summer of Code please go here: [[Google Summer of Code 2013]]}}

{{Top icon|raw={{PlusOne}} }}
Welcome to the XBMC [http://www.google-melange.com/gsoc/homepage/google/gsoc2012 Google Summer of Code] ideas page. We are pleased to announce that we have been accepted as an official [http://www.google-melange.com/gsoc/org/google/gsoc2012/xbmc GSOC mentor organization this year].

We encourage interested students to review some of the ideas on this page, and then feel free to provide input on any ideas you may have in the [[#Students Project Proposal Ideas|Student Project Proposal area]]. Alternatively, feel free to jump into the '''[[forumtopic:161|XBMC GSoC subforum]]''' and chat about any project you’d love to cover.

From March 26th to April 6th, any interested students may apply at the [http://www.google-melange.com/gsoc/homepage/google/gsoc2012 GSOC home page] to work with XBMC. After that, we’ll notify applicants whether we get to work with each other according to the [http://www.google-melange.com/gsoc/events/google/gsoc2012 GSOC schedule].
{| width="100%"
| align=left |
__TOC__
| align=right |
{{youtube|wju0RodoETI}}
|}
== About Us ==
As there may be many students who have landed here as a result of GSOC, but are unfamiliar with the project, here are a few resources that may help explain what we are about.

:XBMC is an award-winning free and open source (GPL) software media player and entertainment hub for digital media. Created in 2003 by a group of like minded programmers, XBMC is a non-profit project run and developed by volunteers located around the world. More than 50 software developers have contributed to XBMC, and 100-plus translators have worked to expand its reach, making it available in more than 30 languages.

 
To get an idea of what XBMC is truly capable of, it really must be seen. Check out a few other user-created videos: 
[http://www.youtube.com/watch?v=NcogPuSo-DU XBMC with the default Confluence skin] 
[http://www.youtube.com/watch?v=4asUCtE0ONU XBMC with Aeon Nox skin] 
[http://www.youtube.com/watch?v=4NR57ELY28s XBMC on Raspberry Pi] 
 

XBMC is written primarily in c++ and runs on a variety of platforms including Windows, Linux, OSX, and iOS. It has been ported to work on several low-power platforms including the BeagleBoard, PandaBoard, AppleTv, AppleTV2, and most recently, the [http://www.raspberrypi.org/archives/571 Raspberry Pi].

XBMC was a mentoring organization in [[Google Summer of Code 2008|2008]], and had team members involved in GSoC for other projects in 2011.

If XBMC is selected as a mentoring organization for 2012, students will need to review the Overview of a good project proposal, follow the outline for proposals when applying, and review the list of project ideas detailed below. Students are welcome to propose ideas outside the list and are encouraged to be as creative as they like.

=== Mentors ===
This years main mentors are Jonathan Marshall (jmarshall) and spiff, who have both been mentors in previous GSoCs. Backup mentors are Joakim Plate (elupus) and Bob van Loosen (bobo1on1). The GSoC admin is Nathan Betzen (natethomas). Other team members have also volunteered to be available to assist where possible with code and design review.

All mentors and backup mentors are extremely experienced in the XBMC codebase and will thus be able to assist students in getting to know the codebase and in quickly identifying projects that are both achievable for someone unfamiliar with the internal workings of XBMC and desirable to the wider XBMC community.

== Project Proposals ==
=== Overview ===
Qualifications for a good Summer of Code proposal:
* Discrete, well-defined, modular
* Comprised of a series of measurable sub-goals
* Based on open specs that are available free of charge
* Based on complete specs
An example of a good proposal is the implementation of a new feature or function that is not yet available in XBMC.

An example of a less desirable proposal is one that's not as measurable, such as refactoring an existing API. Bad proposals tend to be ones that would require touching a lot of core code.

To re-iterate:
* Localized/isolated code projects = ''good''
* Global code refactoring = ''bad''
* A project should have a set of subgoals, so even if the end goal turns out to be too big some of the parts will be of benefit.
* Not too big! This is an important problem when choosing a project, while it is fun to think about solving a grand project its not always realistic. Its better to finish a smaller project than to start a grand one.

=== Outline for proposals ===
==== Some project title ====
* ''Summary'': A somewhat small but explanatory walk through of the project. It should not be overly detailed just enough to understand the problem trying to be fixed and how this project opt to solve it.
* ''How will I achieve this'': Explain how the project will be done, what technologies are needed and how to implement them.
* ''What will the project focus on'': Explain what the project will focus on, what is the important parts of the project.
* ''Benefits'': Who will benefit and why from this project. Think about what a user or developer may need or do to benefit from it. Why does it benefit many users.
* ''Goals'': What is the goal of the project, a project may not always solve the problem entirely as it may take to much time. Think hard about what can be accomplished during a summer with your skill and deduct that quite a bit. If the project can't be done after this perhaps its better to opt for a smaller one or one with subgoals.
* ''What does it touch in XBMC'': Think about what parts of the code this may touch, XBMC is a big application and a lot of the code is spread out and very complex. If a project touches to much it may be impossible to complete.
* ''Requirements'': What is needed to complete the project, what code language knowledge what hardware etc.
* ''Possible mentors'': Place to add possible mentors (Team-XBMC will add this).

== Team-XBMC proposal ideas up for discussion ==

=== Focus on client/server model ===
For this year's GSoC, XBMC will be focusing on projects related to making XBMC easier to use in environments where multiple XBMC clients need to interact. With XBMC running on tablets and new embedded devices (iOS, rPi, with other OSes in the works) more and more folk are accessing both local and remote media from multiple machines. It makes sense, therefore to keep information about what content is available and what has been watched in sync across multiple clients. The primary goal of GSoC 2012 is to focus on projects that make this easy for the user to accomplish. Other projects that don't fit in this category but may still be of interest to students are listed in the last section.

=== Existing ability within XBMC for client/server setups ===
XBMC contains several features that allow for a client/server setup. These include:
* A UPnP server and client built-in.
* The JSON-RPC API for two-way passing of information.
* The EventClient API for two-way remote control communication.
* MySQL server support for sharing XBMC's music and video databases, with path translation services for sharing across different machines.
While these are each useful, they're typically either difficult for the user to setup (mysql server) or do not quite contain everything required for true client/server communication (UPnP doesn't share all metadata, editing isn't available from the client etc.) With some focused projects in this area, the user experience of XBMC across multiple clients/servers would be dramatically improved.

=== Projects within the client/server area ===
* '''Improved UPnP serving and client''' - XBMC includes a UPnP server and client. Not all of the metadata available within XBMC's libraries, however, are shared over the UPnP interface. This project would fill the gaps of missing metadata, as well as ensuring that niceties such as resume bookmarks and the like transfer seamlessly from client to client. In addition, the interaction between client and server would be enhanced to allow the client (or server) to update watched status, resume bookmarks and the like as well as allowing on-client editting of metadata which then updates the server (either using UPnP methods or the JSON-RPC interface). Any such improvements would be available transparently to listings other than UPnP (eg addon listings) by setting the appropriate properties.

* '''Clean scraping API with bindings to python''' - Currently XBMC uses regular expressions to handle the parsing of websites, and the existing scraper API is focused on this end use. Designing and implementing a new scraping API that is language-agnostic will allow alternate bindings to be provided, for example to python. Work would involve identifying the main entry points to scrape (eg CreateNfoURL, CreateSearchURL, GetDetails, GetArtwork etc.) along with any helper functions (callbacks to fetch URLs etc.), implementing a simple example of use of the API (in C/C++), then implementing a wrapper for the existing XML/regexp scrapers, and then adding python bindings with example python scrapers. The intention would be for most of this work to be done outside of the main XBMC codebase, with integration into XBMC being done as a last task.

* '''Improved remote clients for tablet/touch devices''' - Design and implement a remote client for touch-based devices (Android, iOS) that interact with the main APIs that XBMC provides for client apps (JSON-RPC and UPnP server). This may involve building on the existing Android remote control, and extending the JSON-RPC API and/or UPnP server for any additional requirements.

* '''Better support for multiple profiles within the server APIs''' - Currently XBMC has a profile system whereby multiple users can interact with the XBMC client and share the same library. These are currently stored outside of the main database, which makes interacting with XBMC using a particular profile troublesome. In particular, watched counts, resume points, ratings etc. are forced to be shared between profiles, and the only filtering of content is done based on which filesystem locations the profile is allowed access to. A better system would involve the profiles being stored inside the main database (or at least a representation of them in the database), allowing content and meta information related to the content (playcounts, resume points, ratings) to be linked to one (or more) of those profiles. In addition, specification of which profile is accessing JSON-RPC/UPnP would then allow those services to offer just the content information that the profile has access to.

* '''Custom library categories''' - XBMC's library categories of Movies, TV Shows, MusicVideos are currently fixed. This project would look to extend this to user-specified content categories. One potential extension is adding a content type column to each of the existing content tables, allowing simple queries for subsets of rows. The content type and category would be a source-level attribute, defined when the user first adds a filesystem source (or edits a source) to XBMC (e.g. type is TV Shows, category is Anime). XBMC would then show Anime and TV Shows as general categories (TV Shows being of type TV Shows and empty category). Additional support for further categorisation could be made by the addition of generic key/value tables to allow for extension of information. Without altering the existing tables, this could be done with an (idContent,idType,idKey,strValue) style table, supplemented with an idKey, strKey match. Additional database fetches for this table could then be done off-thread (eg in the thumbloader) for main listings, with joining to the table being done for filtering (smartplaylists).

* '''Extend skinning engine to better support touch interfaces''' - With tablets and other touch interfaces being used more and more, it makes sense to define UI controls that better interact with these devices. In particular, a drop down list box (combobox) would be an ideal addition that would benefit touch devices (and non-touch devices). In addition, the addition of buttons attached to items in list would be useful to serve as hints for additional menu options available to the user, most of which is currently hidden behind the context menu (not discoverable), or clumsily available via always-popping up menus when the user taps an item. Further, the potential for XBMC scaling panel or list controls using multi-touch zooming would be useful to explore.

* '''Extend skinning engine to better support multiple layouts''' - Many tablets are 3x2 or 4x3 interfaces, where as televisions are typically 16x9 (or even 21x9). Having the layout/scaling and positioning of the skin being done on a controlgroup basis rather than being defined at the window layer would allow groups to automatically reposition their content to better align with the aspect ratio of the users' device. For example, aligning a group to the center of it's parent, while ensuring it doesn't stretch would allow information to remain in the middle of the screen regardless of aspect ratio. Other improvements would be to allow relative control positioning (i.e. control <foo> should be positioned 10 units to the right of control <bar>) which allows the skinner to both more easily prototype and skin as well as making it easier to alter.

* '''Extend skinning engine to allow populating lists/panels with filesystem content''' - Currently skinners must choose between static content, defined by the skinner, or dynamic content filled by XBMC over which they have no control. This project would look to add a 3rd option, whereby the skinner specifies that they want the list filled with particular content from the filesystem or from XBMC's libraries. XBMC would then retrieve the listing and any metadata and populate the list (all in the background). In addition, XBMC would then apply it's default actions for that listing (with interaction to the skin as needed) when the user interacted with that listing (eg playing a music file when the user clicks on it).

* '''Picture Library''' - Design and implement a database schema suitable for storing and retrieving picture metadata. Fields should consist of the typical fields found in picture files (eg EXIF information) along with an extensible key/value field system to allow tagging/keywords/people etc. Support should include the ability to identify when new pictures have been added to the users' filesystem or when metadata information has been changed for one or more pictures. Design and implement a filter/directory node system so as to allow the user to browse and search this information, allowing smart filtering and smart slideshows to be generated. Lastly, add support for such filters to the picture window.

=== Other projects of interest ===

* '''Games / Program Library''' - ''Medium Difficulty'' - Add functionality similar to the current video and music library for a games / programs. Add a game / program executable or a folder of roms for emulators. Parse files for tags and other metadata. Store paths and metadata in a database and possibly scrape sites for more information.
* '''Automated Test Suite''' - ''Difficult'' - Devise a mechanism for defining and executing automatic regression tests of XBMC features.
* '''Improved Picture Player''' - ''Medium difficulty'' - Write a new picture/slideshow engine to be more like a normal player (see [[DVDPlayer]] and [[PAPlayer]] as examples). Ideal would be to utilize the existing GUIImage code to handle loading of images, and the animation engine for transistion effects (pan/zoom/rotate, etc.)
* '''RSS reader''' - ''Medium difficulty'' - Create an addon which works much like google reader that supports parsing text, video and pictures, (supporting multiple RSS feeds), and displaying this in the GUI. This should be simple enough, like the RSS readers on mobile devices, but suited for a TV display.

== Students Project Proposal Ideas ==
Feel free to add of your own ideas for projects here. They can be as big or as small as you feel you can comfortably accomplish between May 21st and August 20th. In the end, it's better to have a smaller, completed project, rather than a larger, incomplete project.
=== Input Generalization ===
Currently in XBMC input is handled very differently depending on the control and each input type is isolated and added as extra and the code have become quite a bit unmaintainable. This leads to a large number of regression bugs and a large number of inconsistencies between the input types. Some bugs are almost unfixable as it is really hard to follow what is going on and even harder to know what is supposed to go on.

As such I propose a clean general input layer where every input type is handled the same way and an input device is made up of a number of smaller, much easier to define, types of input.

The idea is the following: We have many input devices on the system, each input device have an ID which is used when mapping to an action. An ID is for example "wiiremote" or "mceremote". Of course one could add that an input also have a UUID so multiple input devices of the same ID can exist and can be used in games, but this is another matter and the abstraction soon to be explained should be able to handle that addition.
Each input device can send Input events to the Input manager, which resides in the core. An input event could for example be that a button is down/up or that a cursor have been moved to a new location. It can also state that an analog location have been moved. Further abstraction would be that an analog location is what a mouse cursor is, however it may make sense to separate those.

As it is currently in code a joystick button is not handled the same as a keyboard button or a remote button, not even a mousebutton. Essentially all button triggers should be processed in the same method and it does not really matter what input device triggered them.

For example a keyboard would be an input device with ID="keyboard" and could send that button="A" is down. Another input device could send ID="WiiRemote" and button="A" is down. Since ID is not the same these are not considered the same remote and the mapping can be different.

So every input on a system becomes an input device, each device can send input events which consist of the ID of the remote and information about the actual event. This event can reflect a button state change or a cursor change.

XBMC Core will then take the input event and map it depending on the ID and the actual event along with a window to create an action. This almost what is done now but currently the code is not general and not shared among the input types.

When we have a general input layer it would be possible to allow jsonrpc to act as an input but also create input addons.

=== Media Server ===
* ''Summary'': It becomes increasingly popular to have more than one instance of XBMC in a household, even more so with the introduction of XBMC on portable devices. This means that sharing the library between XBMC instances becomes much more important to the average user and the current model of doing this via MySQL, while it works, is not user friendly nor future proof. I propose as a project to take core features of XBMCs incredible media management and make them available in a seperate server instance. Note that this does not enforce a client server model and I am not proposing a move to a client server solution, XBMC will and should always have the possibility to run as a stand alone instance fully in charge of its data, this is one of the most important features which most other media centers does not have and it makes XBMC a very user friendly application. What I am proposing is merely the possibility to have XBMC act more like a thin client, i.e. if a server exist on the network its transparently added and feels like it is integrated in client. Instead of doing the sharing over MySQL the data could be shared over uPnP, afterall uPnP is made to share libraries. This would also make other media devices, which is not power by XBMC, able to use said features. The features which makes XBMCs media playback and presentation so great are amongst other things our VFS and scrapers, coincidentilly these parts of XBMC are those which have had quite a bit of feature creep and could use some sanitizing. What I propose is to create small isolated libraries, tested and designed outside of xbmc. The media server would thus be a way to actively test the libraries and hopefully spot problems in the API before they get adopted. When the libraries are considered in a clean state they could be used inside XBMC aswell (not part of this proposal though). The code which is sane in XBMC can obviously be ported over, no need to reinvent the wheel. This does allow for an interesting possibility to clean up our API and make these features available for more than just XBMC with the nice sideeffect of creating a media server!
* ''What will the project focus on'': XBMC, while amazing has quite a bit of feature creep and much of the functionality in XBMC is not as isolated as they could be. Since this project will take a lot of the technologies from XBMC it have the chance to create a set of libraries which are clean, reusable, isolated, designed outside of XBMC and used outside of XBMC. Some of the libraries which could be created as a part of this project is a VFS, scanning and scraping, URL and database libraries. When the project is done these libraries can be used in XBMC (or any other project) if wanted. The media server will act as a testbed for the libraries which are created whilst creating something of use for end-users of XBMC.
* ''Benefits'': From the users perspective they install the media server on his / her computer or server and the HTPC picks up the server and use it. If a friend pops by with a laptop with the server as soon as it enters the network the HTPC can use the content available on said laptop. Another scenario would be that the user have more than one XBMC installation, perhaps on his portable device or just many HTPC boxes. When adding a movie to the server all of these devices will pick it up and if one device watch the movie it is shared amongst them. The project will create a set of reusable libraries which allows which can be used by XBMC which could lead to a cleaner and more stable core, and a way to test functionality outside of XBMC.
* ''Goals'': Create reusable and clean libraries for VFS, database, scanning, scraping and media database.
* ''What does it touch in XBMC'': Nothing, it will require pulling technologies from XBMC
* ''Requirements'': C/C++ for the libraries to be created but Python for the server.
* ''Possible mentors'': jmarshall, spiff

[[Category:Google Summer of Code]]