Print

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

[oxyandy]

So if you're reading this Roman,
then clearly you are looking for an excuse to get your head out of lines of code...
So is there any progress ?

[Roman]

All I can say for now is: funkyfiga is a very very evil set....

<rom name="7407.11b" merge="7408.13b" size="1048576" crc="9efe4c60" ...
<rom name="7408.13b" size="524288" crc="1a947f3b" ...


so it maps 7407.11b to 7408.13b (in the parent) which has a different hash than 7408.13b in the clone.....did I mention that I hate merge attributes.....


...and with some other fix your problem or readding files over and over again is fixed...now to the next issue....

[f205v]

IMHO the funkyfiga problem should be addressed by MAMEDevs and not by cmpro.

[Roman]

well...yes...it looks a bit weird...especially if you compare sizes etc..
however I found a workaround....

still have other things to fix...jeezus....did this ever work here....

[Roman]

http://mamedev.emulab.it/clrmamepro/binaries/cmp20141127.rar

fixed:
- wrong placed chd issue
- export issue
- funky set

I wasn't able to repeat the unpack issue or the data loss of romfiles which oxyandy reported though...lemme know if you still got them...(maybe it was fixed with one of the other fixes)....

[oxyandy]

(maybe it was fixed with one of the other fixes)....

.........maybe,
I suggested fixing Funky would make 'other not yet reported problems vanish'
- well, as expected those problem are gone now too.
Great work.

I restored my MAME 0.155 ZIP merged set to what it was... (before 1st CMP Funky Beta)
Just downloaded "Sexy Beta II", ready to destroy my ROM set now.

1. No more unpack errors
2. 'New Scan' completed - no errors.
3. I have not done a Scan and fix on old .155 set  then Rebuilt from .156 update pack
(might try this later - this is what I did first time & this is where I lost some files, during initial "New Scan", before updates)
4. This time I would have had heaps of .156 files in back-up folder (not cleared those)

Heading out to lunch, so far, so GREAT ! - Zero miss....
Second 'New Scan' had fix prompts,
Third 'New Scan' fix prompts,
Fourth 'New Scan' = no errors, no prompts

I am not testing CHDs
Later guys

[oddi]

About chds:

CMP move 3 chds to ROMs folder


inside have :
jojojr1/cap-jjk-2.chd [jojojr1]
jojojr2/cap-jjk000.chd [jojojr2]
sfiii3r1/cap-33s-1.chd [sfiii3r1]

i dont touch chds and start again full scan, when start cmp say:



click "Yes to all" and cmp move chds to him backup folder and report missing chds:



manualy move chds to chd folder and again start full scan, report :



if move chd to parent set "jojo" cmp wanna again remove chd :



see the last 2 shots:  cmp first remove chd from "jojojr1" folder, second shot - cmp remove chd from "jojo" folder
May have any problem with this chds and correct check main set
post shots from first chd, for other 2 chds is same history.
if i manually add chds to correct parent folders after next scan cmp wanna remove again

Ps: Check chds with chdman, all is correct !

Code: [Select]

----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-jjk000.chd [jojojr2] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file:   g:\MAME\WIP_SVN\CHDs\cap-jjk000.chd [jojojr2]
File Version: 4
Logical size: 65,821,824 bytes
Hunk Size:    9,792 bytes
Total Hunks:  6,722
Unit Size:    2,448 bytes
Total Units:  26,888
Compression:  zlib (Deflate)
CHD size:     45,108,605 bytes
Ratio:        68.5%
SHA1:         09869f6d8c032b527e02d815749dc8fab1289e86
Data SHA1:    d5a11315ac21e573ffe78e63602ec2cb420f361f
Metadata:     Tag='CHTR'  Index=0  Length=45 bytes
              TRACK:1 TYPE:MODE1 SUBTYPE:NONE FRAMES:26888.
----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-jjk-2.chd [jojojr1] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file:   g:\MAME\WIP_SVN\CHDs\cap-jjk-2.chd [jojojr1]
File Version: 4
Logical size: 65,449,728 bytes
Hunk Size:    9,792 bytes
Total Hunks:  6,684
Unit Size:    2,448 bytes
Total Units:  26,736
Compression:  zlib (Deflate)
CHD size:     53,553,201 bytes
Ratio:        81.8%
SHA1:         0f5c09171409213e191a607ee89ca3a91fe9c96a
Data SHA1:    74fb14d838d98c3e10baa08e6f7b2464d840dcf0
Metadata:     Tag='CHTR'  Index=0  Length=49 bytes
              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:26736.

