(2015-09-16, 17:29)da-anda Wrote: So add-ons should decide what should be imported from them automatically and what not - never Kodi.
Add-ons do decide what should be imported. Kodi just makes it simple - if it should be imported, make it a leaf on the content:// VFS. Otherwise, omit it from the VFS. This means that spotify and google only provide your music library. Netflix/amazon/youtube only provide your watchlist.
The content:// VFS doesn't span the entire domain of content; only what makes sense to be in your library.
(2015-09-16, 17:29)da-anda Wrote: Add-ons are free to create local caches to speed things up though - but these caches should not be part of the main data storage of Kodi.
Optimal caching requires domain knowledge of the stuff being cached. Therefore, I expect add-ons to manage their caches. xbmcswift2 makes this easy, as I have discovered.
Basic metadata caching could also be implemented in Kodi if the add-on provides a "time-to-live" property.
(2015-09-16, 17:29)da-anda Wrote: I'm not sure if you ever tried to import a music library with ~10-20k songs while having the download of additional artist info enabled - this is taking ages. On my PI2 it took like 1 day or more and even on my workstation it's taking hours. And assuming heimdall is adding a simmilar load like fetching artist info, this is a veeeeery bad user experience.
Heimdall has amazing potential. It operates on first-order logic, which has clear, defined data dependencies and thus can be massively parallelized.
Let's say you have two games. And three rules:
Code:
1. If X is a game, a CRC and Platform can be calculated for X.
2. If X has a CRC, the Title and Fanart URL can be found at <insert game web database>
3. If X has a fanart URL, then download and cache the image
Rule 1 might take 15ms for a large CRC. Rule 2 might take 1.5 seconds for a web request. Rule 3 might take 15 seconds for a high-definition image download.
However, game X is independent from game Y. Heimdall's scheduler could exploit this knowledge and execute the rules in this order:
Code:
If X is a game, a CRC and Platform can be calculated for X.
If Y is a game, a CRC and Platform can be calculated for Y.
If X has a CRC, the Title and Fanart URL can be found at <insert game web database>
If Y has a CRC, the Title and Fanart URL can be found at <insert game web database>
If X has a fanart URL, then download and cache the image
If Y has a fanart URL, then download and cache the image
You now have a basic game library in 2*15ms, a detailed game library in 2*1.5s, and a fanart-populated game library in 2*15s.
(2015-09-16, 17:29)da-anda Wrote: Next is that the local storage is flood with artwork of games that the user might never play. Limited storage is an issue on low power platforms like the PI and many Android boxes, so it should not be wasted.
We just need a smarter texture cacher that can "forget" images to maintain a storage quota.
(2015-09-16, 17:29)da-anda Wrote: So the worst thing we can do is to stick with the VFS for presenting content. It's nice to browse hierarchical stuff in add-ons, but it also has way too many limitations for that and offers a bad user experience (like the "next page" VFS entries that need to be hacked in by add-on authors etc)
What limitations does hierarchical browsing have? And why do add-ons offer a "next page" item instead of just showing everything?