Print

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

[emulajavi]

Hi Roman,

When using clrmame to check MAME 227 (dat obtained with clrmame from mame64.exe), it reports one file as wrongly named... but it seems that's it's a file that according to the set information, has to exist twice with different names. What could be happening?

See attached pic


Thank you!

[Roman]

You need it twice then.
You can simply rebuild the set and the rebuilder will create it for you automatically...or you clone it manually.

[emulajavi]

Hi Roman,

Thank you for you quick reply.

I took the sfd10001.zip (which contains the six 6 files, as you can see in the image above) and rebuild it, and it created a sfd10001.zip with only 5 files.

It seems that 901467.uk6 which is identical to 901467-01.5c is inside c8050fdc.zip and it's so not needed in sfd10001.zip

Because both 901467.uk6 and 901467-01.5c are identical, and 901467.uk6 'belonging to another place' what ClrMame wanted to do is simply rename it as 901467-01.5c, and so it what it wanted to do was correct.


One question about software lists..... The proper way to add them to my current MAME setup would be

1.- Point ClrMame to mame64.exe to create a new dat file and when it prompts a message about Software Lists say Yes
2.- Place all Software List roms and chds inside the 'roms' folder, alongside my current MAME roms and CHD
3.- Scan with ClrMame and fix if needed

?? Is that correct?? Or is it possible to keep MAME roms & CHDs and Software Lists ROMS & CHDs on separate directories?

[Roman]

Hi again,
sorry for the quick and dirty answer yesterday...I did not look closely enough into it.

After checking the listxml output of latest MAME I see that there seems to be an issue with that one set and that file/set.
I need to check why it includes the (identical) device rom there and why this is causing the naming weirdness.
Since it doesn't do that here, I need to take a closer look.

What merge mode are you using?


Regarding software lists: I strongly recommend to keep them separated. So 1 profile per software list. This has various reasons:
- not all software lists are actually listed in MAME's -listsoftware output
- setting up 1 profile for all software lists plus MAME is a pain
- hard to actually differ between them if everything is in one
- slow
- etc...

So for each file in MAME's hash folder (these are the software list 'datfiles') create a profile. Scan them with cmpro's batcher all in a row...

[Roman]

Ah ok...I now know what might have happened...
Indeed the uk6 rom is obsolete since it now belongs to a refenced device. So it should be placed in the belonging device set and not in the set itself.

Now you got it in your zipfile and cmpro detects the file where the name doesn't belong to the set, so it looks more closely by checking its hash to see if it is just a wrong named file.
Unfortunately this set also holds a hash identical file which does belong to the set (5c). The name check finds a matching hash and says that the file is wrongly named and should be named like the 5c one. It doesn't see that this file already exist. Fixing the name will most likely fail since the file already exist.

So...the name check works, the proposed name is also ok, the fact that the file is already there is not taken into account during the check.

Pretty rare case...in this case you need a little manual involvement to get rid of the file (or you turn off the "name" check and only keep the "unneeded" check).

If new sets are added via the rebuilder, such things won't happen. But it happens when the set exists in that form from a previous MAME version and MAME decided to separate a file as device or bios or parent etc....but such affect only happens when in addition you have the hash collision here...

So...actually I wonder why the .5c file is not defined as device rom as the .uk6 rom....maybe this should be double-checked by MAME devs.

[emulajavi]

Regarding software lists: I strongly recommend to keep them separated. So 1 profile per software list. This has various reasons:
- not all software lists are actually listed in MAME's -listsoftware output
- setting up 1 profile for all software lists plus MAME is a pain
- hard to actually differ between them if everything is in one
- slow
- etc...

So for each file in MAME's hash folder (these are the software list 'datfiles') create a profile. Scan them with cmpro's batcher all in a row...

Ok perfect

What merge mode are you using?

Split mode

Ah ok...I now know what might have happened...
Indeed the uk6 rom is obsolete since it now belongs to a refenced device. So it should be placed in the belonging device set and not in the set itself.

Now you got it in your zipfile and cmpro detects the file where the name doesn't belong to the set, so it looks more closely by checking its hash to see if it is just a wrong named file.
Unfortunately this set also holds a hash identical file which does belong to the set (5c). The name check finds a matching hash and says that the file is wrongly named and should be named like the 5c one. It doesn't see that this file already exist. Fixing the name will most likely fail since the file already exist.

So...the name check works, the proposed name is also ok, the fact that the file is already there is not taken into account during the check.

Pretty rare case...in this case you need a little manual involvement to get rid of the file (or you turn off the "name" check and only keep the "unneeded" check).

If new sets are added via the rebuilder, such things won't happen. But it happens when the set exists in that form from a previous MAME version and MAME decided to separate a file as device or bios or parent etc....but such affect only happens when in addition you have the hash collision here...

So...actually I wonder why the .5c file is not defined as device rom as the .uk6 rom....maybe this should be double-checked by MAME devs.

Yes. That seem to have been the problem. For whatever reason I had the uk6 file inside the rom .zip.... instead on the separate device .zip.

Since the uk6 file hash was identicial to the 5c, cmpro treated it as a wrong named file. If I clicked on fixing it, it would report that it can't fix it (because there's already the 5c on the rom's .zip).

So as you said, cmpro worked correctly and it's up to mame devs to probably remove the 5c file from the rom set and only keep the uk6 file on the device set.


Thanks!!