[Bug] Numbered sequels show as alternative version of different game

[c010rb1indusa]

RomM version v3.10.1

Describe the bug Numbered sequels in a series are showing as alternate versions for a different game i.e Final Fantasy 7 is shown as an alternative version of Final Fantasy 9 and visa versa. Happens with many more sequels. Oddly enough it doesn't do this with Final Fantasy 8....

Screenshots Screenshot of the issue

Just wanted to say thanks in advance. All your hard work on this software is very much appreciated over here.

[zurdi15]

Hi! Thank you for the kind words. This is caused just by how the metadata providers search engine detect games. The quick fix here is to manually match them to the correct game, we can't do much more right now 😅

[c010rb1indusa]

The games are properly matched though. Final Fantasy 7 is matched properly as itself but it shows FF9 as an alternative version even though FF9 has its own individual entry that's properly matched as well.

https://imgur.com/a/3mE1OGY

This is what SMB on NES looks like https://imgur.com/a/ORcOBza

These are all games with their own separate entries that are properly matched. Forgive me if I'm mistaken but I don't see a way in the UI to manually remove these versions from the others metadata.

[gantoine]

@c010rb1indusa Any chance the SGDB IDs of those games match even though the IGDB IDs are different? That would cause them to be considered sibling games.

[focustense]

I did some sleuthing after seeing all six Mega Man (NES) games being linked this way. I don't have SGDB set up at all. It turns out this is because of the ScreenScraper ID.

MariaDB [romm]> select id, igdb_id, sgdb_id, ss_id, name from roms where id in (87, 88, 89, 90, 91, 92);

+----+---------+---------+-------+------------+
| id | igdb_id | sgdb_id | ss_id | name       |
+----+---------+---------+-------+------------+
| 87 |    1714 |    NULL |  1255 | Mega Man   |
| 88 |    1715 |    NULL |  1255 | Mega Man 2 |
| 89 |    1716 |    NULL |  1255 | Mega Man 3 |
| 90 |    1717 |    NULL |  1255 | Mega Man 4 |
| 91 |    1718 |    NULL |  1255 | Mega Man 5 |
| 92 |    1719 |    NULL |  1255 | Mega Man 6 |
+----+---------+---------+-------+------------+

The ss_id in question is for an apparently arbitrary game in the series, Mega Man 2.

I have noticed in general that ScreenScraper matching is hit or miss, mostly due to subtle changes in their formatting, like using dashes instead of colons - perhaps this could be alleviated by having the scanner strip punctuation before running searches. That said, this appears to be a different issue, and it's particularly strange in these cases because when I go to do a search to manually fix it, the very first search result is always a correct match for both IGDB and SS at the same time, e.g.

And this is without having renamed anything, and without manipulating the search query at all. The UI has no trouble finding the correct match on both providers.

So in a large number of these cases it doesn't actually seem to be a problem with ScreenScraper metadata matching per se, just seems to be the scanner acting weird, and different from how the manual search UI acts. For the record, I just scanned my library yesterday, and did these manual fixes this morning, so it's very unlikely that something in the metadata itself got fixed overnight for all those games.

Other series this happened with - just to illustrate how common this is - include:

• Adventure Island (all 3 games)
• Dragon Warrior (I, II and IV, but for some reason not III)
• Contra and Contra Force (no numbering in these)
• DuckTales (both games)
• Wizards & Warriors (odd, since the second game is named "IronSword", also the 3rd does not get lumped in)
• Ninja Gaiden I and III, but not II
• Super Mario Bros 2 and 3, which also very strangely get linked to Mario Bros (not Super Mario Bros 1) and Super C (a totally different game!)

[focustense]

FWIW, after even more experimentation and a lot of manual searches and corrections this afternoon, I'm starting to think that ScreenScraper search doesn't pay any attention at all to numbers in the search string, or treats them in some unconventional way.

Not only does this general issue come up very consistently whenever SS metadata is involved, but the actual title that ends up getting matched is completely inconsistent. In any given trilogy series, all 3 roms will almost always end up pointing to the same game in ScreenScraper, but which game is completely random and might be any of the 3 actual games in the series.

So maybe this simply has to be written off as ScreenScraper having poor search results and needing frequent manual corrections. However, it's also very tedious to fix, and that's something that I think can be improved on the RomM side, unless there's already an easier way than what I've been doing, which is:

1. Open up the ROM page in RomM.
2. Click on 3 dots -> Manual Match.
3. Usually keep the name as-is (maybe 1 out of 10 times I have to simplify it to get more search results.)
4. Click search.
5. Wait a while to get the results.
6. Find the correct ScreenScraper result. If I'm lucky, there is already a merged result; but if not lucky...
7. Select the SS result, click OK and wait several seconds for the metadata to update.
8. Since IGDB metadata should usually have priority, now I have to switch it back, so now repeat everything from step 3 onward but select the IGDB result again.

There probably should be a better way? Understandable if this can't be quite as slick as something like radarr, where the app "just knows" the correct mapping between IMDB and TMDB, because TMDB actually has the IMDB ID. But maybe we could have something like the Jellyfin metadata editor where we can just assign the "external IDs" directly and choose which one is primary, as opposed to having to go through the search process.

[gantoine]

There probably should be a better way?

The better way IMO is hash-matching, which is coming soon in the next major release. We're also planning to allow setting the IDs directly for each source separately.

[aaronflorey]

Would it be possible to strip out the info inside brackets that generally come with roms, and then doing a levenshtein match against the returned results?

[aserrallerios]

I'm experiencing this and I got a huge library to scan.

Would it be advisable to wait until the new hash-matching is released?

[gantoine]

Would it be possible to strip out the info inside brackets that generally come with roms

We do this already when trying to match against game titles

doing a levenshtein match against the returned results

cool idea, not sure how useful it would be in practice but we would welcome a POC PR

Would it be advisable to wait until the new hash-matching is released?

Yes, scanning is slower in 4.0 now that we hit more API endpoints and do more hash calculations but the results are better IMO. I'm planning on wiping my setup and scanning my entire library from scratch to test the new scanning.

[gantoine]

Most of this has been addressed in v4.0.0. Screenscraper matching is still problematic with numbered sequels, but we'll improve that in future work.