Summary of Changes

Hello @zeroSteiner, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request implements a crucial enhancement for game organization by enabling the grouping of game files that share the same base name but differ by revision tags. By leveraging a new fs_name_no_tags field and updating the sibling_roms database view, the system can now intelligently identify and present these variations as different versions of a single game, significantly improving the clarity and usability of the game library, especially within the platform view.

Highlights

• Database Schema Update: A new Alembic migration script (0068_sibling_roms_fs_name.py) has been added to introduce an index on the fs_name_no_tags column in the roms table and update the sibling_roms SQL view.
• Game Grouping Logic Enhancement: The sibling_roms view now includes fs_name_no_tags as an additional criterion for identifying and grouping related ROMs, allowing games with the same base name but different tags to be treated as versions of the same title.
• Backend Handler Integration: The roms_handler.py file has been updated to incorporate fs_name_no_tags into the filtering and metadata ID creation logic, ensuring that the new grouping mechanism is utilized in the application's backend.
• Model Index Definition: The Rom model in rom.py now explicitly defines an index for fs_name_no_tags, aligning with the database migration and improving query performance for this field.

@gantoine Any chance we consider this to be some kind of opt-in toggle instead of default logic? There are plenty of instances where two (or more) official game releases have the same name on a platform but they are not the same game. With this current behavior, unique games get grouped together based purely on their file name even if they have unique metadata IDs.

Any chance we consider this to be some kind of opt-in toggle instead of default logic

Not possible due to technical contraints (virtual tables). It comes down to what's more common: different games with same name on the same platform, or bad/missing metadata sources?

Any chance we consider this to be some kind of opt-in toggle instead of default logic

Not possible due to technical contraints (virtual tables). It comes down to what's more common: different games with same name on the same platform, or bad/missing metadata sources?

Hrm, fair enough. The latter is almost certainly more common, but is fixable by community effort of updating the metadata provider(s). The former isn't changing ever however.

I don't think this commit really considered this scenario at all to be fair, it's purpose was just to group what in theory should be the same game (i.e. regional variations) via fuzzy logic. I don't have an answer to this right now, but maybe the better solution would be finding an alternative non-fuzzy way to accomplish what this PR set out to do?

P.S. My opinion is that the non-fuzzy way is what we already do currently however. If the game has the same metadata ID, it gets grouped.

For my purpose, it's a lot of ROM hacks and games from itch which have multiple versions that I tend to keep in case there's a regression. I think in those cases it would probably polute the metadata providers, especially since this is almost exclusively independently created content. Maybe the vtable could be refined to instead of comparing the name with no tags, compare the name with all non-revision tags. I haven't looked into this but if you think that'd suit your need @Spinnich, I could give it a shot. Would be helpful to have a hand full of edge cases that are causing you issues.

Hey, thank you for getting back to this! To start, I'll list off a few examples but they are all basically the same scenario of two unique official games having the same base name on the same platform. I'll pick on the NES platform since there's a few examples although this is not exclusive to the NES platform by any means. All of these listed games now get grouped together in my RomM instance with this PR.

Airwolf (USA) (Acclaim) & Airwolf (Japan) (Kyugo)
Black Bass, The (Japan) & Black Bass, The (USA)
Rampart (USA) (Jaleco) & Rampart (Japan) (Konami)
Star Wars (Japan) (Namco) & Star Wars (USA)
Tetris (USA) & Tetris (Bulletproof) (Japan) (En) (Rev 2) & Tetris (USA) (Tengen) (Unl)

P.S. I realize one of these is an unlicensed game, but I could not resist having an example of three games with the same name lol.

For my purpose, it's a lot of ROM hacks and games from itch which have multiple versions that I tend to keep in case there's a regression. I think in those cases it would probably polute the metadata providers, especially since this is almost exclusively independently created content.

I definitely understand the desire to lump a bunch of similar unofficial hacks together, but I disagree that it should ever come at the expense of incorrectly lumping games together. Would it not just suffice for you to put all of these versions in a rom folder to group them?

Maybe the vtable could be refined to instead of comparing the name with no tags, compare the name with all non-revision tags. I haven't looked into this but if you think that'd suit your need @Spinnich, I could give it a shot. Would be helpful to have a hand full of edge cases that are causing you issues.

This is over my head but I'm open to a more elegant solution. I am doubtful that fuzzy logic based solely on file names could avoid ever grouping games that shouldn't be. The only thing that comes to mind is perhaps evaluating the metadata IDs first? If two games have two unique metadata IDs, then this logic would not group them... or something to that extent.

I have exampels of this breaking with legit games. Looking here it appears to have grouped Armored Core PSX and its sequals just as "Armored Core".

Going to revert this change in the upcoming 4.8.2 patch release.