Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[haynor666]

Baines, I've check your file and it's ok inclrmamepro x64 with any 7z library (7.20, 7.22b, 7.32a)

[oxyandy]

haynor666

with any 7z library (7.20, 7.22b, 7.32a)

Really ?
Do you mean 7z library (9.20, 9.22b, 9.32a) ?
Where does 7 come from ?

[haynor666]

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) 

[Roman]

I can put a win8.1 pro systembuilder to m amazon wishlist then :-)

[Baines]

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.

[Roman]

hmm....I've now tested a big variety of dlls and 7z files and got no issues. Running Windows 7 (Ultimate) 64 bit....
Does anyone experience any issue with Windows 7? If so, please send me the file.

Windows 8.1 ...well...of course there is a chance that it fails for some reason on that system...can't test at the moment since I don't have it....but on the other side Windows 8.1 is not THAT different....weird....

guess I need a virtual machine and a test installation....

[Baines]

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.)

[Roman]

can you send me your files?

I can also try to prepare a version which prints out some more info, 7z internal error codes etc....


I've run tests with directories, no directories, mixed ones etc....simply compressed via 7-Zip [64] 9.32 alpha  Copyright (c) 1999-2013 Igor Pavlov  2013-12-01.....context menu....

no issues.....can't really believe it's Windows 8.1 related.....

[Baines]

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. :/

[Roman]

you cant really compare 4012 with 4014... well both are based on the same version of the 7z sdk but now I use the c++ part which is way more modern and supports blockwise processing which is definetly needed if you work with larger archives....

regarding windows 8.1, I maye the chance to do some testing in a week....

in the meantime I try to do a build with some more detailled error message output...

[Roman]

so, noone with Windows 7 facing this problem???

[oddi]

Confirmed error when drag and drop 7z archive on about window.
Win8.1 x64 , the last cmpro x64 build. Test with 7zip 9.28a and 9.32. Same error.

with cmpro x86 - drag and drop 7z worked fine.

[oxyandy]

Great work Oddi,
about time another win8 64 user came forward. +1 for you.
You are never far away from this forum, that should Roman when he looks for results/testers.
Thanks

[Roman]

so again only Windows 8.x with 64bit cmpro build....and only 7z...hmm..interesting....maybe a compiler issue...maybe a flaw in the 7z sdk....maybe a bug in Windows 8

[Roman]

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.....

[Baines]

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.....

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

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

===========================
EDIT:
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.

[oxyandy]

Hi Baines,
Some great testing there!
I bet you are happy to know you are not alone with this exact fault, as confirmed by Oddi - it indeed seems 'Win8 x64 CMP64 7z specific bug' & not just 'your' OS.

[Roman]

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

[Baines]

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.

[Roman]

actually "calcCRC: 00000000" shows me already that it did not calculate the hash during decompression.... (0 is the inital value)...but that can have different reasons:

- 7z decompress fails pretty early (and so it never hit the hash update at all...pretty common when the file is small....but result = 1 shows it return a good return value)
- the extract callback which does the hash calculation isn't called at all (I can add some debug promps in another build for this...)
- something is not thread safe.......or it's simply a compiler issue...which is still weird since it runs fine on 64bit Windows 7.......guess there is no way besides of getting Windows 8.1 installed yikes...(nothing I can do this week)