----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-33s-1.chd [sfiii3r1] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file:   g:\MAME\WIP_SVN\CHDs\cap-33s-1.chd [sfiii3r1]
File Version: 4
Logical size: 100,916,352 bytes
Hunk Size:    9,792 bytes
Total Hunks:  10,306
Unit Size:    2,448 bytes
Total Units:  41,224
Compression:  zlib (Deflate)
CHD size:     67,848,619 bytes
Ratio:        67.2%
SHA1:         2f4a9006a31903114f9f9dc09465ae253e565c51
Data SHA1:    47c7ae0f2dc47c7d28bdf66d378a3aaba4c99c75
Metadata:     Tag='CHTR'  Index=0  Length=45 bytes
              TRACK:1 TYPE:MODE1 SUBTYPE:NONE FRAMES:41224.
ps: Sorry the last image, if click No to all result:

[oxyandy]

Hi Roman,
I do not understand Oddi's CHD problem. 
(I have suggested "dont list mismatches for bad dumps" <---CMP CHD option should be ticked !)



I do know those CHDs are v4 bad dump flagged.
His get moved to back-up, mine stay put, repeated "New Scan" = no fixes/changes prompted.

I do see a problem with CHDs as follows:
MAME .156 FULL MERGED SET in CMP Scanner/Rebuilder
(Using dat file supplied by Oddi, yes the same DAT file & CHDS, he is having a problem with, I have no problem)
Parse DISK merge tags (TICKED)
I expect to see

\jojo\cap-jjk000.chd
\jojo\cap-jjk-2.chd
\jojo\cap-jjk-3.chd

\sfiii3\cap-33s-1.chd
\sfiii3\cap-33s-2.chd

Instead I see:
jojo\cap-jjk000.chd [jojor2]
jojo\cap-jjk-2.chd [jojor1]
jojo\cap-jjk-3.chd
jojojr1\cap-jjk-2.chd [jojojr1]
jojojr2\cap-jjk000.chd [jojojr2]

\sfiii3\cap-33s-1.chd [sfiii3ur1]
\sfiii3\cap-33s-2.chd
\sfiii3r1\cap-33s-1.chd [sfiii3r1]

See 5x CHDs vs 8x CHDs - Kill the damn dupes will ya

EXAMPLE: cap-jjk000.chd [jojor2]
The [jojor2] has now become part of file-name

[Roman]

Just a note...

Of course there can be differences in some sets if you scan/fix with developer build and latest productive version....
There are some sets which will now be in a parent/clone relationship while they were not when you used the lastest official version of cmpro...

and so of course you might have some dupes getting alerted/removed now....maybe the mentioned chd sets are some of them...

I will recheck them tonight...


...and if you used a custom dat, send it....or directly include cmpro.ini, <profilename>.cmp and the dat.....


...and also keep in mind that such changes may require two (!) scans...there are some cases (and such parent/clone stuff can be one of them) may have some left overs shown in the scan results tree....(maybe I fix this one day...)..So..please be sure you do 2 scans....

[oxyandy]

Later tonight when time permits, please re-read my previous post Roman,
Problems with CHDs
1. When "Parse DISK merge tags" is ticked, CHDs are being duplicated in clone_name folders. (Unticking "Parse DISK merge tags" makes a better set, without dupes)
Please stop dupe chds being created.

2. Instead of CHDs having the file extension *.chd, some now have the extension *.chd [clonename]
Please standardise all file extensions for CHDs to be only *.chd

Once you have done this and created a new build "Sexy Beta III",
we will re-visit Oddi's (some needed chds being moved to back-up folder problem)

Thanks !

EDIT:
Ok I just tested with ARMAX's (0.156 CHD ONLY DAT) I can not reproduce the exact problem.
For replicating this bug, his dat is useless, it makes a chd set as I expect.
However, (see above *.chd [clonename]) once CMP has renamed chds to this extension,
CMP itself, no longer recognises the files (*.chd [clonename]) as chd files !

This IS Oddi's problem.
1. CMP is changing the default file extension to a file extension to an unrecognisable file ext. (Even by CMP)
2. Oddi is then placing these unrecognisable (*.chd [clonename]) manually in wrong folders

SO, fix 1. & 2. above, Oddi's problem = fixed
Dont over complicate this bug fix

DAT file to reproduce ?
If you don't already have one from EXE & CMP, either one of us will upload one for you..
Oddi & myself are presently using exact same dat file..

[Roman]

1) Actually parse disk merge tags should create less dupes...so..what did you do?

