Please do not post a support request without first reading and following the advice in

Metadata Improvements in EmulationStation

  • @fieldofcows Thank you for your considered response! I will mull it over while trying to sleep.
    I am glad you are taking this so very professional, even when it's your hobby!

    Lets get back to this when we are both fresh and less fuzzy.

  • @fieldofcows just throwing it out there as I thought of it: how likely is a "related games" filter?

    Eg: on the Detailed View would it be possible to have a list of other games that share a number of tags/filters/whatever?

    On further thinking, it probably wouldn't work with the way things work now, but I just wanted to mention it.

  • @mattrixk That's a really good idea. Technically it's easily possible but I don't know how well it would fit in the UI.

  • @fieldofcows yeah, it was the UI implementation that I wasn't sure about. I was originally thinking of a second gamelist, but how do you access it? If up/down travels the main gamelist and left/right changes system, how do you move over to the "related" gamelist? Without menu intervention at least.

    Interesting in theory, but I don't know how it would work in practice.

  • I just wanted to add that for those of us with large collections, folder structure is vitally important. Also, @Zigurana, yes performance is still very much an issue. I've got about 63,000 ROMS in my collection currently, and startup time on my stock-clocked Rpi3 is roughly 8 minutes using the most recent "official" (v2.1.0RP) version of EmulationStation. ES is also not saving metadata, and although I haven't fully tracked down the issue yet, I believe the collection size is playing a factor (yes, I've checked all the easy settings/configs already, but let's not derail this topic for this particular problem).

    Also, @fieldofcows, you said you are not a database engineer; I've done some database design professionally and would be happy to help with this project. I sent you an email with further information a few days ago. I've been thinking about this for the last few days, and have some ideas that will allow people to use their existing folder structures (i.e. grouped by system type), but also to easily save/add new filter types and search queries for the main system select screen (i.e. "Classic Platformers" or "Mario Collection" or "Favorites" or whatever). Furthermore, I have some ideas that will allow for each of these filter types to (relatively easily) have their own custom themes.

    @mattrixk and @Nismo have both been doing some great theme work and have expressed interest in recent posts with having things like video previews, fan-art backgrounds (made easier now to thanks to the UXS scraper by @screech), etc. It looks like @sselph is updating his scraper and looking towards better ES integration now as well.

    I've also read posts from other users who would like to see additional artwork, and this could all be easily referenced by the new database system, and displaying it should be pretty easy too, although I'm not familiar with the guts of the current ES codebase. This could also give us the ability to do more advanced things like dynamically rotating and scaling artwork while scrolling through games, for example, which would give theme designers a much more powerful toolset to work with, without a large development burden.

    From a user's perspective, I love what you've already done and am very excited to see where this goes. From a developer's perspective, I'm willing to provide some assistance with implementing these features.

  • Hi @MWGemini. Thank you very much for your post. I was beginning to wonder about the value of the metadata update I'm working on because it is taking quite a lot of my limited spare time but you have just made it all worthwhile.

    I had a bit of a problem with spam email over the last couple of day - I think some scraper has used my email address to send a load of spam and I got ~500 failed delivery reports so I just bulk deleted it all so I would appreciate it if you could resend your email. Thanks.

    What I have is a little bit away from working but I think the data structure now allows three different (at least) types of grouping:

    • Folder structure from a relative root directory (so the path for a game is stored as "dir1/dir2/" for example)
    • Tags - just a text field. Any number of tags can be specified per game
    • Metadata - this is just a list of tag/value pairs. Like tags above, there can be any number of these per game

    I have a C++ class named GameData that manages the game list and metadata. In order to query the database you just ask for the game list and specify the filter. At this stage the results are queried from the database and populated in memory. They are populated either as a flat gamelist or maintaining the folder hierarchy where equivalent relative paths in different systems are grouped together.

    It all seems to make sense to me at the moment. The code is a bit scruffy and incomplete and the version of ES built on my codebase doesn't work properly at the moment but if you want to examine the code then you can take a look at Most of the code for the game data is in the es-gamedata subdirectory.

  • @fieldofcows I've just re-sent the email, and I'll try to set aside some time to look through your recent code changes and try to put my database design ideas into a diagram to send to you.

  • @MWGemini Got your email, thanks. I'll have a good read and get back to you. Thanks!

  • @Zigurana: You asked for it, here it is.
    @fieldofcows: This is for you.
    @MWGemini: You might be interested in this too.

    I made a design proposal doc with Google Docs, full of ideas about how I think we could make metadata and filtering work a lot better in ES.

    It's still a WIP and kind of trails off towards the end, but I'll keep working on it, and people are welcome to leave comments (and if it's wanted, I can open it up to editing).

  • @mattrixk I also wrote up a design document, and it looks like we've got many of the same ideas. If you and @Zigurana want me to share it with you, send me your email (I can't seem to find a private message option on here... am I blind?). I'd love to get input from theme designers, since my document is focused more on the technical details and usability issues. I'd like to get it polished quite a bit more before sharing it with the rest of the community, but am happy to share it with other interested parties (particularly scraper developers such as @sselph and @screech).

  • @MWGemini nope, not blind. No message option (I think Buzz turned it off to discourage rom sharing). If love to see your document and give some input.

    My doc is currently set to read/comment only, but I can add you, @Zigurana and @fieldofcows as editors. I think @Nismo might even want in on this.

    Edit: removed email address.

  • @mattrixk Just sent you the doc. You might want to remove your email from your post to prevent spam :). I also made a few comments on your doc. I agree with basically everything you wrote, with the exception of database versus XML. Currently, gamelists are stored in XML and I (and @fieldofcows too, I think) want to replace that with a SQL database. It's a big undertaking, but it'll give us a lot more power as users and for you as a theme designer. Functionality wise, I think we're pretty much on the same page.

  • @MWGemini I'm happy to read it over. My email address is on my github page.

  • @sselph Just shared it with you as well :).

  • @MWGemini said in Metadata Improvements in EmulationStation:

    Currently, gamelists are stored in XML and I ... want to replace that with a SQL database.

    I don't really have much of a stake in the XML vs DB argument. I'm happy to go with whatever is suggested by the people who know what they are talking about. From what I've gathered, XML is lot easier to edit/add info than a database, but the DB allows faster loading/categorisation of info? Would using DB change how themes are made? Would they still be made in XML?

    I was thinking if we went ahead with all of the extra filters/tags and metadata, that we would possibly need some kind of separate program to handle it all, be it web-based or desktop based. I know amadeus has his Retropie Metadata Editor for Windows. I haven't had the chance to look into it, but maybe something like that would be of use.

  • @mattrixk Two questions there. First, the XML vs DB argument applies only to the game lists. Themes would still be in XML. XML is more human readable, yes, but for doing large and advanced edits, it's really not ideal or easy. From a performance standpoint and from a feature standpoint, a database is the best option for storing data about the games. Themes will continue to work as they currently do.

    As for making a separate program to actually create and edit themes, I think that is a great idea, and probably would not be very difficult. That would allow theme designers to visually create and edit themes (or at least see a preview of what the changes would look like), without needing to keep copying it to the Pi and reloading it.

    The bigger question is what information do we want to store in the database and make accessible to users, theme designers, etc. I tend to lean in the direction of more data is better, and let individual theme designers and users decide what subset of that data they want to use.

  • That would allow theme designers to visually create and edit themes (or at least see a preview of what the changes would look like), without needing to keep copying it to the Pi and reloading it.

    Yes, all of my yes.

  • @MWGemini said in Metadata Improvements in EmulationStation:

    As for making a separate program to actually create and edit themes, I think that is a great idea, and probably would not be very difficult. That would allow theme designers to visually create and edit themes (or at least see a preview of what the changes would look like), without needing to keep copying it to the Pi and reloading it.

    I use a portable Windows version of ES that @herb_fargus created a while ago. It works great, but as it's only ES, not RetroPie, and doesn't keep up to date with updates, it's not much use for testing out newer stuff like Video Preview or Grid View.

    I've had RetroPie set up on Ubuntu within a virtual machine, but it was so awkward to do anything, took up way too much space (having to set up an entire operating system for a single program is very inefficient) and I just simply dislike Ubuntu (a lot. I had to use it for work for almost a year).

    If someone wants to make a hassle-free version of RetroPie that runs on windows (without me having to compile and all that stuff I don't understand) the same way that Herb's portable ES does, then that would be awesome.

    I forgot to say: when I was talking about a program, I meant one that we can use to sort out the metadata and filters, not for theme making, however like I said above, if anyone wants to make a simple portable Windows RetroPie, it would be awesome

  • administrators

    @mattrixk no such thing. Retropie is Linux, windows is windows. You can hack a few batch scripts together to try and replicate it but would be a monumental task and still won't work the same. Would be simpler to just run a live USB with Ubuntu or to dualboot your pc

    Closest you could get is libretro emulators and maybe a Windows compilation of the retropie ES but won't have runcommand etc

  • @mattrixk Yes , like @herb_fargus said, a portable retropie for windows it's impossible, but I compiled the latest ES build for windows without too much problems.

    Emulationstation is portable itself.

    I actually don't have retropie or rpi, I do all my work on windows, but I deleted the latest build, and go back to old fieldofcows fork because has more stuff like nosplashscreen and other things.

    Of course i'll try to build the latest ES for windows with all the new metadata improvements and all the new stuff (when released), so I can upload a compiled version for themers or people that want to test without sacrifice their rpi builds.

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.