slow startup esp with lots of skin widgets due to addon menu's caching removed on startup

Bug report

Describe the bug

When starting kodi, any addon menus that were cached to disc (via the cacheToDisc=True param in the addon), are not used on startup. This leads to the user having to wait a long time if they have skin with many widgets which point to addon menus. This is particularly bad with a lot of widgets and on a lower end machine that can't handle so many python instances all loading at the same time (1 per widget).

It also seems like json-rpc calls used by widgets don't cache at all which is unexpected.

Expected Behavior

Kodi should startup fast with content quickly displayed in all widgets even if out of date , letting the user choose to wait for more updates or use the widgets as is.

Actual Behavior

Kodi calls all the addons menu at the same time no matter how many of them there are and doesn't matter if there is a cached menu on disk or how old it is. This can leave a page of widgets with spinning waiting indicators for many a long period, in some cases over a minute.

If there is limited memory, then this can often lead to crashing or memory managers killing the process due to too many addons loading at once

Possible Fix

Kodi should use the cached menu, regardless of how old initially so startup is fast. and then queue the actual call to the addon menu and refresh the widget once the menu has been cached again, thus limited the number of addons running simultaneously and letting the user browse some content even if its stale. Many lists don't change that often so in many cases the list would be unchanged.

To Reproduce

Steps to reproduce the behavior:

Pick a skin with widgets
Pick a plugin that allows caching it's menus
Add widgets that point to the addon menus
Open once and let the wdigets load
Restart then notice the delay before the widgets are loaded.

Debuglog

not applicable

Screenshots

Here are some links or screenshots to help explain the problem:

not applicable

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:

None

Your Environment

Used Operating system:

@djay please provide all information requested by the issue template, esp. debug log and exact Kodi version! As of now we do not even know which Kodi version you are talking about.

@ksooo fixed

No debug log?

I can do better than a log. Here is a plugin that does a hack to get round this bug

https://github.com/nkestrel/kodi.service.plugin.listcachekeeper

On startup and when displaying cached lists, the log will show errors as Kodi tries and fails to delete the protected cache files

As you can see kodi is cleaning these cache files in startup, preventing kodi from a fast startup.

and here is the code that clears these cached lists out on startup

xbmc/xbmc/settings/SettingsComponent.cpp

Line 394 in 49ba279

    
           auto archiveCachePath = CSpecialProtocol::TranslatePath("special://temp/archive_cache/");

actually I've noticed that some skin widgets do not end up creating cache files on disk when set to a addons directory. Only when you go to the addon manually is the cache file created. So to fix this problem additional changes would be needed by skin widgets to generate those cache's and use them, as well as the caches not being wiped on startup. This would then result in the desired fast startup.

Not that sure on the code but I think what needs to be changed to use a cache is

xbmc/xbmc/interfaces/json-rpc/FileOperations.cpp

Line 72 in a9076fe

    
           JSONRPC_STATUS CFileOperations::GetDirectory(const std::string &method, ITransportLayer *transport, IClient *client, const CVariant &parameterObject, CVariant &result)

I think the main part of the code does the caching for viewing the addons is

xbmc/xbmc/windows/GUIMediaWindow.cpp

Line 730 in a9076fe

    
           bool CGUIMediaWindow::GetDirectory(const std::string &strDirectory, CFileItemList &items)

@jmarshallnz what do you think of the idea of caching lists from plugins to disc in json-rpc if they are slow? perhaps with an extra flag if you want to ensure its fresh?