Video addon performance on Pi
#46
(2014-07-21, 18:42)LehighBri Wrote: Any thoughts or guidance on the following potential optimization regarding keeping http connection open to speed things up?

Without the results of profiling, it's hard to tell.
If profiling identified that http requests were taking a significant amount of time, then sending multiple GET requests per connection may well help.
Reply
#47
(2014-07-17, 16:41)popcornmix Wrote:
(2014-07-17, 16:26)isilver18 Wrote: It's a shame we haven't overcome this problem yet.

Can you describe an add-on with a problem, and time how many seconds it does to do various operations (e.g. navigating though menu levels and starting video playback).

We can then determine if your setup is slower than others (in which case some change of settings may help you),
or whether something can be done in xbmc, or the add-on to make it faster.

I can give an example as i've had a great deal of experience with slow video addons. Genesis is a big one for me takes about 30 seconds to open. Then about 30 seconds if I click a menu such as television. Once that loads if I hit most popular im presented with another 30second waiting screen and on and on until I finally get to the show I want to watch and select the source. It does this constantly as if it is not caching anything and I am running open elec using usb 3.0 storage overclocked. It seems to be lingering on the working screen and not the loading of the actual sources.
Reply
#48
It's usually not nice to dig out old threads, but neither is starting a new one with the same topic! Tongue

I found a 'not so nice' way to make a video plugin way faster on the RaspberryPi:
where it took 2-3s for every operation before, it is now done in 0.1s

I'll try to explain:
As discussed the problem is the slow python interpreter, it takes 2-3s to load the code and all the imports, the 'real' functionality is done in a few ms.

But what if the plugin was started only once?

I made just that:
- the plugin called by xbmc is just an interface to the real code, it is just a few lines and loads very fast
- on first run the plugin creates a thread of 'the real code' which keeps running
- on succeeding runs the plugin passes the arguments to the already running thread which in turn races through the functions

It works beautifully!
I made a wrapper for the original plugin that handles the communication but I didn't change anything on the original plugin at all

There is still one problem I found a workaround but no real solution, I made a post about it: Python: save reference to a thread

what is the prefered way of sharing code here?
It's just a few lines
Reply
#49
If it's just a few lines of code paste it within a formatted code block. (The # function in the editor).

I for one am very interested in seeing it! Smile
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#50
Ok, here you go, and please excuse some code ugliness, this is the first time ever I've looked into python

this is default.py (the script called by XBMC):
Code:
import sys,xbmc,xbmcaddon,xbmcgui

WINDOW = xbmcgui.Window(10000)

#wait for handler to reset arguments of last call
while WINDOW.getProperty('arg1')!='':
    xbmc.sleep(1000)

WINDOW.setProperty('arg2', sys.argv[2])
WINDOW.setProperty('arg1', sys.argv[1])

# firstrun is set by a service
firstrun=xbmcaddon.Addon('plugin.video.ThePlugin').getSetting('firstrun')
if firstrun=='True':
    xbmcaddon.Addon('plugin.video.ThePlugin').setSetting('firstrun', 'False')
    import threading, handler
    class Thread(threading.Thread):
        def __init__(self, target):
            self._target = target
            threading.Thread.__init__(self)
        def run(self):
            self._target()
    Thread(handler.handle()).start()

#wait for handler to signal that action is finished
while WINDOW.getProperty('finished')!=sys.argv[0]:
    xbmc.sleep(100)

WINDOW.setProperty('finished', '')

and this is handler.py:
Code:
import sys,xbmc,xbmcgui
import ThePlugin

WINDOW = xbmcgui.Window( 10000 )

#initialize the arguments
WINDOW.setProperty('arg1', '')
WINDOW.setProperty('arg2', '')

def handle():
    while (not xbmc.abortRequested):
        #did default.py send some command?
        arg1=WINDOW.getProperty('arg1')
        if arg1:
            arg2=WINDOW.getProperty('arg2')

            # fill in the arguments in sys.argv for ThePlugin
            sys.argv = [sys.argv[0], arg1, arg2]
            ThePlugin.main()
            
            WINDOW.setProperty('arg1', '')
            WINDOW.setProperty('arg2', '')
            #inform default.py that the handler is done
            WINDOW.setProperty('finished', sys.argv[0])
        else:
            xbmc.sleep(100)

There is one huge problem:
If the thread locks up you have to restart XBMC to get a new instance.

That and the ugly parameter passing with WINDOW.setProperty could be solved by saving a reference to the thread.
Reply
#51
I am interested in trying this but know little to nothing about code where and how do I add these lines?
Reply
#52
(2014-10-21, 17:57)DankNasty Wrote: I am interested in trying this but know little to nothing about code where and how do I add these lines?

I don't recommend putting this on a plugin you haven't written yourself.
Because the way it works there are a number of things that can go wrong in the plugin.

It's really just an experiment that needs further investigation and maybe I didn't think of something and it's total crap Rofl
Maybe someday XBMC will get modified internally to keep plugins running on the RaspberryPi, or maybe developers just need to start optimising their code.
Reply
#53
keeping stuff running and running is not the best idea for embedded devices with limited RAM and CPU I suppose - but I'm no dev
Reply
#54
Can someone explain what is going on here as I've found this by accident.
Applies to XBMC Gotham 13.2 versions - RPi, Ubuntu and OSX

All my movies are in seperate folders with corresponding metadata.

It seems if I set the following:

Set Content > Movies > Current Scraper > The Movie Database
Movies are in seperate folders that match the movie - select
all others settings - deselected.

I end up getting a very speedy scrape occuring - a lot faster than if I set:

Set Content > Movies > Current Scraper > Local information only.

This has surprised me as I thought a local scrape would be way way faster. ?

Anyone able to shed light on the difference ?

Reply
#55
(2014-10-25, 12:14)wrxtasy Wrote: I end up getting a very speedy scrape occuring - a lot faster than if I set:

Set Content > Movies > Current Scraper > Local information only.

This has surprised me as I thought a local scrape would be way way faster. ?

Anyone able to shed light on the difference ?

If it's not a Pi specific issue, then it's best to create a new thread in the "Kodo General Help and Support" forum where more devs will see.
Reply
#56
Yes .. but its not a problem, more an unexpected speedy surprise. I will repost however.

I suspect textures when local .nfo scraping has something to do with it.

Reply
#57
I feel like this whole thread was a lie. After reading over the thread I see lots of people blaming the addon programmers. But since the update to helix I have great news. Every single plugin programmers had got there act together and begun to program properly. As a matter of fact it is simply amazing because every plugin just runs so much faster.

I am being sarcastic. I just feel so horribly let down by the community because so much blame was put on the add-on developers and it seems to be unwarranted. I am probably hurt more then the average person by being a programmer myself.
Reply

Logout Mark Read Team Forum Stats Members Help
Video addon performance on Pi0