Closed anderbubble closed 1 year ago
Weird, I can't reproduce here. That would happen if one of the roms were missing its CRC in the DAT file, but it looks fine (I downloaded the daily P/C pack). Can you post the DAT so I can have a look?
https://github.com/alucryd/oxyromon/commit/acbe6f66b491ce7c08be30ca7ae198c620052c8a should print the name of the faulty game (if any) when importing.
That's it, the DAT I downloaded didn't list the cue files, for some reason the parent/clone one doesn't, but the standard one does. The cue files don't have any CRC information, only SHA1. That's unfortunate, up until now every DAT I've encountered has had CRC information :/
Processing "Non-Game - Audiobooks (Audio CD) (20230125-135311).dat"
System: Non-Game - Audiobooks (Audio CD)
Version: 20230125-135311
Games: 163
Processing system
Deleting old games
Processing games
⠁ 0/163 0/s 00:00:00 (00:00:00) [--------------------------------------------------------------------------------]thread 'main' panicked at 'Game "Chabon, Michael - The Yiddish Policemen's Union (USA) (Disc 01).cue" has no CRC', src/database.rs:928:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I could make CRC optional like MD5 and SHA1, but then the import process would need another rework, matching files will take significantly more time if I need to compute all 3 checksums and hope there's at least one of them in the database.
Or I could just display in the web ui what type of checksum is available in the roms card, and let users adjust their import command accordingly. Making the whole process worse for a single non-standard DAT doesn't seem like a good idea.
imo just logging something like "can't process {entry}: no CRC" and ignoring the entry would be fine, just not crashing out.
Let's go with that then, I'll implement it probably tomorrow.
Fixed in develop :) ROMs without CRC are now skipped.
Thanks!
current version: b48c0192d72a1fdae62ad6e8e9c1b1e3c91f980e