RetroArch icon indicating copy to clipboard operation
RetroArch copied to clipboard

Retroarch refuses to scan files even when CRC32 matches

Open khanson679 opened this issue 6 years ago • 1 comments

Description

When scanning a folder of Genesis ROMs, only a small number are added to the playlist. I manually checked several CRC32 checksums against the database source and confirmed they are correct -- I am assuming that the rest are likewise good.

Next, I scanned individual files. No difference.

Then I turned on the option "scan without core match". Now "Scan folder" still fails for any ROMs that were not accepted before, but "scan file" seems to work.

I find this odd, because the filenames are the same as those in the database, and the relevant core is already installed. It's also odd that there is a difference in behavior between "scan folder" and "scan file".

I will note that I've had obscure problems in the past adding ROMs for other systems as well. Furthermore, it's hard to troubleshoot the scanning process, because neither the GUI nor terminal give any debug info (although the terminal notes successes, and the GUI implicitly notes successes by briefly showing "0/1 scanning filename", etc.).

Expected behavior

ROMs with CRCs matching database are added to playlist when scanning folders or files.

Actual behavior

ROMs with CRCs matching database may or may not be added to playlist when scanning folders. Other (correct) ROMs are only accepted when "scan without core match" is enabled AND "scan file" is used, based on limited debugging.

Version/Commit

  • RetroArch: 1.7.7 (Ubuntu PPA)

Environment information

  • OS: Ubuntu 19.04

khanson679 avatar Jun 24 '19 04:06 khanson679

Update. The database source I was checking against is this .dat file.

Also, I've confirmed that the filename extensions are part of the problem. After converting the source ROM names to canonical names, all ROMs seem to have been accepted. Going back the the original list, it looks like only those with .bin and .smd were accepted, while those ending in .68k or .sgd were not. The rest of the filename was different in all cases, so that doesn't seem to be the issue.

Obviously, this doesn't explain the difference in behavior between "scan folder" and "scan file" when scanning with option "scan without core match" enabled.

khanson679 avatar Jun 24 '19 04:06 khanson679