Why is 'abortRequest' so inconsistent in practise?
#1
I'm finding with a service addon that abortRequested is rather inconsistent.

E.g.
Windows - if I hit the close window button, it isn't called. If I shutdown Kodi via it's own shutdown, it is.
LibreElec - It doesn't appear to be called on a reboot via the close menu, or on a shutdown via the remote.


The real question is - is there any guaranteed way to run some addon code (I want to turn a device off) - on exit of Kodi, that behaves consistently. Obviously it if crashes, weird behaviour is expected, but I'd have thought that and regular close/shutdown would trigger the addon abort stuff.

(and atexit doesn't work with Kodi right?)
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply
#2
I'm having a similar issue, I wait for Kodi to exit in an addon I've developed using the statements below:

monitor = xbmc.Monitor()
monitor.waitForAbort()
...some more code here....

The code gets executed at the moment I disable, the addon. However, if I select shutdown from the menu, it is not called.
I'm running the code on OpenELEC, have tried version 6.0.3 and 7.0.0, they behavior is the same.

In my opinion the code should get excecuted nomatter how you exit Kodi, or am I wrong here? The documentation states this is (one of) the proper method(s) to do this and there is no mentioning of dependencies on how Kodi is exited.

I doubt I'm doing anyting wrong here, as are you. So I'm thinking this a bug in Kodi (or maybe OpenELEC in this case).

Hopefully some smart guys read this thread and can enlighten us ;-)

Kind regards,

Jorg
Reply
#3
I find it quite random - does not seem to matter how I exit....it will sometimes get called, and others (mostly) not - can't isolate it to a specific exit method.
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply
#4
I do think this a bug in kodi, and i'll probably file a bug report if I find the time.
If anyone disagrees, there is still some time to keep me from doing something stupid ;-)
Reply
#5
(2017-01-07, 03:08)bossanova808 Wrote: Windows - if I hit the close window button, it isn't called.

afaik that's expected behavior. windows instantly kills kodi and there no time left to execute any shutdown functions.
hence, this is not the way one should exit kodi.
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#6
(2017-01-09, 00:21)jorgh Wrote: I'm having a similar issue, I wait for Kodi to exit in an addon I've developed using the statements below:

monitor = xbmc.Monitor()
monitor.waitForAbort()
...some more code here....

it works fine here (tested on linux).
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#7
I think the issue is related to Openelec. The addon I'm using needs to call something on a domotica system. But openelec shuts down the network before the addon is able to fire it's request.

I've tested using "sysctl stop kodi" and the code is properly excecuted. In this case I think After=network.target needs to be added to the kodi.service systemd kodi.service file.

I'll try my luck at the openelec suport forum or IRC channel.

Thanks for all the responses, it helped me figure out what went wrong.

btw, Windows does not just kill a process on hitting the close button. I'm not running Kodi on windows, so I cant verify if Kodi does not handle this way of closing properly. On hitting the close button, a clean closing of Kodi should commence (just look at what notepad does, after you've made some changes and press the red cross ;-)
Reply
#8
(2017-01-24, 22:02)jorgh Wrote: btw, Windows does not just kill a process on hitting the close button. I'm not running Kodi on windows, so I cant verify if Kodi does not handle this way of closing properly. On hitting the close button, a clean closing of Kodi should commence (just look at what notepad does, after you've made some changes and press the red cross ;-)

ok, i'm not a windows user myself :-)
was just repeating what others, who i assume are more knowledgeable in this area than me, said:
http://forum.kodi.tv/showthread.php?tid=...pid2445079
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#9
in short. if your script does not receive (or process correctly) onabortrequested on Le, that means kodi is crashing on exit.

in LE, there is an additional patch that's supposed to handle SIGTERM signal that's sent to kodi from init, then init waits 5 seconds or so and if kodi still did not exit cleanly, LE does not care. if kodi crashed right before addons received abortrequested - nothing can be done. it's a bug in core/python.

