mirror of
https://github.com/SabreTools/MPF.git
synced 2026-02-08 05:37:45 +00:00
Libcrypt detection issue and errors issue with latest appveyor build #224
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sadikyo on GitHub (Sep 11, 2020).
Originally assigned to: @mnadareski on GitHub.
So I just used the most recent Appveyor build to test the EXE date detection in ps1 discs (it worked).
However...unfortunately, I noticed two other issues that seem to be new or a reversion.
The disc I dumped without Libcrypt, dicui submission says Libcrypt.
Also, it gives the total errors incorrectly. For this dump (see below for logs), it shows 154 errors when it should be 394.
It pulled 394 on the version I was using just prior.
Running edccchk, it looks like 154 is maybe the 1 error on mode 2 form 1 sectors, and then 153 warnings from the mode 2 form 2 sectors? It seems to be excluding the warnings from mode 2 form 1.
Logs: https://cdn.discordapp.com/attachments/599357686332784671/753783002399637675/SLUS-90037.7z
edccchk:
Mode 2 form 1 sector with error at address: 34:09:52
34:09:52: Failed ECC P
34:09:52: Failed ECC Q
Non-data sectors........ 47190
Mode 0 sectors.......... 0
with errors..... 0
Mode 1 sectors.......... 0
with errors..... 0
Mode 2 form 1 sectors... 82896
with errors..... 1
with warnings... 240
Mode 2 form 2 sectors... 70682
with errors..... 0
with warnings... 153
Total sectors........... 200768
Total errors............ 1
Total warnings.......... 393
Total errors+warnings... 394
Done
@sadikyo commented on GitHub (Sep 11, 2020):
Slight correction / update. On the previous version I was using, it was also pulling 154 errors.
When I was signed in, it pulled the error count from the redump page, 394. So it seems the submission file will report errors differently based on whether you are logged in or not. I don't know (and assume it wasn't) the intention to pull errors from the actual redump entry as opposed to the current dump.
@mnadareski commented on GitHub (Sep 11, 2020):
This is odd, since it should never pull information unless all hashes match. So in this case, either the error count on the page is wrong or the dump info is wrong. Either way, I may have to make the local copy take the lead and have the count fought over elsewhere.
@sadikyo commented on GitHub (Sep 11, 2020):
I should clarify - the hashes did match. What I'm saying is, when I wasn't logged in with dicui, it generates errors 154. When I'm logged in, it generates 394. Correct should be 394, but shouldn't dicui be reporting errors as reported with that particular dump, as opposed to populating that from redump?
I guess the core issue though really is that dicui seems to be reporting the wrong total errors, regardless of the other decision on population, etc.
@mnadareski commented on GitHub (Sep 11, 2020):
My current theory is that the edcEcc text output changed in some way. That would explain a seeming regression like this.
@sadikyo commented on GitHub (Sep 11, 2020):
Is that also connected to the libcrypt issue or is that something else? I guess you'll find out! Let me know if there is anything else I can do to help here.
@mnadareski commented on GitHub (Sep 11, 2020):
I think this is two separate issues:
@mnadareski commented on GitHub (Sep 11, 2020):
Part 1 fixed in
5bad68b9ff