X-NEWA Very Slow to Start

[pkscout]

I've had this issue for awhile, and it finally got annoying enough that I decided to look into it a bit more. What happens is that if I haven't used XNEWA in awhile (i.e. first thing in the morning), it can take several seconds (sometimes 10 - 12 seconds) for any X-NEWA window to open. While I'm waiting I can do other stuff in XBMC, so for a long time I thought I just hadn't hit the remote button correctly. The problem seems much worse on my Windows machine (where Next PVR is as well) than on my OSX machine (where I do my development work).

After walking the code a bit, the best I can figure is that it has something to do with the suds object cache created in XNEWA_Connect. The thing is, all that accounts for about 10 lines of code, and I can't see anyway to optimize it (or even why it would be causing a problem). So I attacked it from the other end. I decided it the lag is going to be there, at least it would be nice to know XNEWA was starting. So I added a dialog to default.py similar to the one used when the channel icons are cached. In Gotham, it uses the newer background dialog (a little less obtrusive IMHO), but that's somewhat a style choice.

Just below the first import I added:

Code:

from xbmcaddon import Addon
    if int( xbmc.getInfoLabel( "System.BuildVersion" ).split('.')[0] ) >= 13:
        from xbmcgui import DialogProgressBG as _dialog
    else:
        from xbmcgui import DialogProgress as _dialog

Then the XNEWA_Connect call looks like this instead:

Code:

sDialog = _dialog()
        sDialog.create( 'X-NEWA', '%s %s' % (smartUTF8(__language__(30153)), smartUTF8(__language__(30000))) )
        my_xnewa = XNEWA_Connect(settings=my_settings)
        sDialog.close()

The message you actually see is "Connecting to NextPVR." I thought I'd share in case there was interest in adding that to the shipping version. If there's interest in migrating more of the progress dialogs to background dialogs, I'd be happy to look at that. I'd probably opt to wait for the next official release so that I'm not working too much on the older codebase I have here.

[mvallevand]

Is the slowdown related to X-NEWA or do you think it could be NEWA? NEWA can be slow to start up from a restart/reboot and on top of that NEWA by default will scan all your recording folders so shares etc have to wake up. I manually edit NEWA code to avoid that slowdown.

Two areas in the logs to look for NEWA slowdowns would be between

Code:

12:43:54 T:8420  NOTICE: AreYouThere() returns: True
12:43:54 T:8420  NOTICE: http://ip:8866/public/Util/NPVR/Client/Instantiate
...
12:43:54 T:8420  NOTICE: {u'SIDValidation': {u'validated': True}}

Code:

12:43:54 T:8420  NOTICE: XML info
...
12:43:56 T:8420  NOTICE: XML Info end

If it is really the suds code, I am not too worried about it since I am taking it out, after the next NEWA builld.

Martin

[pkscout]

I'll take a closer look at the logs. The times I've noticed it and looked at the logs it occurred between when XNEWA logs "DST off" and "init fanart." I don't restart the windows machine very often (or put it to sleep), but it could be NEWA is waking up after a long pause with no activity.

[zaldwaik]

I use openelec and starting X-NEW with default NPVR screen takes a long time, at least 12 seconds. While being used sometimes it stops responding to remote clicks completely and I have to reboot to recover. This often happens after some navigation around.

[mvallevand]

I use openelec and starting X-NEW with default NPVR screen takes a long time, at least 12 seconds. While being used sometimes it stops responding to remote clicks completely and I have to reboot to recover. This often happens after some navigation around.

There is a problem in NextPVR that I have told sub update where the initial remote connections generate errors instead of sending screens, I can't do much on the client just send keystrokes and let it display on it's own.

For your second observation without specifics or logs nothing much I can say. It was a problem on the main menu with sub fixed in 3.2.9. See if turning off animation helps.

Martin

[sub]

zaldwaik, can you post the logs, so we can see if there any errors in web.log or npvr.log?

[zaldwaik]

Sorry for the delay, but I just ran into the issue where the interface stops responding to remote clicks. I was not clicking much, went to TV guide and then it would not respond. Logs attached.

[mvallevand]

For case #2 I can see a freeze in NextPVR logs but I'd need the corresponding xbmc log too.

Martin

[zaldwaik]

I was wondering if I use a different faster HW than Rasp Pi (ASUS Chromebox appears to be promising) would NPVR start and respond faster? The current LiveTV XBMC functionality is lacking, so I go directly to the NPVR interface. But the slowness to start, along with serious lag for button presses makes it barely usable. It is even slower than my Popcorn Hour box. I am using Aeon Nox for skin and it is surprisingly responsive, but some add-ons lag. Your thoughts?

[mvallevand]

I was wondering if I use a different faster HW than Rasp Pi (ASUS Chromebox appears to be promising) would NPVR start and respond faster? The current LiveTV XBMC functionality is lacking, so I go directly to the NPVR interface. But the slowness to start, along with serious lag for button presses makes it barely usable. It is even slower than my Popcorn Hour box. I am using Aeon Nox for skin and it is surprisingly responsive, but some add-ons lag. Your thoughts?

I don't use my RPi for XBMC it was too laggy with the native UI for me, I am sure that web client would be worse. You can tweak things to speed it up, turn off library scanning and disable the xbmc pvr addon which is always running the back ground but it never will be a speed demon. The NMT was an optimized remote client, but I never considered the RPi good enough to bother optimizing as an NMT replacement.

Too answer your question try XBMC/X-NEWA on a real linux/windows PC and you can see the best case for x-newa. fred250's app for Samsung players is using the web client is definitely a good alternative to the RPi

Martin.