Print

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

[B2K24]

FYI Parse ROM merge tags option has always been unchecked in my clrmame since it's the default option.

[Roman]

so I did a little bit of research...

First of all, there is no file loss at all...as oxyandy said already, the files are in the archive but are listed as missing in the tree view...which is correct for this check, since the files do not exist with that name (rebuilder will of course create them since they are dupes and do exist with a different name).

The reason why you're stuck is that the fix missing (or test for missing-but-fixable) routine did not look into the parent set in case of full merged sets. It did however look into the parent set in addpaths or backup folder but not directly in the same set in the rompath...

You might want to try this build which includes this lookup (and a little goodie for oxyandy)

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

[Dullaron]

i going to try that one. Before I do. I want clear this with oxyandy. I didn't do a clean rebuild this time and see what happen here. This is from the svn that I download this morning. Merge the ROM's setting.

Force 10 (JPM) (IMPACT) (set 5) [folder: j6frc10d - parent: j6frc10 - size: 768kb]
wrong size: f1015p2 [wrong: 131072] [right: 131073] [CRC32: 36508a26] [not fixed]

Happy Hour (JPM) (IMPACT) (set 1) [folder: j6hapyhr - size: 768kb]
wrong size: 20427.bin [wrong: 131072] [right: 131073] [CRC32: 3de94b07] [not fixed]

No matter what I do. This will show without doing clean rebuild. Will not removed those because of the same name and different crc? Looking at the same ROM and confused? Unless it swapping in and out with two different sets.

Anyway I took those out and then rebuild those sets. Now fix. Just wouldn't removed those for some reason.

Roman. The new tool did some fixing. I saw it doing some fixing. Just wouldn't fix those above.

[Roman]

look at the size. Your file is 131072 and it should be 131073....
how should cmpro guess the missing byte?
if "run checksum analysis" (and "fix if possible") is enabled (chd + checksum options window), it tries to pad with 00, 01 and 0xff if I remember correctly...and checks the checksum after that....but generally cmpro can't guess missing bytes....

131073 is however a very odd (ha ha ha) file size...maybe a bug in the dat.

but anyway...give the checksum analysis a try...

[B2K24]

Thank You Roman, after using the version you linked a rebuild to 147 and then a scan + fix of 147u3 + rebuild from update pack and backup path gets 0 misses

Missing
·Sets                 0/26452
·ROMs                 0/205995
·CHDs                 -/623
·Samples              -/3507
·Bytes                0/148gb

[Dullaron]

Roman I'm talking about the tool doesn't removed the useless ROM's when all the boxes are checked on those two. Everything else useless gotten removed without a problem.

ffight -> useless ROM removed. s224b.1a

qtono2j -> useless ROM removed. tn2j_09.12a

sc4gcclb -> useless ROM's removed. 95004252.bin 95004253.bin

Unneeded is checked.

I did removed the useless ROM's by drop in the window. I think the ROM's must've been fix by MAME Team or who ever. Probably missing header or something.

Anyway I wouldn't worry about it Roman.

[oxyandy]

Dullaron
If you look at the dat entries for these

Code: [Select]

Force 10 (JPM) (IMPACT) (set 5) [folder: j6frc10d - parent: j6frc10 - size: 768kb]
wrong size: f1015p2 [wrong: 131072] [right: 131073] [CRC32: 36508a26] [not fixed]

Happy Hour (JPM) (IMPACT) (set 1) [folder: j6hapyhr - size: 768kb]
wrong size: 20427.bin [wrong: 131072] [right: 131073] [CRC32: 3de94b07] [not fixed]From the last dat to the latest, you will probably notice that the CRCs are the same in each dat.. Only the 'apparent' size has changed...
If the above is true, then CMP is not considering the ROMs useless..
It is considering them as 'needed' ! (cause CRC matches, size not)
SO, CMP is perfectly correct in telling you that the size is wrong, cause it is.. !

Now surely, 131073 is a mistake, these are Binary dumps, so there is no header.
This should be 131072, no doubt...

I have not been doing SVN builds so I do not have the last & current dat..
So I can not say 'exactly' but you do..
compare  j6frc10d & j6hapyhr between the 2 dats..
Has the CRC remained the same - the size changed ?

[Dullaron]

Maybe it is a mistake on those. Yep the size change after I done the svn update. Maybe I need to talk to them to find out why the size went up.

http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=299982&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

Tafoid said it been fix. It was a typo in the svn source.

[Roman]

to sum it up, case closed, cmpro is ok now.

[oddi]

Amazing:) The last question: "Parse Rom merge tags" option , enable or disable ?

[Roman]

well, actually it's your own decision

I did not enable it by default because the "merge" tags in MAME were too often too wrong (pointing to wrong roms, just missing or holding bad checksums) in the past. cmpro can detect such errors during datfile parsing and fixes them, but still....I did enable the chd merge tags though...
For romsets, I actually also like to have the correct file names which otherwise get lost due to merging...but again, it's your personal taste....

I still wonder why people always come up with the set size argument. Comeon...HD space is cheap and if you're collecting MAME sets, you should not care about a minimum space gain by using the merge tags, full merging in general or 7z...

Last but not least....people should use this forum if they have questions/problems or may found a bug...it doesn't help when endless discussions are kept on a different forum. Normally I can fix issues within a day or two...when I know about them...when I got a scenario where I can easily repeat the problem...

Thanks for any support!

[Dullaron]

Sure I will post here Roman when I need help or something.