Several rdb entries for the same game (NES and others)

[JoeOsborn]

The RDB files generated from these dats often have several records for the same game, but with different metadata.

In general, one published work might exist as several distinct data files with different checksums. This means that if metadata are assigned via checksum, they only get defined for one specific dump of that content.

Looking at the NES game Xexyz as an example, both the headered and headerless roms are in the rdb thanks to no-intro. However, all the rich metadata like publisher is keyed to the headered ROM with CRC checksum 4DF8E460 ; if the headerless ROM is used instead, rdb lookups can’t easily find that info.

To brainstorm a few solutions:

Is there a way to make the crc, md5, or sha1 fields arrays instead of bins? I don’t know if the query syntax supports array membership checks, and those fields wouldn’t be indexable.

Can a c or lua converter or some other process take an RDB, and make sure all records with the same rom_name have the same metadata besides crc, sha1, and md5 fields? I don’t know how well this would work beyond NES, I haven’t looked at other databases much.

Do users of the RDB have to do their own merging of records, looking up all entries with the same rom name?

What other approaches are there that make sense?

[JoeOsborn]

I guess this is related to the problem of libretro/RetroArch#11275 and schellingb has the RDBEd tool for fixing up the files semi-automatically. I think it would be ideal for those fixes to be applied using the libretro infrastructure in here rather than being maintained separately and conducted for each individual RDB by hand. What can we do?

[RobLoach]

As you mentioned, many of the NES games particular are affected by Headered vs Non-Headered. RetroArch considers different CRCs as completely different games. Much of the meta-data is stored in metadata folders that also get super out of date from No-Intro.