[da-anda]

I'm not sure I like the current integration concept for content provider add-ons. Feels a bit limited in usecase as it seems to be a all-or-nothing thing. IMO it'd be much nicer if content add-on API would focus on searching and combining aggregated search results. You won't browse 10k games by hand but you'd rather search for stuff or apply certain filters and then only add stuff to your library that you actually care for. Taking this further, one would not like to import ALL youtube videos, but only your own and maybe channels you follow, for the other millions of videos you'd only like to search for things. Same with music or picture (flickr) content add-ons. I know that you focus is currently primarily on games, but it doesn't hurt to think ahead.

[garbear]

Given that this is an add-on for a theoretically always-on internet service, perhaps it would make sense to trigger Heimdall any time trying to launch a game returns an error?

Though, that might not be a great idea, since a faulty internet connection could cause a total loss of your library.

Content is remembered when it disappears. It is marked as such, and doesn't appear in the library view anymore. When the source returns, the content re-appears in the library without needing a rescan.

To handle this, the database provides a "compress" function, which purges any orphaned content. However, content with user data (e.g. games with savestates) can optionally be kept.

[garbear]

Does this new content things works well for remotes (meaning browsing via webserver like vfs or things like that ?)

The contentdb:// protocol is just a thin VFS wrapper around the database. You can even perform direct mongodb-style queries via JSON:

Code:

contentdb://game/?q={ year: { $gt: 1990 } }

And unrelated but does the controllers of Retroplayer works from Event Server ? Meaning I can emulate a physical remote from a phone for example ?

controllers won't work through EventServer anymore. The Event Server API lacks support for "button up" events. The API will need to be expanded to support this, and ES clients will need to be modified to report button-up events.

[garbear]

I'm not sure I like the current integration concept for content provider add-ons. Feels a bit limited in usecase as it seems to be a all-or-nothing thing.

First of all, this isn't an all-or-nothing thing. I plan to implement two context buttons - "Add to library" and "Remove from library". These context buttons can appear on any local, remote or content add-on items.

We don't have to auto-scan. For example, let's say you add a folder to your music sources. The folder has 100,000 leafs. Initially, the library will be empty.

Let's say you select "Add to library" on this folder. The library will expand to 100,000 items. Then you enter that folder, and select "Remove from library" on a subfolder with 50,000 leafs. The library will shrink to 50,000 items.

You can then enter the removed subfolder, select "Add to library" on a sub-subfolder with 100 leafs, resulting in a library of size 50,100.

The same applies to content add-ons. In a theoretical Spotify add-on, you can add an artist. You can then exclude certain albums by that artist.

I think this should make it incredibly easy to build a library around the content you wish it to contain.

IMO it'd be much nicer if content add-on API would focus on searching and combining aggregated search results. You won't browse 10k games by hand but you'd rather search for stuff or apply certain filters and then only add stuff to your library that you actually care for. Taking this further, one would not like to import ALL youtube videos, but only your own and maybe channels you follow, for the other millions of videos you'd only like to search for things. Same with music or picture (flickr) content add-ons. I know that you focus is currently primarily on games, but it doesn't hurt to think ahead.

Aggregating search results isn't something I had planned on. My approach is to scan everything (or chosen subsets of everything) to the library, then make use of our rich mongodb-based JSON query syntax at the VFS level. For example, one of your game library XML nodes could have this as a path:

Code:

contentdb://game/?q={ year: { $gt: 1990 } }

Is aggregating search results something we'd like to have? How would this be implemented?

[topfs2]

In the background, a Heimdall service is started with the parameter content://content.game.internet.archive. It walks the VFS, deriving metadata and writing the metadata back to the VFS.

If the content on the Internet Archive changes, the content can be re-scanned by simply calling the Heimdall service again with content://content.game.internet.archive as the parameter.

This could be put on a timer, so every 24 hours the Heimdall service can be called. Or it can be called from a context item labeled "Scan to library".

So your using Heimdall in your concept right now, that makes me soooo happy you wouldn't believe Fun to see that it works

[da-anda]

