As discussed in issue #5440, directory scans are slow when compressed files must be checked against multiple databases. This commit adds support to hint to the scanner that a particular database should be used so that only a single scan is required. If the directory name being scanned matches the database name then that single database is selected.
Archive scans were broken for cores like Atari 5200 and Commodore 64 because archive contents were skipped if a core reported it supported compressed files. The problem is, it's a false assumption that just because a core supports compressed files that the content database contains CRCs for compressed files.
Instead of adding the contents of every compressed file to the scan list ahead of time, the patched logic now checks for the CRC of the archive itself as it always has but then adds the archive contents to the scan list if the archive itself is no match. This maintains the logic of adding only the archive if the core supports compressed files and the archive CRC matches but also allows for deeper content scans when there is no match.
The patch also removes `core_info_unsupported_content_path` as it was redundant with existing `core_info_database_supports_content_path` logic.
- Use the primary (largest data) track for CRC identification, as it
seems least likely to be shared among multiple discs
- CRC the primary track when importing a loose .cue file.
- If multiple tracks are in the same file, CRC the correct chunk
Support chd files. Fall back to using the CRC32 of the last track
of CDs if a serial number is not available. This requires new
database files, but is necessary for chd scanning to work.
The check for unsupported content was reversed which was causing files to be checked against every database. Correcting this improves performance drastically. This appears to have been broken since at least commit #fc1f2cdcf.
Alcaro