[ronie]

Below you'll find an up-to-date list of all changes made to the python API since the release of Kodi Krypton.


previous threads:

• Changes to the python API for Kodi Krypton
  

Please keep this thread clean. It should be an easy overview for python coders who are updating their addon for Kodi Krypton.
For discussions / feature requests / bugreports, please find (or create) the appropriate thread in the addon development forum.

[ronie]

2017-01-04 DBID for music items

addons can now set & get the dbid for music items

Code:

listitem.setInfo('music', {'mediatype':'song', 'dbid':12345})

dbid = listitem.getMusicInfoTag().getDbId()

pull request: https://github.com/xbmc/xbmc/pull/10858

[ronie]

2017-01-04 WindowXML setContent

addons using WindowXML that are creating a media list using the built-in container,
can now set the content of the container:

Code:

self.setContent('movies')

pull request: https://github.com/xbmc/xbmc/pull/11258

[ronie]

2017-01-05 mediatype for music items

addons can now get the mediatype for music items

Code:

mediatype = listitem.getMusicInfoTag().getMediaType()

pull request: https://github.com/xbmc/xbmc/pull/11110

[ronie]

2017-01-05 int/float support for slider controls

addons can now define a float or int range (instead if just a fixed 0-100%) range for slider controls

Code:

self.slider.setFloat(15.0, 10.0, 1.0, 20.0)
self.slider.getFloat()

self.slider.setInt(450, 200, 10, 900)
self.slider.getInt()

the params are: current value, min value, step size, max value


pull request: https://github.com/xbmc/xbmc/pull/11230

[gedisony]

2017-01-04 WindowsXML setContent
addons using WindowsXML that are creating a media list using the built-in container,
can now set the content of the container:

Code:

self.setContent('movies')

pull request: https://github.com/xbmc/xbmc/pull/11258

I'm just curious,

setContent() lets the skin know how to list the directory items, what view types will be available and which infolabels to display.

Using windowsXML bypasses the skin system and can use setProperty/getProperty to pass values. Why use setContent() ?

[ronie]

it's only useful if you use the built-in container of the window, which 99.999999999% of the addons don't use ;-)

pretty much all addons define a container and add listitems to it:

Code:

self.getControl(1234).addItems(listitems)

but you can also add the listitems directly to the window:

Code:

self.addItems(listitems)

if you use that method, you can define multiple view types in the skin xml file of your addon,
and define which views (or other controls) are visible based on the content type.

[ronie]

2017-03-05 kodi language file changes

not a python related change, but it can potentially affect your addon..

as of PR#11039 the kodi language file no longer uses '%s' / '%i' string formatting.
in case your addon is using any of the affected strings from the kodi language file, please be aware this will no longer work:

Code:

xbmc.getLocalizedString(20464) % foo
xbmc.getLocalizedString(299) % count

pull request: https://github.com/xbmc/xbmc/pull/11039

[ronie]

2017-03-17 WindowXML isMedia

addons using WindowXML that are creating a media list using the built-in container,
need to set the isMedia bool to True in the window constructor:

Code:

win = xbmcgui.WindowXML('script-globalsearch.xml', xbmcaddon.Addon().getAddonInfo('path').decode('utf-8'), 'default', '1080p', True)

this will allow you to reference the container in the skin xml without specifying the container id.

pull request: https://github.com/xbmc/xbmc/pull/11766

[peak3d]

In the next couple of weeks a PR will go into kodi that keeps python sessions open as long a user navigates inside an addon.
Reason is that this pushes performance significantly because modules are taken from python cache instead reloading / rereading them on every click.

From development side this means: Only the default python script (defined in addon.xml. commonly default.py or addon.py) are re-interpreted on every click.
All imported (sub-) modules will be taken from cache and not reinterpreted.

What does this mean for you python addon dev?

- arguments passed from kodi to addon are only available in default script, if you need them in any of your submodule script you either pass the current arguments from default script into your submodules, or you call sys.argv inside your functions where the code is executed. Storing the value of sys.arg[#] in a global variable at the head of your submodule will not work because the code is only executed once on first module startup, but not on subsequent calls.
- For compatibility reasons sys.argv[0] (base_url) and sys.argv[1] (plugin_handle) stay same when reused. This means that it is possible now to store them in a global variable in submodules.
- if you are debugging / developing a submodule, you may have to first select an other addon and then return to your addon to get a fresh reload. Or switch reusing of python session off (see below)

Reusing of python sessions can be disabled in addon.xml, metadata section:

xml:


<extension point="xbmc.addon.metadata">

  <reuselanguageinvoker>false</reuselanguageinvoker>

</extension>

Edit: Pull Request: https://github.com/xbmc/xbmc/pull/13814

[FernetMenta]

Usage of DialogBusy results in nop now. I removed it becuase it was wrong: https://github.com/xbmc/xbmc/pull/13954

Unfortunately Kodi's GUI lacks a proper MVC (model view controller) architecture. Giving addons the chance to open modal dialogs in an uncontrolled manner is wrong. In this particular case it lead to crashes that I fixed with this change. DialogBusy is a singelto and must only be used once at a given time.

EDIT: as a workaround python scripts can make use of the new DialogBusyNoCancel: https://github.com/xbmc/xbmc/pull/13958

[ronie]

2017-06-06 Addon Settings

new options for getting and setting addon settings were also added a while ago:
 

• getSettingBool()
  
• getSettingInt()
  
• getSettingNumber()
  
• getSettingString()
  

 

• setSettingBool()
  
• setSettingInt()
  
• setSettingNumber()
  
• setSettingString()
  

PR: https://github.com/xbmc/xbmc/pull/12228

[da3dsoul]

There was notes on changing duration format for ListItem. One of my users said that time was broken in several places, but I don't expect them to piece together how each place correlates to what.
I'd like this to be all in one place for future reference and verifying.
Duration/Time is referenced in several places:

• Player().GetTime()
  
• Player().GetTotalTime()
  
• ListItem.Duration
  
• ListItem.Property('TotalTime')
  
• ListItem.Property('ResumeTime')
  
• ListItem.Property('StartOffset')
  
• possibly more that I'm forgetting
  

What is the format for all of the above? It's likely that I'll need to convert values in my addon for different places.

[ronie]

for skins, there has been a change regarding $INFO[ListItem.Duration]
for videos it used to return the time in minutes, which now has been changed to a HH:MM:SS format

i'm not aware of any changes regarding python addons though.
afaik getting / setting time is still done in seconds there.

[robweber]

2017-06-06 Addon Settings

new options for getting and setting addon settings were also added a while ago:
 

• getSettingBool()
  
• getSettingInt()
  
• getSettingNumber()
  
• getSettingString()
  

• setSettingBool()
  
• setSettingInt()
  
• setSettingNumber()
  
• setSettingString()
  

PR: https://github.com/xbmc/xbmc/pull/12228  

I have a question on these, not sure if what I'm seeing is a bug or intended behavior. In testing if I use the getSettingBool function on a bool type setting I get a 0 or 1 as a result. I was expecting an actual python bool True/False value. This was causing some if statements to fail on me so I wrapped them in a bool() function and then they worked. I am testing with Leia with Python 2.7 still. Would Python 3 yield a different result?

UPDATE

I wrote a test addon just to see if I could duplicate behaviors I was seeing. The getSettingBool does return a 0 or 1 but if statements all evaluate fine. The issue I was having I think is that I was putting the bool value into a dict object and then using json.dumps() to generate a JSON string. Because the value was a number I was getting something like {"value":1} rather than {"value":true} - which is what I was expecting. Again, wrapping the result in a bool() fixes it but that was the true problem.