If there is, say:

Game [file inside zip has crc 0]
Game (Beta) [file inside zip has crc 1]

and a new version of a dat file swaps them around:

Game [file inside zip has crc 1]
Game (Beta) [file inside zip has crc 0]

ClrMame gets confused and says that they are both missing instead of renaming them properly. You have to move both files to another directory and do a rebuild to get the right names.

> If there is, say:
>
> Game [file inside zip has crc 0]
> Game (Beta) [file inside zip has crc 1]
>
> and a new version of a dat file swaps them around:
>
> Game [file inside zip has crc 1]
> Game (Beta) [file inside zip has crc 0]
>
> ClrMame gets confused and says that they are both missing instead of renaming
> them properly. You have to move both files to another directory and do a rebuild
> to get the right names.
>

Hmm...works fine here. Circular renames are supported since years. Just retested it with a modified puckman set where I exchanged the checksumvalues of 6e with 6f:

PuckMan (Japan set 1, Probably Bootleg) [folder: puckman - size: 8kb]
wrong name: D:\temp\test\puckman\namcopac.6e [wrong: namcopac.6e] [right: namcopac.6f]
wrong name: D:\temp\test\puckman\namcopac.6f [wrong: namcopac.6f] [right: namcopac.6e]




Roman Scherzer

> Hmm...works fine here. Circular renames are supported since years. Just retested
> it with a modified puckman set where I exchanged the checksumvalues of 6e with

Yes, it works within one zip file. But not between two separate zip files that have one rom inside each. The following dat files make clrmame go pop:

game (
name "Addams Family, The (U) (Beta)"
description "Addams Family, The (U) (Beta)"
rom ( name "Addams Family, The (U) (Beta).bin" size 1048576 crc 2803a5ca )
)

game (
name "Addams Family, The (UE)"
description "Addams Family, The (UE)"
rom ( name "Addams Family, The (UE).bin" size 1048576 crc 71f58614 )
)


---->


game (
name "Addams Family, The (U) (Beta)"
description "Addams Family, The (U) (Beta)"
rom ( name "Addams Family, The (U) (Beta).bin" size 1048576 crc 71f58614 )
)

game (
name "Addams Family, The (UE)"
description "Addams Family, The (UE)"
rom ( name "Addams Family, The (UE).bin" size 1048576 crc 2803a5ca )
)

Well..it's a normal behaviour because:

What you're talking about is a set + name check.
Since both sets got valid names for the used datfile, the set + name check won't run...it will only try to detect correct names for wrong (i.e. name doesn't appear in the dat) set names.
The roms + name and roms + unneeded check does work and of course detects the wrong files in the correctly named sets.

Anyway...it's not problem since usually people got all fixing options enabled and that would mean:

- roms + check/fix unneeded will move the wrong names to backup
- roms + check/fix missig will automatically put them back in to the correct place (if scanner->advanced->fix missing scans all files is enabled)


or if using the rebuilder for adding new files, they will be automatically picked up when using enabling the addpaths option (no need to setup an addpath, backupfolder is used by default)


Roman Scherzer

Maybe this screenshot will persuade you to believe it is a bug :)

http://img320.imageshack.us/my.php?image=swapbug7cl.jpg

> Maybe this screenshot will persuade you to believe it is a bug :)
>
> http://img320.imageshack.us/my.php?image=swapbug7cl.jpg
>


It's NOT a bug. I just told you in the previous post it's intended that way. The set + name check checks only unknown setnames. Your setnames ARE correct, since they appear in the database. So only the rom + name check gets active and that of course sees that the roms in the correctly named sets are wrong. The sets aren't in a parent/clone relationship either, so roms + unneeded doesn't say they are wrong placed.

As said before: several fix missing options will fix that automatically and both clrmamepro's setname and romname check work correctly.


Roman Scherzer

> As said before: several fix missing options will fix that automatically and both
> clrmamepro's setname and romname check work correctly.

As you can see in the picture, I have those options enabled and they still don't fix the situation...

> > As said before: several fix missing options will fix that automatically and
> both
> > clrmamepro's setname and romname check work correctly.
>
> As you can see in the picture, I have those options enabled and they still don't
> fix the situation...

Hehehe...look at your files...and you should easily see what's wrong with your sets:

1) you got correct Setnames
2) you got correct Romnames
3) you got invalid (exchanged) checksums

so you can easily see what's happening:

- set + name check doesn't need to fix anything
- rom + name check doesn't need to fix anything
- rom + checksum check tells you the file is bad

And since nothing's moved to the backup folder (unless you use popupmenu->delete->all not fixed), fix missing doesn't pick anything up.


Your problem is that the rom name and set name is still correct, so only the checksum check detects the bad checksum.


If you simply exchange the names of two sets the other method I told you works fine (although you need 2 scans, the 1st removes the unneeded, the second picks up the missing).


So in your case you simply have to use the delete not-fixed method to put bad checksums to backup where it'll be picked up later.


All these stands in no contrast to the scanner and its purpose how it works and not a bug at all. All checks/fixes react correctly. What you want is what the rebuilder does, since it's not setbased but filebased. The scanner is setbased (+ parent/clonerelationship). Everything which is out of this parent/clonerelationship scope (except a set + name check based on unneeded sets) is not expected to be found/fixed and there is no intention to cross-test on a rom (not set) based level. Think about it how long a scan would take if every set is compared against each of the other sets....enjoy ;)




Roman Scherzer