I'm not sure I like the current integration concept for content provider add-ons. Feels a bit limited in usecase as it seems to be a all-or-nothing thing.

First of all, this isn't an all-or-nothing thing. I plan to implement two context buttons - "Add to library" and "Remove from library". These context buttons can appear on any local, remote or content add-on items.
...

ah sorry, then I missunderstood you screenshots above. I thought after you selected the content add-on it's immediatly imported.

IMO it'd be much nicer if content add-on API would focus on searching and combining aggregated search results. You won't browse 10k games by hand but you'd rather search for stuff or apply certain filters and then only add stuff to your library that you actually care for. Taking this further, one would not like to import ALL youtube videos, but only your own and maybe channels you follow, for the other millions of videos you'd only like to search for things. Same with music or picture (flickr) content add-ons. I know that you focus is currently primarily on games, but it doesn't hurt to think ahead.

Aggregating search results isn't something I had planned on. My approach is to scan everything (or chosen subsets of everything) to the library, then make use of our rich mongodb-based JSON query syntax at the VFS level. For example, one of your game library XML nodes could have this as a path:

Code:

contentdb://game/?q={ year: { $gt: 1990 } }

curly braces are not allowed in URLs, and I think our VFS paths should stay within that spec. Also, how does this work along with the DB abstraction? You plan on using the Mongo-DB syntax as abstract query language?

Is aggregating search results something we'd like to have? How would this be implemented?

Well, at least in my opinion it's something we should have had since ages, but I couldn't convince a experienced dev to work on it. It's a real shame that it requires an add-on to do a global search atm. Apple basically shows on their new AppleTV how it could work. The reason why I perfer this is that as user you don't have to know where stuff comes from in order to find it. Back to games as example. Let's say you have 3 content add-ons, one is the Internet Archive, one Steam, one Android apps and you feel like playing Sonic, which is not yet added to your library. Where would you start to search for it? As a pro-gamer you might know on which platforms Sonic was released so after a few mins of wild clicking you might have found the version you where looking for, but as a noob you'd be lost and spend way too much time finding the game. But if you could simply search for "Sonic" and get all hits back from all content add-ons, you're ready to play in seconds and might have even found out that there is a optimized Android or Steam version with improved graphics available to play. Same with TV shows. Assuming we would finally get native Prime and Netflix support and you'd like to watch the next episode of Sense-8 but don't remember if it was a Netflix, Amazon or Hulu exclusive show, who cares, you're ready to watch after a quick search.

The implementation could roughyl look like this:

• Search request started by user
  
• search manager forwards the request to each of the registered search providers
  
• there should be default search providers for the local library, to be extended by add-ons (either content add-ons or a new extension point)
  
• search providers return their results grouped by content type back to the search manager that aggregates them
  
• combined result is shown to the user and skins decide how which content type is rendered (poster, thumb, album cover, ...)
  

The search result presentation could be handled in different ways:

• when doing a global search, splitted up by object type (Movies, TV-Shows, Games, Artists, Albums, Pictures, ...)
  
• when doing a type specific search, like "movies"
  • a) show results grouped by provider ("my movies", "netflix", "hulu", ...)
    
  • b) combined search results, grouped by unique identifier (imdb ID f.e.), sorted by "relevance", where each search provider is adding a "relevance" property (exact match = 100, partial match = 50, ...). This mode is basically what AppleTV does, so when clicking on the search result you also see on which services it's available
    

The result view doesn't have to wait for all search providers to be finished. New results could be added to the list as they are found. And I know that this requires changes to our skinning engine and is not an easy thing to do. I wrote such a modular search a while back for a website, so I roughly know the workload required.

[garbear]

ah sorry, then I missunderstood you screenshots above. I thought after you selected the content add-on it's immediatly imported.

For the game library, I think auto-importing content add-on should be on by default (after all, except for search, importing content is the whole point of content add-ons). For a hypothetical Spotify content add-on, this imports your starred tracks and playlists, not the entire music world. The rest of the music world is discovered through search, and added to your library from there.

