Please login or register.

Login with username, password and session length
Advanced search  


The new forum is online, hope you enjoy it!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Baines

Pages: [1]
Down side is that I forgot to mention a different issue that I ran across when testing...

Files can be identified with CRC, sha1, and md5.  The Rebuilder cares if the sha1 and md5 of a file doesn't match the DAT information.  The Scanner, and the Scanner's "Fix Name" function, doesn't.

When I was testing, I for some reason rigged two files with identical CRCs, but different contents (and thus different sha1 and md5).  I made a DAT for one of the roms.  If I archive the other instead manually and stick it in the Rom directory and run a Scan, CMP looks at its CRC, sees the match, and decides that it is the proper file even though the sha1 and md5 don't match.  If it has a different name, CMP decides it is the right file and just has the wrong name, and setting Fix Name will have it rename the file.

There is an Advanced option to test sha1/md5 for Fix Missing, but not to enable it for the basic scan, and not as a safety for Fix Name.

(Ah, I remember why I did it.  I was trying to see whether the Rebuilder was actually checking the sha1/md5 of destinations when set.)

EDIT: I could have worded this report better.  I meant to say that this was an issue from the start, not something introduced in one of the fixes.

and test 3...


And it works!

At least it worked for everything that I threw at the About pane.

EDIT: Quick test, I don't see it throwing warnings in the Rebuilder either.

hmm..but it's not fixed with this here:


or is it....? (found something which looked a bit odd...but should not harm...but who knows...)

Still fails.  It doesn't seem to break anything new, but the same stuff that failed before still fails.

error while unpacking 7z file C:\Users\Billy\Emulation\ClrMamePro\apple.7z

file: cmpro.ini
index: 1
testMode: 1
reqCRC: 617F2616
calcCRC: 00000000
bCRC32: 0
result: 1

it doesnt calculate the crc for some reason...0 value.....need to check that...the unpack operation succeeded though...only the check if required crc matches calculated one fails...

I will try the tests with the appl'n logs test later today....sound a bit like an index issue....it seems to try to calculate the crc32 of a folder entry which is 0 when it should pickup the file...

....guess you used a standard 7z add e.g. via context menu to 7zip up the file and folder, didnt you

I used the context menu as well as the GUI.  I tried the context menu 7z'ing both file and folder together, as well as using the context menu to 7z only the folder and then adding the file through the GUI ("Open Archive", then drag-and-dropping the file onto the GUI window and choosing to add).

But again, the process fails even if there is no folder in the archive at all.  I should have mentioned that the error log I posted was from a 7z that held only a single file.  (Specifically, it held a cmpro.ini file.)  I only noticed how the file and folder combination worked after I made that initial reply, and decided to edit that into the initial reply rather than make a second post.

And oxyandy, yes, I did mean to say that it is nice to know that it isn't just my machine.  Computers, and seemingly particularly Windows machines, can have some quirky and inconsistent issues that never really get tracked down.  You never really know about an issue until someone else says they have it too.

ok you Win 8.x 64bit users out there..can you please run this: http://mamedev.emulab.it/clrmamepro/binaries/cmpro64.rar

Go to about and drag'n drop one of your failing files....a prompt should appear (before the common "unpack failed on file")....you can use ctrl+c/+v to copy it/paste it....

should give me a little clue what is going on.....

error while unpacking 7z file C:\Users\Billy\Emulation\ClrMamePro\apple.7z

file: cmpro.ini
index: 1
testMode: 1
reqCRC: 617F2616
calcCRC: 00000000
result: 1

More testing info.

I found that some 7z archives with both files and folders in the root would work, and some would fail.  I did plenty of testing on the wrong track, before noticing alphabetical order.

I made an empty directory and a four byte test file.  The directory happened to be called "logs".  I 7z'd both the file and the empty directory together.  Then I changed the first letter of the name of the 4-byte file and made a new archive.  When the 4-byte file was named "apple.txt" (putting it alphabetically before "logs"), the archive failed on the About pane test.  When the 4-byte file was named "zpple.txt" (putting it alphabetically after "logs"), the About pane handled the archive correctly.

It may also be worth noting that if a root test file is zero-size, it won't interfere with the About pane test.

can you send me your files?

I can't think of anything else to send.  Clrmamepro has been downloaded from the site, both the zipped and self-extracting exe versions tested.  7zip downloaded from its site, both 9.20 and 9.32alpha tested.  All official downloads from the proper sites, and the multiple copies should exclude possibilities of some kind of freak post-extraction damage.

I've tested with an untouched extraction of CMP, to a clean directory with no settings changed at all, as I don't need to change anything to experience the About pane issue.

The 7z archives that cause issues appear to be perfectly fine archives.  I've already attached an example in a previous reply, only for oxyandy to test it in CMP without issue.

EDIT: I don't trust EmuCR, but that was the only place where I found older copies of CMP.  For testing, I just downloaded both 4.014 and 4.012b 64-bit from there. 4.014 showed the same issue as 4.014a, while 4.012b worked fine (which matched my memory of having no problems with 4.012b).  Unfortunately, looking at other forum posts, it sounds like some pretty big changes to how 7z was handled were made between 4.012b and 4.014, so its not like that bit of info is going to be particularly useful. :/

I may have found something.

If I 7zip a file, then drag-and-drop the resulting 7z file onto CMP's About pane, it results in an error.

If I 7zip a directory, then drag-and-drop the resulting 7z file onto CMP's About pane, it processes correctly.  This works even if the directory itself contains files.

