[memeka]

For Android, the issue is with the python interpreter: http://forum.xbmc.org/showthread.php?tid=170883

[realtebo]

My code is

Code:

import urllib2
import json
import jw_config

def loadUrl (url):
    response = jw_config.cache( urllib2.urlopen, url) )
    html = response.read()
    return html

When jw_config.cache is defined as

Code:

try:
    import StorageServer
except:
    import storageserverdummy as StorageServer

The problem is that the line

Code:

jw_config.cache( urllib2.urlopen, url) )

throw a syntax error, but I don't understand ... why ?

[realtebo]

Yet resolved !

Code:

import urllib2
import jw_config

def loadNotCachedUrl(url):
    response = urllib2.urlopen (url)
    html = response.read()
    return html        

def loadUrl (url):
    html = jw_config.cache.cacheFunction(loadNotCachedUrl, url)
    return html

[shlomicthailand]

hey guys

started using your plugin - really save time , but i struggle with cleaning the whole cache at once for the addon , instead of wildcards delete the keys.
i want to wipe the whole table

looked inside the code and saw cacheClean(empty) - but it does nothing , more accurate it tries to look for a key name
"cache" + self.table which will never exist.

what am i missing here ?

thanks

Shlomi

[realtebo]

I'm doing this

Code:

cache = StorageServer.StorageServer("plugin://plugin.video.jworg/", 24)
cache.delete("%");

And this works

[shlomicthailand]

I'm doing this

Code:

cache = StorageServer.StorageServer("plugin://plugin.video.jworg/", 24)
cache.delete("%");

And this works

thanks

[realtebo]

In the Wiki you suggest to use a row like this

Code:

<import addon="script.common.plugin.cache" version="0.9.1"/>

I copy/pasterd into plugin.video.jworg and all is working very well, but actual version is 2.5.2

Can I update this version requirement to 2.5.2 ?
Can I safely leave this requirement to 0.9.1 because xbmc always use the latest available?

[ghostwhowalks]

Why does XBMC need an addon for this? XBMC already keeps a cache file for each directory's file items (in the cache folder with file extension *.fi), only they are deleted when a directory is reloaded (seen in the log as DEBUG: 'Clearing cached fileitems'). If you mark a cache file as ready-only it can't be deleted and the corresponding directory can be loaded from it almost instantly. Accessing directories through favorites also avoids deleting the cache file and is similarly fast. If XBMC retained these cache files would there still be any benefit in using this common plugin cache?

Unlike XBMC's cache which loads directories very quickly when it works, I haven't been able to get any apparent performance benefit out of this common plugin cache on Windows or RPi (logs are error free and look good). What kind of benefit is expected?

When commoncache.db is created for the first time, accessing youtube listings takes 10+ seconds while normally for me it takes 4 seconds. After restarting XBMC the problem goes away and listings are shown in 4 seconds like before. In the log the additional 6+ seconds is spent doing '_sqlGet' for each list item, after restarting these are all done in under a second.

[shlomicthailand]

i can say for sure that common cache plugin helped with my addon on RPI tramendesly

[ghostwhowalks]

What OS are you using? Is your addon publicly available? I'm using a clean install of Openelec 3.2.4 for RPi, the Youtube addon using the common plugin cache takes 20+ seconds to show a listing and the same for reshowing. The Dailymotion addon does not use the common plugin cache and takes 5 seconds to show and reshow a listing.

[shlomicthailand]

i wrote i use RPI - my addon means that i develop the addon,

don't know about the timings you wrote , just noted that with the addition of it , our users reported faster load times.

[Eldorado]

What OS are you using? Is your addon publicly available? I'm using a clean install of Openelec 3.2.4 for RPi, the Youtube addon using the common plugin cache takes 20+ seconds to show a listing and the same for reshowing. The Dailymotion addon does not use the common plugin cache and takes 5 seconds to show and reshow a listing.

Not really a fair test, 2 completely different addons based off different sites

Also you guys should read up on exactly how this module is used, it's not a cache per se, but gives a easy to use database to store items for re-use, such as saving a list of favourites, makes the life of the addon dev much easier

[ghostwhowalks]

Thanks for your input Eldorado. The comparison is not entirely fair but the Youtube addon is mature and important so I expected it to be using the cache to its full potential. The cache is advertised for speeding up listings:

The cache greatly cuts down on the time it take to reshow a listing after playback has finished, or just on directory change.

http://forum.xbmc.org/showthread.php?tid...#pid955618

This makes sense given the way it works (function return results remembered for later) but I'm not seeing any speed improvement at all. I tried one of your addons which uses the common plugin cache, Project****. I uninstalled the cache and as expected I lost the ability to store favorites but the listing reshow speed is unchanged. By the way the cache doesn't seem like a reliable place for storing favorites for any length of time.

I also tried ***Film which has its own method of saving favorites, so disabling the cache still allows favorites to work, also no speed difference.

The Twit addon doesn't work at all without the cache, it caches the tv show and episode lists, presumable to make them faster. On the RPi it takes 20+ seconds just to move between listings, similar to the Youtube addon. I'm noticing a pattern that addons making use of the cache are running dramatically slower than those that don't on my RPi.

The Youtube and Vimeo addons work without the cache, no obvious loss of functionality, no speed difference. Both very slow addons.

I also overclocked my RPi and noticed there was no speed improvement for the Youtube addon, the cache may be bottlnecking the RPi in some way. The XBMC list cache does not have this problem.

This very slow cache access could be in connection with the bug I experienced on Windows that made a newly made commoncache.db slow until I restarted XBMC, but with RPi restarting doesn't help.

[Eldorado]

You have to know how the cache is being used, for my addons (don't mention the names here) I only use them where I needed to save information for the user, ie favourites, search history etc.

Neither of them are using it to cache previous pages, so you won't notice any speed changes

But in instances where the addon is using the cache to save a page then it will be faster, it's obviously faster to pull from a local database then to re-request the page from the internet.. but you are right concerning rpi, there is a bit bottleneck reading/writing to the sdcard.. only things you can do to help that is using a very fast sd card and/or using a usb memory stick

And like I said, the addon has to have been programmed with this functionality, doing straight blind tests won't prove much unless you confirm that it is caching pages

[moreginger]

I'm trying to Pickle something to the common plugin cache and I get:

Code:

File "/home/ZZZZ/.xbmc/addons/script.common.plugin.cache/lib/StorageServer.py", line 416, in _sqlSet
self._log(u"Update : " + data, 3)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)

Looks like someone else reported an issue like this a few days ago too (http://forum.xbmc.org/showthread.php?tid=181395) - coincidence or has something changed recently?