curly braces are not allowed in URLs, and I think our VFS paths should stay within that spec. Also, how does this work along with the DB abstraction? You plan on using the Mongo-DB syntax as abstract query language?

I spent an entire week evaluating NoSQL solutions, and EJDB is the only I decided to go with. No others (LevelDB, Tokyo cabinet/kyoto cabinet, UnQLite, MongoDB legacy c++ driver/new c++ driver) support the features we need and buildsystem integration for the platforms we build for

EJDB uses a mongodb syntax, so I'm just exposing it to the VFS

and o.f.c. queries would be url encoded

Code:

contentdb://game/?q=%7Byear%3A%7B%24gt%3A1990%7D%7D

The implementation could roughyl look like this:

• Search request started by user
  
• search manager forwards the request to each of the registered search providers
  
• there should be default search providers for the local library, to be extended by add-ons (either content add-ons or a new extension point)
  
• search providers return their results grouped by content type back to the search manager that aggregates them
  
• combined result is shown to the user and skins decide how which content type is rendered (poster, thumb, album cover, ...)
  

The search result presentation could be handled in different ways:

• when doing a global search, splitted up by object type (Movies, TV-Shows, Games, Artists, Albums, Pictures, ...)
  
• when doing a type specific search, like "movies"
  • a) show results grouped by provider ("my movies", "netflix", "hulu", ...)
    
  • b) combined search results, grouped by unique identifier (imdb ID f.e.), sorted by "relevance", where each search provider is adding a "relevance" property (exact match = 100, partial match = 50, ...). This mode is basically what AppleTV does, so when clicking on the search result you also see on which services it's available
    

The result view doesn't have to wait for all search providers to be finished. New results could be added to the list as they are found. And I know that this requires changes to our skinning engine and is not an easy thing to do. I wrote such a modular search a while back for a website, so I roughly know the workload required.

The implementation looks solid. I think the presentation would be difficult. Especially sorting by relevance. Most search providers won't provide relevance, which makes sense because they want you to use their service, not one that aggregates their results.

Back to games as example. Let's say you have 3 content add-ons, one is the Internet Archive, one Steam, one Android apps and you feel like playing Sonic, which is not yet added to your library. Where would you start to search for it?

If all three content add-ons were added to the library upon installation, then we could use local search without having to aggregate different results.

[da-anda]

auto-imporiting the entire VFS from content add-ons is IMO the worst thing we can do. I'm not opposed to auto-import in general, but it should be limited to things that make sense, like importing your music library from spotify or google music, your watchlist from netflix/amazon/youtube and stuff like that - but never ever the entire VFS. So add-ons should decide what should be imported from them automatically and what not - never Kodi. 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.
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. 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.

At least my vision for a new content related API for add-ons is primarily search capabilities and the possibility to add selected items to the library. With the search API we could show aggregated "recently added" or "trending" media accross add-ons and finally make Kodi itself more usable. The times are over that all media is available offline so browsing the local library is something that's barely done these days (maybe did it once this year while I'm almost daily watching Netflix). And browsing streaming services with millions of entries is also unlikely to be done - thus powerfull search and filter options are required IMO and become a main part of the Kodi UI and not be hidden in a side blade.
Also, the new API should it make easy to explore content, which means it would be good to define media type specific categories/tags that add-ons need to map their equivalents on. That way we can browse games from several add-ons in one go, depending on the category we're after. Like if I feel like playing Arcade stuff, I go into the Arcade category and get an aggregated overview. The main games window or even a category view could look like this:

• My games (aggregated via a search query)
  
• Most popular (aggregated via a search query)
  
• new games (aggregated via a search query)
  
• by category (list of categories defined by Kodi - could be extended by add-on categories that couldn't be mapped)
  
• by platform (platforms aggregated via a search query from add-ons)
  

Each of these items wouldn't be a dumb VFS item but rather a smart playlist and presented in a FireTV like way (or Netflix, Google TV, AppleTV, they all do basically the same).
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)

[garbear]

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.

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.

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.

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.

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?

[da-anda]

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.

