Erroneous Cannot move different files to warnings resulting in improper behavior
#440
Assignees
Labels
bug
A confirmed issues that needs fixing
Comments
|
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 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. |
This was referenced Jun 23, 2023
|
Hi @chainsawsalad, I've been hacking at this slowly over the past few weeks, and I think I might have the solution. Could you help me by running the testing instructions at #467 (comment) against your local setup? I spent some time being able to run |
|
@emmercm just tried it as i ran in the same issue for some ps games. Works like a charm for those games. |
|
@emmercm I re-ran my test example with the original two ROMs, and things look good, however I ran it against the rest of my library and I do still see examples of this happening with other ROMs. Working example: Not working examples, extracted out of command output: |
|
@chainsawsalad let's dig in on one of the examples and I can make a unit test around it. For this one: I see a shared track 1 again (SHA1 Could you list the contents of those input zips? Something that includes name, size, and CRC32 such as: |
|
@emmercm does this get you what you need? |
|
@chainsawsalad that's perfect, thank you! I was hoping there was something easy to spot in the output, but everything checks out. I've been spending all evening staring at this, and the "how" is nitty gritty, but the "why" is because some of these games have duplicate tracks within them: <rom name="Zero 4 Champ II (Japan) (Track 25).bin" size="846720" crc="11bf5dbd" md5="b0845f9d312f9686079470c88cb62596" sha1="9f5fd5f2788d144e0eb61e2edfbbad0deb090350"/>
<!-- ... -->
<rom name="Zero 4 Champ II (Japan) (Track 27).bin" size="846720" crc="11bf5dbd" md5="b0845f9d312f9686079470c88cb62596" sha1="9f5fd5f2788d144e0eb61e2edfbbad0deb090350"/>I'm still hacking away at it. |
|
The unit tests aren't passing, I need to clean them up, but feel free to try again for a sneak peek @chainsawsalad 👍 |
|
@emmercm just re-ran my on my whole PC Engine CD collection--no errors! |
🔒 Inactive issue lockThis issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
The text was updated successfully, but these errors were encountered: