[zomboided]

I've just added an onNotification method to my monitor class in my addon to intercept the onWake notification. Everything is good, when the system wakes up, I get an event.

However, the waitForAbort() that I was using in the main loop is no longer detecting the onQuit event so it doesn't let Kodi shutdown.

The onQuit event is being picked up by onNotification, and I currently am setting a variable to be True and then doing my own check followed by xbmc.sleep(10) as an alternative to waitForAbort(10).

Is this the right approach? Will doing the sleep cause any problems (I've not seen any yet)? I'm on Kodi 17 if that makes any difference to this.

[Lunatixz]

Could you post your code, from the description it sounds okay to use your own escape and sleep. As long as you have a fallback to execute escape on abort.

I've also observed strange waitforabort behavior. Your best bet would be to create a test script, log all loops and events and post both the log and script at Kodi's Trac page.
http://trac.kodi.tv/

Sent from my SM-G935T

[zomboided]

The is the class, with a global variable

Code:

abort = True

class KodiMonitor(xbmc.Monitor):

    def onSettingsChanged( self ):
        # Do some stuff to update the settings
    
    def onNotification( self, sender, method, data):
        global abort
        if method == "System.OnWake":
            # Do some stuff
        
        if method == "System.OnQuit":
            abort = True

Then this is the main loop

Code:

while not monitor.abortRequested():

    # Do a load of stuff

    shutdown = False
    for i in range(0, delay):
        if waitForAbort(1000):
            # Abort was requested while waiting. We should exit
            shutdown = True
            break
        if not getAPICommand() == "":
            break
    if shutdown: break

Finally, the waitForAbort(1000) just does this:

Code:

def waitForAbort( time ):
    if not abort: xbmc.sleep(time)
    return abort

I probably should change the while loop condition to check for the abort boolean, but I think I'm most concerned about the CPU load when doing a sleep every second. I need to do this as I'm trying to read an API command that can be input to the plugin whilst it's running. I guess this is what the monitor version of waitForAbort(1) does, but I'm not sure.

I'm not sure what you mean by this : "As long as you have a fallback to execute escape on abort". Can you say some more please?

Any input appreciated...thanks!

[Lunatixz]

I probably should change the while loop condition to check for the abort boolean, but I think I'm most concerned about the CPU load when doing a sleep every second. I need to do this as I'm trying to read an API command that can be input to the plugin whilst it's running. I guess this is what the monitor version of waitForAbort(1) does, but I'm not sure.

I'll review the code tonight, in the meantime check out post #15 from the link below.

https://forum.kodi.tv/showthread.php?tid...pid1735110

Sent from my SM-G935T

[Milhouse]

Is this the right approach? Will doing the sleep cause any problems (I've not seen any yet)? I'm on Kodi 17 if that makes any difference to this.

You should be using monitor.waitForAbort().

Your sample code then becomes:

Code:

while not monitor.abortRequested():

    # Do a load of stuff

    monitor.waitForAbort(delay)

and you can get rid of the global "abort".

[Lunatixz]

Is this the right approach? Will doing the sleep cause any problems (I've not seen any yet)? I'm on Kodi 17 if that makes any difference to this.

You should be using monitor.waitForAbort().

Your sample code then becomes:

Code:

while not monitor.abortRequested():

    # Do a load of stuff

    monitor.waitForAbort(delay)

and you can get rid of the global "abort".

@Milhouse Check the OP =) waitforabort was breaking his loop prematurely.

[Milhouse]

@Milhouse Check the OP =) waitforabort was breaking his loop prematurely.

Yes, and I thought twice about posting, but he says:

the waitForAbort() that I was using in the main loop is no longer detecting the onQuit event so it doesn't let Kodi shutdown.

and then posts a sample which uses his own function called waitForAbort() and globals, so it's not clear if his problem is with monitor.waitForAbort(), or it's with his own custom waitForAbort().

If the problem is with monitor.waitForAbort() then let's see a code sample that demonstrates the problem, as that's what he should be using in place of his own function.

[Lunatixz]

@Milhouse Check the OP =) waitforabort was breaking his loop prematurely.

Yes, and I thought twice about posting, but he says:

the waitForAbort() that I was using in the main loop is no longer detecting the onQuit event so it doesn't let Kodi shutdown.

and then posts a sample which uses his own function called waitForAbort() and globals, so it's not clear if his problem is with monitor.waitForAbort(), or it's with his own custom waitForAbort().

If the problem is with monitor.waitForAbort() then let's see a code sample that demonstrates the problem, as that's what he should be using in place of his own function.

ahhh my taptalk code view is skewed didn't notice a custom waitfor abort function =)

[zomboided]

Originally I was using monitor.waitForAbort() like this:

Code:

while not monitor.abortRequested():
    
    # Do some stuff

    shutdown = False
    for i in range(0, delay):
        if monitor.waitForAbort(1):
            shutdown = True
            break
        if not getAPICommand() == "":
            break
    if shutdown: break

But when I added the onNotification() to detect a system wake notification, I observed that the monitor.waitForAbort and/or monitor.abortRequested() were never true to break the loop. I added in some debug code to print out the events that onNotification was receiving and noticed that the onQuit event was being received when the system was going down, hence this thread.

The code that I have appeasr to work - in that it allows the service to quit, but I had concerns whether it was an appropriate pattern to use (ie whether there were other notifications I should also be checking to determine when to break), and whether xbmc.sleep would be an issue (which you've both cleared up for me, thanks!) I guess I'm also surprised that just by adding an onNotification, this changes the 'standard' abort behaviour. Maybe this is what I need to raise a bug about?