Basically, if there are files inside the root of the archive, it will cause an error in CMP.  I've tested this with individual files and directories, as well as adding and deleting files and directories from existing archives.  Whenever there is at least one file in the root directory, it causes an error in CMP.  When there are no files, only directories, in the root of the archive, CMP processes everything without issue (including all the files within those directories.)

I've replace 7z_64.dll in clrmamepro folder with other versions that came with 7z msi installer.

I just tested clrmamepro behaviour with different versions of 7z libray (outdated 9.20, stable 9.22b and 9.32a)  :)

I tried that, but experience the same error with each.

I have found some 7z files that the About panel handles without issue, but these are always old files originally from a different machine, and 7Zip (whether coincidentally or not) says they use compression method LZMA:18.  EDIT: Found a file that compressed to LZMA:18 on my machine, and CMP's About pane errored on it, so that was a dead end/coincidence.

An attempted summary:
Using CMP 4.014a 64-bit, on my machine which is an i5-4670 running Windows 8.1 64-bit, I encounter two issues which are presumably related.  Dropping the 7z file on CMP's About pane produces an error.  Rebuilding a duplicate rom into an existing 7z file with the option to check the destination md5/sha1 enabled produces a warning.

7Zip installed on my machine shows no evidence of an issue.  It has no problems with any of the files, which test and extract properly.  CMP itself shows no issue rebuilding from a 7z archive; its Rebuild issue only occurs when a rom already exists inside the destination 7z archive.  (Roman said the destination md5/sha1 check uses CMP's 7Zip DLL.  I assume the About pane uses it as well?  The Rebuild process itself I assume uses 7z.exe instead.)

Zip and Rar files show no issues.

The 7z_64.dll included in CMP 4.014a is version 9.20, which is identical to the 7z.dll included in 7Zip 9.20.  So the DLL itself doesn't appear to somehow have been damaged on my machine.  Replacing the dll in the CMP directory with the appropriately renamed version from other 7Zip packages produces the same issues.

Oxyandy had no trouble with a 7z archive that produces a CMP About pane error on my machine.

On my machine, 32-bit CMP 4.014a works without issue.  I believe, but cannot say for certain, that 64-bit CMP 4.012b and before showed no issue on my machine either.  (I deleted my older copies, but I don't recall seeing the issues before.  I can't speak with 100% accuracy though.)

On the off chance, I ran a RAM check, which discovered no issues.  But memory checks can never guarantee the absence of problems.

I have found older 7z files obtained from other machines that exhibit no issues, but even some of those do.  The compression method may or may not be tied to whatever is messing up for me, but that could just be a coincidence.

It doesn't look like anyone else has encountered such issues, or at least have not reported them if they have.  (Is anyone else using Win 8.1 64-bit?)

I'm really confused, and will probably switch back to using 32-bit CMP for the near future.  The issues don't seem critical for me (as CMP has no complaints unless I check an option that defaults to off, or use a drag-and-drop feature that I hardly ever use), but I might as well play it safe.

I'm attaching an example 7z that causes clrmamepro, at least on my machine, to throw an error when dropped onto the "About" panel.  The contents are just CMP's "whatsnew.txt"

7z.exe finds nothing wrong with the file, testing and extracting fine.  CMP chokes on it when dropped onto the About pane.  (I'm assuming the unpacking warning and the About panel error are connected.)

hmmm...actually I am pretty sure that I took it from the latest 32 alpha....but asmentioned...I wasn't able to reproduce an unpack issue yet

The version of Clrmamepro 4.014a that I downloaded (extracted from the zip into a new and clean directory) has the 9.20 DLL, not the 9.32 alpha DLL.  The file's Properties->Detail pane describes it as Version 9.20, and it is a byte-for-byte match for the 7z.dll in my installation of 7Zip 9.20.  The 9.32 alpha DLL is marked Product Version 9.32 alpha and is smaller.

Oxyandy, the dll is not blocked.  I did check to make sure when you asked, though.

by the way...if nobody noticed yet, if you go to "About", you can simply drag'n drop all kind of files and archives and it decompresses/calc hashes.....

I'm not really sure what is going wrong at this point.

Running 64-bit Clrmamepro 4.014a: Dragging a zip or rar archive onto the About panel works. Dragging a 7z archive onto the About panel fails with an "Unpack failed on file" error window.  This is happening with both the installer and zip versions of Clrmamepro.

Running 32-bit Clrmamepro 4.014a: Dragging the same 7z archives onto the About panel works fine.

Opening a command prompt, the same files test and extract without issue with command line 7z.exe. This is true for both 9.20 version (what I've had installed) and the 9.32alpha version (which I downloaded to test).

I'm running Windows 8.1 64 bit, and Clrmamepro 4.014a (zip, not self-extracting).  7Zip v9.20 is also installed.  (While 7Zip is up to 9.32alpha, I've stuck with 9.20 because every release since has been an alpha or beta, and the page still links to 9.20.)

The Rebuilder is set to compress to 7z.

When "Additionally test SHA1/MD5 of existing destination" is checked, an "error while unpacking 7z file" warning is generated whenever the Rebuilder has to check a destination rom file.

The files in the destination directory appear to be fine.  They test with no issue in 7Zip itself, and also extract with no apparent issue (and the extracted file maintains the proper CRC).

Running the Scanner with "Test archive (decompress to memory) (Scanner only)" checked does not generate warnings, so the issue appears to only occur in the Rebuilder's process?

Pages: [1]

Page created in 0.117 seconds with 20 queries.