With that logic it would be impossible to search for anything that's not imported to the local library which IMO would not be a wise thing to do, unless the search interface is handled via it's own extension point/VFS path

We just need a smarter texture cacher that can "forget" images to maintain a storage quota.

While I agree that we need a texture cache pruning, it still doesn't make sense to initially flood it by scraping 10k games.

What limitations does hierarchical browsing have? And why do add-ons offer a "next page" item instead of just showing everything?

Just compare Kodi to any other TV UI. Browsing lists is dead boring and not visually appealing. Also it takes much longer to find what you want when you first have to go into each node to see it's content - so the better way would be to have content previews of nodes (see my smartplaylist example), like all the other major players do. Yes, others primarily want to sell you stuff, but even without that aim it's still more pleasent to navigate as a user. Kodi does the same thing partly on the home screen in Confluence (recently added stuff), but that concept should be expanded to more areas, and the new games window would be a perfect start. In same way some sort of "app store" add-on/window could be created to give users a nicer interface to find and manage add-ons.
As for the "next page" - these are probably there because the add-ons scrape websites and the result is splitted on several pages. Some add-ons also do it to speed things up.

[garbear]

With that logic it would be impossible to search for anything that's not imported to the local library which IMO would not be a wise thing to do, unless the search interface is handled via it's own extension point/VFS path

The search interface is separate from the content:// vfs.

While I agree that we need a texture cache pruning, it still doesn't make sense to initially flood it by scraping 10k games.

What if Kodi loads artwork on demand? I think this already happens for plugin content.

Just compare Kodi to any other TV UI. Browsing lists is dead boring and not visually appealing. Also it takes much longer to find what you want when you first have to go into each node to see it's content - so the better way would be to have content previews of nodes (see my smartplaylist example), like all the other major players do. Yes, others primarily want to sell you stuff, but even without that aim it's still more pleasent to navigate as a user. Kodi does the same thing partly on the home screen in Confluence (recently added stuff), but that concept should be expanded to more areas, and the new games window would be a perfect start. In same way some sort of "app store" add-on/window could be created to give users a nicer interface to find and manage add-ons.

This is a good point. It falls out of the scope of the working pull request, but hopefully a nice, clean games window can serve as a clean slate for someone to implement this.

[da-anda]

Oh, I didn't mean that you have to do such a game window - I only wanted to point out what might be required to support by your API and what would be an ideal way of finding/browsing games.

I'm still not sure if your concept for the content API is working out though. You mentioned that anything in the content:// path will be auto-imported and that the API will support adding and removing nodes/leaves to the library. But what about search results? Search results might show items that are not exposed in the content:// vfs - how would these be added to the library? IMO ALL content should be exposed via content:// VFS and extensions need to support some "getImportableNodes()" method that's synced. That way the library import could always be handled via the content API.

[garbear]

IMO ALL content should be exposed via content:// VFS and extensions need to support some "getImportableNodes()" method that's synced.

The content:// VFS *is* the getImportableNodes() method. It's an API for importing nodes using the VFS as a transport

An API for search results is a good idea, and it's something I've worked with. The mythical spotify add-on uses the musicsearch:// protocol, for example.

The only problem is: I don't have an add-on that provides search, but I do have one that provides content If someone writes an add-on that provides search, I'll build search support into Kodi.

[ghallberg]

Oh garbear, please don't start talking about a spotify addon aswell, the suspense of waiting for the game tab is already killing me!

Keep being awesome!

[RockerC]

Oh garbear, please don't start talking about a spotify addon aswell, the suspense of waiting for the game tab is already killing me!

You should all try out the SpotyXBMC2 project if you like to experince how a concept like this could work with Spotify from an end-users point-of-view (and IMHO also how it should work).

Just checkout: read http://forum.kodi.tv/showthread.php?tid=105147 and then checkout http://forum.kodi.tv/showthread.php?tid=67012 for akezeke's proof-of-concept.

SpotyXBMC2 project has unfortunately been abandoned, but akezeke's code is still available here: https://github.com/akezeke/spotyxbmc2