emmercm
commented
1 year ago I'm sorry @chainsawsalad, I had read this and had been thinking about it, and then never got back to you.
This is because a number of PC Engine CD discs share the same track 1 it looks like, with the SHA1 e1baaf01eee215def8bd6f6aa080e3a41ffc74f4. Internally, igir de-duplicates input files, because the thought was it doesn't particularly matter where a file of a certain hash comes from. But in the case of moving games with multiple files (e.g. discs), we do kind of care, and would prefer the files come from the same archive.
This is going to take quite a bit of internal refactoring to tackle, to break that input file assumption. I'll see what I can do!
On the logging, I agree with you, that's really aggressive. I'll drop the level down to DEBUG.
lostb1t
chainsawsalad
github-actions[bot]
Paste the command
npx -yes igir@latest -vvv move test report --dat ../DATs/Redump/NEC\ -\ PC\ Engine\ CD\ \&\ TurboGrafx\ CD\ -\ Datfile\ \(541\)\ \(2023-04-09\ 22-11-42\).dat --input ./input --output ./outputDescribe the bug
Certain optical media files seem to behave unexpectedly when processed against certain other optical media files. I haven't been able to figure out why this happens, but I've isolated many examples of it. It results in a failure to
copyormoveone or both files.In the below example
igirfails to identifyJack Nicklaus Turbo Golf (USA).zipas a candidate when it should, and it spits out the following warning:Note the conflict with
Fighting Street (USA).zip. This file is later successfully and properly identified as a candidate and is moved or copied as such. If I removeFighting Street (USA).zipfrom./input/,Jack Nicklaus Turbo Golf (USA).zipis properly identified as a candidate and the tool behaves as expected. I cannot reproduce this behavior with any other combination of files againstJack Nicklaus Turbo Golf (USA).zip.Here are is a very short, incomplete list of other conflicts I've encountered (just TurboGrafx, but I see this for many other optical-based system DATs as well):
More details:
Excerpt from
NEC - PC Engine CD & TurboGrafx CD - Datfile (541) (2023-04-09 22-11-42).dat:Hashes on disk (they match the dat file):
Expected behavior
I expect otherwise positive matching candidates to be treated as such, and not conflict with anything else going on.
The log message
let message = `Cannot ${this.options.writeString()} different files to: ${duplicateOutput}:`;is unintuitive and I honestly don't understand what it means when this issue is encountered. Maybe clearer messaging would help?Unrelated to this behavior specifically, but the console is flooded with
missing XX files for: <unrelated ROM name>. In my example of using only two ROMs in./input/, I see dozens of warnings of what look like attempts to match one of the ROMs to the wrong candidate, and the tool being overly helpful in explaining why. For example:This is true, but
Ys Book I & II (USA)is not among the ROMs in./input/. This doesn't feel like it rises to the occasion of needing aWARN, especially because it's not doing this for every ROM in the DAT, just a subset. See the attached output for a better overview.Debug logs
log.txt
igir version
1.6.4
Node.js version
18.12.0
Operating system
Linux
Additional context
No response