we added that sigterm handler patch to OpenELEC (and it is still in LE, for good) years ago, to solve crashes or deadlocks when doing reboot/shutdown from kowe added that sigterm handler patch to OpenELEC (and it is still in LE, for good) years ago, to solve crashes or deadlocks (EDIT: because misbehaving addons: weather underground, trakt, watchdog, so please dont make another one..) when doing reboot/shutdown from kodi shutdown menu.

EDIT: so, no, you can't count on abortRequested, however, if you use it, you should execute as less code as possible there (if you need to clean up or something), you should not delay or block after you got the event. it is not there for you to run code at shutdown..
Reply
#10
/offtopic: if there's a problem with weather underground, please let me know and i'll look into it :-)
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#11
(2017-01-24, 22:25)stefansaraev Wrote: so, no, you can't count on abortRequested, however, if you use it, you should execute as less code as possible there (if you need to clean up or something), you should not delay or block after you got the event. it is not there for you to run code at shutdown..

Imho, the SIGTERM signal is there to allow proper cleanup at shutdown, otherwise we could always use SIGKILL ;-). I fully agree, that one should not use lenghty code that delays or blocks the shutdown, but only do what is necessary for a clean exit. So in my opinion the event is (or should be) there to run code at shutdown, if not, what is the alternative? If you run lengty code after a SIGTERM, you're punished by the SIGKILL signal that inevitably follows the SIGTERM signal, and it's your own fault in that case ;-)
Reply
#12
(2017-01-25, 11:33)jorgh Wrote:
(2017-01-24, 22:25)stefansaraev Wrote: so, no, you can't count on abortRequested, however, if you use it, you should execute as less code as possible there (if you need to clean up or something), you should not delay or block after you got the event. it is not there for you to run code at shutdown..

Imho, the SIGTERM signal is there to allow proper cleanup at shutdown, otherwise we could always use SIGKILL ;-). I fully agree, that one should not use lenghty code that delays or blocks the shutdown, but only do what is necessary for a clean exit. So in my opinion the event is (or should be) there to run code at shutdown, if not, what is the alternative? If you run lengty code after a SIGTERM, you're punished by the SIGKILL signal that inevitably follows the SIGTERM signal, and it's your own fault in that case ;-)


that's exactly what LE is doing. kodi does not handle SIGTERM by design. TERM acts just like KILL in vanilla kodi.
Reply
#13
(2017-01-25, 15:18)stefansaraev Wrote: kodi does not handle SIGTERM by design. TERM acts just like KILL in vanilla kodi.

By design would mean that it is a conscious choice. Wonder what the rationale behind that choice is....
Reply
#14
I've done some more research and am still unsure what is going on.

When I shutdown Kodi, using shutdown in the Kodi menu, I can see that Kodi does exit, however it does not exit in the same manner than i've its killed through the systemd service.
Both stopping Kodi by using "systemctl stop kodi", issueing a shutdown or reboot from the command line, or sending it a TERM signal, I see far more logging in the kodi log to cleanup everyting, than if I issue a shutdown command through the Kodi GUI. As such, I doubt that it is an systemd config issue (i've also fiddled arount with systemd config to ensure Kodi is not killed to soon, but this does not change the behaviour).

When exiting kodi, throug it's gui, the last log entry in the kodi log is: "NOTICE: ## OpenELEC Addon ## STOP SERVICE DONE !"
When instucting Kodi to exit through sendinding it a TERM signal (or any of the other methods mentioned above), I see far more cleanup and the last entry is "NOTICE: application stopped..." Which in my opnion should always be the last log entry that you would expec on a clean exit. I've not found kodi crashlogs, so I don't suspect a Kodi crash in this case.

So, this gets my suspicion back on Kodi again.

Anybody any leads? Does anybody know what the Kodi GUI shutdown function calls, so I can investigate the difference in behaviour between the exit methods.
Reply
#15
i don't know much of that portion of the kodi code, but start looking here:
https://github.com/xbmc/xbmc/blob/6d5a87....cpp#L2405
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply

Logout Mark Read Team Forum Stats Members Help
Why is 'abortRequest' so inconsistent in practise?0