Hi,

I think I have messed up my whole Mame games. I tried a scan using Clearmame 3.98, after selecting the update. It seems it didn't update as it means to, because I realized there was a new release even if Clearmame was claiming to be up to date.

I do not know exactly what options I selected under clearmame 3.98, but the last release I installed (3.109b) doesn't seem to be able to correct my mess.

I have many files with this error :
Set exists in various rompaths: D:\Games\Emulateurs\Mame\Games CY-JN\sxevious.zip; D:\Games\Emulateurs\Mame\Games SI-W\sxevious.zip
(and so on)

and many others with
Botanic [folder: botanic - size: 40kb]
wrong SysDefPath: botanic [wrong: D:\Games\Emulateurs\Mame\Games A-CX\] [right: D:\Games\Emulateurs\Mame\Games CY-JN\]

My games are splited into a few different folders. And I do not know how to fix it...

Thanks for any help provided.

wrong sys default paths:

- well...either you scanned/rebuilt once with sysdefpaths settings enabled and the other time with them disabled or the bios assignments have changed on database level.
Solution: Either pick the sets up and rebuild them again or move them manually to the correct sysdefpath (or disable the warning in scanner-advanced if you like)

- set exists in various rompaths: this could be caused by a similiar situation. Fixmissing/Rebuilder both decided on some set rules where to put rebuilt or fixed-missing sets. For example if sysdefpaths are used, the sysdefpath is used, no matter if the set exists somewhere else. If you toggled the options in the meantime, you will change the behaviour of fixmissing/rebuilder.
Solution: Same as above...simply rebuild them again or move them to backup and let fix missing fix them automatically with the next scan.


Roman Scherzer

Hi Roman,

Thanks for such a quick answer! And thanks for theses explanations.

I think your diagnosis is correct; but I don't understand how to correct it.

Let me explain: I own some files which belongs (for clrmame) to folder "a". But their name is "bsomething.zip". To fix the error, I should move the file "bsomething.zip" to folder "a"; I don't want to! I would prefer to fix the wrong link.

This is true for "wrong sys default paths" error, but also for "set exists in various rompaths"; if it is obvious for the first, the latter is a bit more tricky, since I have rebuilt many time the culprit files. Trying to (manualy) merge them, when I scan clrmame split again the file.

For now, I unactivated the option regarding the "sysdefault path" detection, letting me only with "set exists in various paths" warning.

PS: do you know why clrmame is so slow with WINE?

> PS: do you know why clrmame is so slow with WINE?

Because WINE is slow.


To correct your issues:

- don't disable the warning about wrong sysdefpaths.
- manually move the listed sets to a new folder, so they should appear as completely missing in the next scan
- to readd them correctly there are several ways:
either use the rebuilder (prefered method) to readd them. This time, be sure you use the correct modes (correct merge mode, correct sysdefpath setting) to add them.... or .... use fix missing. Fix missing looks in addpaths and the backupfolder for missing data. So, either define the folder (where you moved the sets to) as addpath or move them to cmpro's backupfolder and scan with fix-missing. For fixmissing and the usage of sysdefpaths, be sure to enable the belonging setting in scanner-advcanced.


Roman Scherzer

Thanks, I'll give a try to your advices. Again, great support here.

> > PS: do you know why clrmame is so slow with WINE?
>
> Because WINE is slow.

Well, WINE can smoothly "emulate" games like Baldur's Gate or Starcraft; is clrmame more ressource-hungry than these games?

> Well, WINE can smoothly "emulate" games like Baldur's Gate or Starcraft; is
> clrmame more ressource-hungry than these games?


99% of scantime is pure hd access. A full MAME scan on Windows takes 7 seconds (with full usage of the diskcache). The bottleneck is the hd speed.

WINE's MFC and hd emulation seems to be not the best/fastest.
Games are not that resource hungry on the backend part (gfx are handled by your gfxhardware anyway).


Roman Scherzer