[Rasp123]

For a project I want to start I was trying to adjust the default Estuary skin. As such, I was investigating how to dynamically change the contents of a label.
However, Kodi crashes on the setLabel function call. Am I missing something here?
Log doesn't show anything why it crashed, even when on debug log.

I have verified:
- The script is running (verified through embedding a log earlier)
- The ControlLabel object is obtained through the getControl function (verified through splitting the function calls)

Running on Debian (Bullseye) on a rasp 4b. 

I have added the following:
Home.xml:

Home.xml:


<control type="label" id="799">

<label>Test</label>

<top>200r</top>

<height>200</height>

<color>ffffffff</color>

</control>



<control type="button" id="800">

<onclick>RunScript(/../run.py)</onclick>

<onup>700</onup>

<width>462</width>

<left>0</left>

<height>100</height>

<top>100r</top>

<font>font12</font>

<label>Run</label>

<color>ffffffff</color>

</control>

Contents of run.py is:

run.py:


import xbmcgui

xbmcgui.Window(10000).getControl(799).setLabel('12345')

[jurialmunkey]

You'd think it wouldn't matter but you need to separate the window and control objects and assign to separate variables first before calling setLabel.

python:


win = xbmcgui.Window(10000)

con = win.getControl(799)

con.setLabel('12345')

[Rasp123]

Thanks this indeed solved it.
For learning purposes, what's different in the background of doing it multiple steps vs. chaining functions?

[jurialmunkey]

Thanks this indeed solved it.
For learning purposes, what's different in the background of doing it multiple steps vs. chaining functions?

The function returns an object. Assigning the object to a variable creates a reference to that object in the local scope. The reference will exist until the scope returns, which delays garbage collection on the object. For the chained function, the reference only exists for the chain, so it can be garbage collected earlier once the chain completes.

It shouldn't matter though. Either approach should work and the fact that it doesn't indicates a bug somewhere.

There's been a long standing bug for Kodi's CPython API not performing garbage collection properly (the "left classes in memory" log notification), so I assume it is related. My guess is that when chained, the CPython API is deleting the object too early before the chain completes, thereby causing a null pointer dereference crash. Assigning to a variable forces it to continue to exist.

[Rasp123]

Thanks for explaining, makes sense.
Effort is much appreciated!