2) hmm..ehe...well...if you got hash collisions, the chds get renamed exactly the same as roms....internally the name ends with .chd.....but I can change that easily...however I wonder if MAME is able to load chds by hash compare (as it does for roms)...
if not, maybe we have to disable the hashcollision handling for chds for now....(if there are disk-hash-collisions anyway).

3) (comment from post above so it's not forgotten...keep in mind that such changes may require two (!) scans...there are some cases (and such parent/clone stuff can be one of them) may have some left overs shown in the scan results tree....(maybe I fix this one day...)..So..please be sure you do 2 scans...)

[oxyandy]

What did "I" do ? haha you make me laugh, try again what did CMP do ?
No, that's not fair on CMP, CMP did not write itself, a developer did..
Shoot the developer..

Anyway I am sure is a straight forward fix, you have all required info
(I EDITED MY PREVIOUS POST)
Enjoy
Let me know if anything is needed
Thanks

[Roman]

ah ok...the ".chd" fix is clear to me...fine...yeah....should be an easy fix.
(however I still wonder if MAME loads a renamed chd file by hash compare as it does for roms....I mean area51.chd -> blabla.chd....looks stupid...and I bet MAME fails on this...hehe)

but what about 1) again? you got an example where it created a dupe? ...yes I'm too lazy to read through the posts again ;-)

so tasks for this evening:
- chd extension should be added at the end of the new name (easy...)
- double check if MAME supports loading of renamed chds
- fix 1) whatever it is...

[oxyandy]

a renamed chd file by hash compare as it does for roms....I mean area51.chd -> blabla.chd.

- double check if MAME supports loading of renamed chds

Better idea ? Disable the renamed CHDs.. Leave their damn names as they are ?
CMP Stable, had no problem with merging a CHD set, it's handling of chds needed no further development, did it ?

Yeah, as for 1. I have no idea why CMP now suddenly is:

• ignoring the merge tags for chds
• creating the clone folder & dupe chds..

But if I (we) whine enough, you might just look into why 

[Roman]

ah ok..I will have a look at 1)
...regarding the renames of chds....first I will check if there are existing DISK hash collisions within MAME...
...if there are...I will check if MAME loads renamed ones...which I somehow doubt...

if not I may disable the feature for disks...or introduce the old one (removal of parent/clone relationship) for disk hash collisions...

[oxyandy]

 
That all... sounds great !
I feel confident you know the exact problem we are facing, which should help you get to the root cause quickly..

Thanks Roman...

[Roman]

http://mamedev.emulab.it/clrmamepro/binaries/cmp20141128.rar

and now...sleep...till tuesday ;-)

[oxyandy]

Hi Roman,
Good & Bad.
The Good:
Problem with chds (few I tested - not whole set) is fixed.

The Bad:
Memory & CPU usage has increased dramatically.
Switching between [Scanner to Rebuilder] 50% CPU & taking over 2 minutes ?
After clicking CMP [Scanner to Rebuilder] whole CMP vanishes from view for 2 minutes (only taskbar icon visible)
(via right hand lower corner button in Rebuilder window) - I had 0.156 MAME dat loaded
[Rebuilder to Scanner] not so bad, but not like it used to be.
Anyone else seeing this ?


EDIT: DAT I had loaded, http://speedy.sh/u7zMF/M.A.M.E.-v0.156-Nov-26-2014-r242067.xml.7z
trying new folder setup now.

EDIT2: New CMP Folder setup seems to have fixed it.
Tired too, back to bed..zzzzz

[oddi]

Confirmed, cmp work fine with roms/chds

for info, fast testing where Mame watching , names, checksums or other

[PS] Little play with QMC2/Romalyzer and roms /chds , for roms - we know Mame search checksums, no problem if rom name is rom.bin [set name].
For chds not luck , chdname.chd [set name],Romalyzer say: " u not have chd" blabla



Roman we wait official cmp out , good job again, many tnx


Updates:

sets "royal cards"

cmp add crc32

2.bin -> 2.bin_85e77661 [set name]

2.bin_85e77661 [royalcdfr]
2.bin_85e77661 [royalcrdd]
2.bin_85e77661 [royalcrdg]

and confirmed - new cmp work very slow

[Roman]

well why do you compare a dat with an exe based profile. most likely they do differ.
the mentioned royalsomething set got as bad naming and merge tags as funkysomething. mamedevs should have a look at it.
of course scanning with the latest official cmpro gives other results than checking with the test builds (parent clone relationships differ)

the slowdowns. hmm havent really changed a lot from last night build compared to the obes before. maybe a compiler issue. will do a clean build on tuesday. till then tada