Implement caching framework

[dagwieers]

This PR includes:

• Caching and fallback framework for listings (e.g. A-Z, or categories)
• New troubleshooting option to invalidate caches

This fixes #241

[dagwieers]

I would also like to add Recent/Offline caching as well. But the filtered content (My Recent/My Offline) needs special invalidation when things are followed/unfollowed.

Please test. I flagged it experimental for now.

[mediaminister]

Does this speed up menu browsing? Didn't notice a difference with the master branch.

[dagwieers]

It depends.

On Android I don't see a lot of improvements, except if I disable this caching some lookups are from time to time slower. (Likely network interruptions)

On Raspberry Pi the difference is bigger. What caching brings you is a more predictable load-time, but it definitely depends on the speed of the SD card, or whether it is still buffered in file system buffers. I noticed that even when things are cached, the JSON processing is the biggest culprit now.

And maybe in some cases getting it from the network may be faster than reading it from SD card. In this case you'd better replaced that SD card (I have had a LibreELEC that was quite slow due to the SD card wearing out).

Also, we have some use-cases where the same file is being loaded multiple times (e.g. tvguide if you first look what's on Eén, and then on Canvas it would be downloaded twice, or live tv, where it would get the EPG information 3 times when building the menu)

I will probably make a distinction between optional caching and mandatory caching. E.g. for categories if you would disable caching it will also not fall back to the categories cache, so for categories and the tvguide I would probably keep a separate option (or enable it always).

[dagwieers]

@mediaminister Beware that for testing you always have to quit the addon, start another addon, and then go back to the addon. This is needed to ensure the new code has been loaded, since we enable uselanguageinvoker that's no longer a guarantee.

[dagwieers]

Just to indicate that the menu speeds on Raspberry Pi is bound to the JSON/menu processing, enable caching and go to the Categories menu. Then open and re-open the Kinderen-category (slow, 54 items) and the Koken-category (instant, 2 items).

We do caching for categories and channel listings as well. I wasn't planning to, but doing that change was pretty easy anyway and the results are even more visible (as the network is a larger part of the total load-time).

That is the reason why you don't notice e.g. the A-Z listing being a big speed up (something I expected). The cheer number of menu items slows everything down on Raspberry Pi.

(Slow here is quite relative, it's still close to a second here !)

[dagwieers]

Recent and Offline is not being cached now, which I intend to do too.

[dagwieers]

BTW I also intend to add a setting to disable fanart/thumbnails, as this may also play a part in slowing down menu listings (indirectly). Plus it helps me understand disk-access and network-access better (now this activity makes things less transparent).

[dagwieers]

For offline and recent caching the differences (on Raspberry Pi) are also quite visible.
I only need to add a means for invalidating the filtered (My favorites) lists whenever programs are followed/unfollowed. But that's not that difficult now.

[mediaminister]

Looks good to me. I tested and it didn't crash.

[pietje666]

Looks good i like that it is something enabled by a setting, btw why don't you use a mocking framework instead of writing your own mocks?

[dagwieers]

Why don't you use a mocking framework instead of writing your own mocks?

Well, if you look at what we did before, it was a kludge. And when I tried to improve it using Mock things were a lot harder then just writing proper modules for it. Also, mocking a library wasn't that easy and my aim was to import kodiwrapper as-is.

The xbmc libraries are not feature-complete, which is fine. If we ever add functionality we either need to add a stub, or add an alternative implementation.

PS This also opens up the possibility to run addon.py directly to achieve a higher coverage.

[dagwieers]

So currently this is disabled by default, but I think we ought to enable this. If we ship this disabled, all our existing users will have it disabled. So if we enable it by default later, they will keep on having it disabled. What do you guys think ?

The TTL is 7 days for categories.json (with a fallback forever). The TTL for other files is 1 hour. And only for favorites.json we also use it as fallback forever. (This in case the favorites system would stop working, it would continue working locally, although updates would not be pushed :-/)

[dagwieers]

Feedback welcome. In the meantime I'll merge it.

[mediaminister]

I agree that we enable this by default, but before a release this feature must be thoroughly tested.