(2021-02-11, 16:44)docwra Wrote: Nope no progress. Need a Kodi Database table first!

I personally don't see whats wrong with another simple Sqlite db, similar to how TvShows works, but the developers were talking about refactoring the entire system at one point at which I lost interest

(2021-03-18, 09:33)Wintermute0110 Wrote:

(2021-02-11, 16:44)docwra Wrote: Nope no progress. Need a Kodi Database table first!

I personally don't see whats wrong with another simple Sqlite db, similar to how TvShows works, but the developers were talking about refactoring the entire system at one point at which I lost interest

Designing the Kodi Games database it is not that simple. Currently I am writing a document with a design candidate which I will publish when finished for feedback.

(2021-03-19, 14:04)docwra Wrote: Fantastic work!

I still don't see why an entirely new database technology layer is needed though. All that should fit nicely into the current Kodi SQlite structure and scraping systems.

I know @garbear has spoken about redesigning the whole thing but I still don't understand why its needed. Sure ORM systems and modern databases are great, but Sqlite also has its advantages of ease of use, speed and easy editing tools. Why not copy the code from the the music or TV show database and work with the same scraping systems?

I'll write a metadata games DB (or use the many that are already available), job done

Sounds easy hehe (I know its not).

(2021-03-21, 07:56)Wintermute0110 Wrote:

(2021-03-19, 14:04)docwra Wrote: Fantastic work!

I still don't see why an entirely new database technology layer is needed though. All that should fit nicely into the current Kodi SQlite structure and scraping systems.

I know @garbear has spoken about redesigning the whole thing but I still don't understand why its needed. Sure ORM systems and modern databases are great, but Sqlite also has its advantages of ease of use, speed and easy editing tools. Why not copy the code from the the music or TV show database and work with the same scraping systems?

I'll write a metadata games DB (or use the many that are already available), job done

Sounds easy hehe (I know its not).

I am not aware of current @garbear plans. My idea is to take the music database and start from there. The database backend will be SQlite. The document does not focus on the low level (use SQlite or a custom no-SQL solution using JSON, etc.) but rather on a high level. For example, in the music DB you have a set of songs that form an album. Albums have an artist. You may want to browse you albums but also browse your artists and show your albums, etc. Compared to music the games case is more complex. Console system usually have a single ROM file. However, arcade systems have a ZIP file with many ROMs inside. Optical media use ISO or CHD files. There are some tricky platforms where games are inside a directory, etc. Some games consists of several disks and many users would like to see them unified and at launching time you select the disk you want to launch. Another big difference is than in he music DB usually all your files are in a single Kodi source. However, in the case of games I think is much better to have one source per-platform and create a new source property named platform. This has implications on the way you organize your ROMs and artwork in your disk.

The games database should accommodate all these cases. It is impossible to make everybody happy, there will be decisions that will be inconvenient for some people. The target is to make an elegant solution, simple and easy to use for most users. As I said, it is not as easy as it sounds!

(2021-03-18, 09:33)Wintermute0110 Wrote: Designing the Kodi Games database it is not that simple. Currently I am writing a document with a design candidate which I will publish when finished for feedback.

(2021-03-19, 14:04)docwra Wrote: I personally don't see whats wrong with another simple Sqlite db, similar to how TvShows works, but the developers were talking about refactoring the entire system at one point at which I lost interest

(2021-03-21, 07:56)Wintermute0110 Wrote: My idea is to take the music database and start from there. The database backend will be SQlite.

(2021-03-24, 17:42)RockerC Wrote:

(2021-03-19, 14:04)docwra Wrote: I personally don't see whats wrong with another simple Sqlite db, similar to how TvShows works, but the developers were talking about refactoring the entire system at one point at which I lost interest

(2021-03-21, 07:56)Wintermute0110 Wrote: My idea is to take the music database and start from there. The database backend will be SQlite.

Looking historically at all those other linked threads that mostly discuss huge databases refactor attempts for Kodi, so please be aware that it could be a risk that Kodi's core developers will not accept large changes this time either if a PR is asking for too many changes to be done to the database schema, especially if any significant changes affect the other databases/libraries in Kodi.

Still, I will be crossing my fingers and wishing for the best possible outcome, as at this point, I think that any native games database making it into Kodi would be better than no native games database in Kodi.

Personally, I had hoped before that someone would first just create a very simple and basic native games database that would quickly get approved for merging directly into Kodi 'as-is' and then later once that native games database is in there that could later be extended and improved. This as it is usually harder to say no to continuous smaller changes with minor enhancements and imporovements.

• GOG.com (formerly Good Old Games)
  
• Stream
  
• Epic Games Store
  
• GeForce NOW (Nvidia Cloud Gaming Service)
  

(2021-03-18, 09:33)Wintermute0110 Wrote: Designing the Kodi Games database it is not that simple. Currently I am writing a document with a design candidate which I will publish when finished for feedback.

(2021-05-27, 14:49)RockerC Wrote:

(2021-03-18, 09:33)Wintermute0110 Wrote: Designing the Kodi Games database it is not that simple. Currently I am writing a document with a design candidate which I will publish when finished for feedback.

@garbear @NikosSiak @a1rwulf @lrusak @velocity Do you guys who develop Kodi's Game API and RetroPlayer have any feedback to share about a native Games Database and Gaming Library in Kodi?

(2021-03-18, 09:33)Wintermute0110 Wrote: Designing the Kodi Games database it is not that simple. Currently I am writing a document with a design candidate which I will publish when finished for feedback.

(2021-03-21, 07:56)Wintermute0110 Wrote: I am not aware of current @garbear plans. My idea is to take the music database and start from there. The database backend will be SQlite. The document does not focus on the low level (use SQlite or a custom no-SQL solution using JSON, etc.) but rather on a high level.

(2022-01-05, 23:24)chrisism Wrote: What is different from AEL?
Not much actually. This is a friendly-ish fork of the original AEL version. I already was helping out and adding features to AEL, but with too many different features and alternative solutions we like to make it a bit more clear and make sure both versions can be stable. The main goal of AKL was to separate the launching, scanning and scraping logic to separate plugins so that it is more open to add more of these components to the addon, with an extra benefit that it is easier to maintain the core addon without doing major releases and changes. So as a result AKL can support more and different types of launchers, scanners and scrapers.
Another benefit is that instead of having a launcher as the center entity, we now use collections of ROMs/games to build everything around. This means we can associate multiple launchers to whole collections and multiple scanners per collections, so you basically get multi-directory support. So not launcher based collections, but simply collections with multiple launchers, scanners and scrapers.

The goal still remains that the functionality and data will be as closely related and interchangeable as possible with AEL.
Meaning you can import and export your data from and to AEL if needed. I will keep on working together with @Wintermute0110 on AEL and AKL and let both addons benefit from new things we add or discover. Most of the things discussed or mentioned in the AEL thread will also apply for AKL.

A special thanks to @Wintermute0110 making AEL possible.