Scanner records wrong checksum in playlists for serial added games.

[i30817]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

I was just trying to add scrubbed Wii discs to the RA wii playlist and to my surprise it worked, when previously it didn't. Instead of thinking that the scrubbed CRCs got added to the database, i got suspicious because it was far too fast.

Sure enough, they were added by serial. However, the bug here is that on the playlists they're set as

/media/i30817/backup/Documents/Games/Trauma Team (USA).iso
Trauma Team (USA)
DETECT
DETECT
F989BB8D|crc
Nintendo - Wii.lpl

This is ultra mega wrong because the CRC of that disc at the time wasn't 'F989BB8D' but something else i forget because the disc was scrubbed (i've since been unscrubbing my discs to see if i can add at least the ones i have to the database).

At a glance this might cause problems with netplay or other functions of RA that require the exact same disc. For instance, a hacked disc and a non-hacked disc might get added to the same lobby, if i understand correctly.

Expected behavior

This is part of a larger problem where RA plays fast and loose with what it thinks serials and checksums assure. Some functionalities can find metadata by serial and others should only find metadata by checksum and another (name) can't even be certain by checksum only.

What i think should happen is both serials and crc32 (or another standard checksum) need to be recorded on the playlist for full functionality, with several features disabled or not depending on which is missing.

Examples:

if the database gets metadata for 'inherent input lag' to use with the new rollback input lag functionality, using serial to identify the game is the right move because it would work for both hacks and the original game. Same thing for images.

Netplay clearly should use checksums and only checksums to prevent hacks from joining up with original.

The name on the playlists should not be searched only by CRC or serial. Sadly, several dumping projects just change the name of ROM before releasing it. Which causes a 'first wins' which might change the names of the user ROMs. Searching for both filename and (serial or CRC) would be enough to prevent this at the cost of 'forcing' users to have the right names like they're 'forced' to have the right ROMs in several playlists (those that add by crc32 not by serial).

Actual behavior

Both serials and checksums are treated as 'unique' primary keys inspite of this being false for both. I'm predicting this will cause pain in the future.

Steps to reproduce the bug

1. [First step]
2. [Second step]
3. [and so on...]

Bisect Results

[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

• RetroArch: [version/commit]

Environment information

• OS: [The operating system you're running]
• Compiler: [In case you are running local builds]

[i30817]

Think most of this bug was caused by 'bad' old database files. Deleted the old ones, and updated them and right now all the systems that detect by serial (substancially more now, even if i have issues with that strategy and think crc is required for some things like hacks and RA savestate style netplay) at least show '00000000|crc' on the playlists.

The rest is a question of requiring a good crc on the netplay or optionally check by checksum on the scanner to hacks.

Closed.