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

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1

clrmame Discussion / Re: clrmame bug report about rebuilding clone set only

« on: 17 July 2026, 06:17 »

Ah I was a bit wrong about filters.

Filters always include dependent machines in your selection to ensure completeness. This makes totally sense in e.g. a split merge scenario since if you have a clone with just one rom in it and you filter on that clone, well, you get that one file which is - in terms of completeness - pretty useless.

When it comes to standalone mode, I guess this "filtering-auto-includes-dependencies" indeed doesn't make that much sense since the stand-alone machine does include all needed files. For unmerged I think about having bios/devices auto added, since they would be needed.

Ok...two tasks for me:
- standlone should not include parent rom files which are not used and double check bios files
- filter mechanism should take the merge mode into account to decide if dependecies are auto added or not


Regarding xpath filtering: Well, it's not a good one if you filter by machine names, correct, but if you have complex filtering like "only clones", "only parents which have at least one sample", "only machines where Sega is in the manufacturer sting and year is between 1980 and 1990" etc etc...then xpath filtering is the way to go

2

clrmame Discussion / Re: clrmame bug report about rebuilding clone set only

« on: 16 July 2026, 18:27 »

Regarding "standalone": Currently clrmame copies all files from the dependency machines into the current machine.
So if machine A references 1 bios machine, 2 device machines and also has a parent machine, all files from the 1 bios machine, all files from the 2 devices and all files from the parent are included to form the archive for A and it uses subfolders for the bios, the devices and the parent.

You're right though that this might be too much for parent dependencies. In your example 03 - 08 are the files which the clone does replace from the original machine and can be potentially removed from the parent subfolder within this standalone machine.

Regarding bios references (not in your dat though), I need to check if there are cases in MAME where a single machine does not list all bios files. If you look on neogeo games in MAME's -listxml you always see all (?) neogeo bios files for each neogeo machine.

For devices I need to include all since machines only refer the device and not single roms.

Guess I will update the standalone view for this.


Regarding "nonmerged". Well, this mode takes the rom definitions as they are. Bios files are excluded, devices are not included, it will generate a "flat" file, which however won't be playable on its own in a lot of cases due to missing devices and bios files.
The rebuilder rebuilds anything it finds and any instance of it. So if a file is used within 30 machines, these 30 machines are generated at least with that one file. So if you don't want one specific machine being rebuilt, you can use filters (e.g. xpath filters) to only enable the machines you need. xpath is powerful enough to e.g. only focus on clones...or on parents..or on any xml attribute/element you can think of

3

clrmame Discussion / Re: clrmamepro - device roms

« on: 13 July 2026, 12:50 »

old clrmamepro: not possible
new clrmame: you can use standalone mode, which includes all dependencies within a machine (required devices, bios and parent files in case of a clone).

....or you can create an own custom datfile

4

clrmame Discussion / Re: CLRMAME bugs

« on: 10 July 2026, 15:13 »

1a) "Log"
When running the commandline version, the log is the printed output with various warn levels (info/warn/error). You can redirect it into a file if you want. When running the UI version, the log area is at the bottom of each screen. It's resizeable, scrollable and you can even copy all entries to the clipboard. If it's "2 lines", then you should adjust it.

1b) "backup path"
Well, due to the fact that rompaths are reserved for your roms, it's pretty obvious that the backup path can't be a subpath of any rompath, otherwise the scanner would detect it as unneeded. That's why the log informs you.

2) Softwarelist: First of all the question would be are you talking about a -listsoftware import from a MAME binary or a single load of a software list (hash file folder).  I expect you do a -listsoftware import from a mame binary and then the following happens: clrmame rememebers a hash for the binary and a hash of its hash folder where the software list xmls are stored to see if it needs to reget the data and doesn't use the cache. So it does see if files do change inside the hashfolder or the mame binary itself changes. In this case, it reimports the data. Now you might do your changes in a different folder, then there is a settings in settings.xml "Settings/HashFolder" where you can specify your path and then this is monitored for changes.

3) Scan versus New Scan
This has nothing to do with cached XML data. A "New Scan" ignores possible existing previous results and rescans all machines while a "Scan" only rechecks the machines which had issues in a previous Scan or New Scan. The result is remembered and store. If there is no existing result, a "scan" will do a "new scan"


So....to sum it up: no bugs

5

clrmame Discussion / Re: Double description error?

« on: 23 June 2026, 06:25 »

clrmamepro warns about this. You can ignore it. Descriptions can be used for file path naming generation (if the user wants this, more advanced feature, rarely used), that's why the uniqueness is checked....and for emulator devs ;-)

6

clrmame Discussion / Busy?!

« on: 12 June 2026, 08:34 »

I should work on the profiler, shouldn't I.......wait...something's blocking....

7

clrmame Discussion / Re: clrmame 0.7.0 released

« on: 28 April 2026, 17:28 »

ok found it...will send you a quick build for a check

8

clrmame Discussion / Re: clrmame 0.7.0 released

« on: 28 April 2026, 07:13 »

Perfect, thanks, I will look at it later today....

9

clrmame Discussion / Re: clrmame 0.7.0 released

« on: 28 April 2026, 06:16 »

Older link showing. I change it to v070. Anyone see this. Just change it from your browser, Be ok.

The link should be fine....reload the page / cache cleaned

10

clrmame Discussion / Re: clrmame 0.7.0 released

« on: 28 April 2026, 06:14 »

I try to repeat that scenario...0.7.0 had no changes regarding to "missing but fixable" though....but surely I will have a look
..or do you have a repeatable scenario which can be zipped up ;-)

11

clrmame Discussion / Re: clrmame 0.6.3

« on: 27 April 2026, 07:21 »

Well, if it lists missing files, you're missing files. It's easy as that :-)
If you have them in your collection, backuppath or addpath, they get added and won't appear anymore as missing.

If you'd have a complete clean MAME collection, no red or orange items are listed. You'd only see the root item "0.287 (mame0287)" and no sub items.

There are context menu options which allow to hide the orange and red entries though, but by default they are not enabled.
"Complete clean" means that no problems were found for your current selection of options. If you e.g. only scanned a few sets by using modifiers/filters, it does not necessaily mean you have all the files...it only means "for your selected filters - it's ok".

So, unless you're using the default options and nothing is shown in the tree...you're done...anything red/orange -> you have some issues.

12

clrmame Discussion / Re: clrmame 0.6.3

« on: 27 April 2026, 05:58 »

>The why is because I do not know what I am doing

well...the readme.md file explains all modules and what they do and what the options do and I hope the previous post already cleared some things up.



>I still get some warnings when I run scanner

Well, then open the warnings....click on the + symbol before the listed items to expand the tree and see what is wrong with the machines....

13

clrmame Discussion / Re: clrmame 0.6.3

« on: 26 April 2026, 15:11 »

ok..let's start...with 2 minor things:

- clrmame 0.7.0 is out :-)
>and then creates a mame287.xml file
You don't need this. You can simply let clrmame's XML/EXE simply point to your mame.exe file. When you specify no additional parameters, -listxml is automatically used. The advantage is that you can simply reuse this setting when your mame binary gets updated.

Now what you did....

- The next step you're trying is to use the rebuilder to rebuild your 287 chd/roms update set to a new folder. Why? The output will be the same as the input after rebuilding.
- When you used the scanner, you used your old 286 collection as rompath and you scanned it with a 287 data basis...of course it will show you files with warnings since romsets change with each MAME version.


So let's start over:

Rebuilder: It takes anything valid from a given input and creates all matching (hash compare against currently loaded data) instances in the specified output. It does not produce fully complete sets. If one file is shared by like 1000 sets, you get 1000 sets with that file. They still may require more. Yes, the rebuilder can be used to add "an update pack" to an existing collection, but then the output should point to your existing collection. Mainly the rebuilder is used to convert data from one emulator to another, or to see what a bunch of messy folders have which can be reused and so on. If you use it as an adder, be sure that you're using the same data basis for scanner/rebuilder and the same merge mode.

Scanner: The scanner is the main module, it scans your roms and sample paths and is able to fix nearly every problem it finds. Surely it cannot magically create missing files out of nowhere, but you can use add paths and the backup path to make it look file files which it then automatically adds to the right place. So when you simply added your "287 update pack" files as an add path, you would simply run the scanner.

So, you should go with the scanner, define an addpath (it's in the modifiers tab), let the rompath point to your rompath(s), check which merge mode you prefer, keep fix issues disabled for now and hit scan.
Then take a look at the tree output. you can expand the items to see what is wrong with the files. If your update pack in your addpath is a good one, you shouldn't see any red X marked sets, the orange ! sets will most likely indicate missing but fixable files (fixable because it found the files in your add path).

When you enable the fix issues option and do another scan, it will try to fix all listed issues, i.e.
- rename wrong named archives/roms/disks
- unneeded files will be moved to backup
- missing but fixable files are copied from the addpaths and backup (optionally when incl. as add path is ticked)
- optionally matched files from addpath/backup are removed


Now imagine you'd have one folder where you always put your update packs and you'd use XML/Exe pointing to your mame binary, then updating mame is just one click the next time.

14

clrmame Discussion / Re: clrmame 0.7.0 released

« on: 25 April 2026, 13:04 »

DjDiabolik: erm..no, the link is correct and working...maybe you need to clean your cache....
Bad A. Billy: well, the mameworld post holds the download link and the link to the readme...that's enough :-)

15

clrmame Discussion / clrmame 0.7.1 released

« on: 24 April 2026, 15:51 »

2026-04-28 clrmame V0.7.1 released

https://mamedev.emulab.it/clrmamepro/binaries/clrmame_v071.zip
https://mamedev.emulab.it/clrmamepro/binaries/readme.html

fixing johnIV's finding regarding fix-missing...thanks John!


2026-04-24 clrmame V0.7.1 released

Core:

- fixed: dir2dat: fixed broken 'archive as files' option
- fixed: cmdline, not always load/save settings.xml from application folder
- fixed: cmdline, when using relative paths, they are not always relative to the current directory (cmdline version) or application folder (ui version)
- misc: rewrote wrong named machines fixing. Clearer handling should also sort out all known rare edge cases which were fixed. Also it reports all found instances of wrong named machines (e.g. chd folder and archive)
- misc: updated ZipArchive to 5.0.1/zlib-ng 2.3.3 zip operations are way faster
- misc: updated cli11 to 2.6.2
- misc: updated bit7z to 4.0.11

UI:
- misc: changed the way the tree gets refreshed, maybe this solves the rare "no tree" refreshing issue

16

clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64

« on: 04 April 2026, 15:00 »

You're welcome.

The general thing is that any file rom/chd file which doesn't appear in the loaded xml is "unneeded". So scanning some huge selection (like MAME) with a small dat (like arcade64) marks anything unneeded which is not part of arcade64....
Unknown sets are then also passed through a routine to see if this might just be a renamed set...which not necessarily be 100% right...(the new clrmame is a bit better there but there were some edge cases recently which still cause a bit of headache...).

So...better keep collections separated, don't try to mix

17

clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64

« on: 04 April 2026, 13:18 »

So it was confirmed that Arcade64 xml output is only a subset (arcade based, working, etc) of MAME's xml output

If you scan MAME rompaths with that subset, it will find sets which are "wrong named". Actually they are "unneeded" (coming from their name) but such sets are then checked if they might be just renamed. The heuristic checks the hashes, checks if the found matches and the rom count might indicate a wrong named set and reports that.

....and of course: you should switch to the new clrmame ;-)

18

clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64

« on: 04 April 2026, 08:53 »

I've exported the arcade64 xml via -listxml from its exe...and I assume you used that export (or directly from its exe) in clrmamepro.
Now when I look at the rather small xml (well, I was expecting that since it only holds arcade stuff), I don't see machines like

25pacman
3super8
4roses

etc... but I do see

20pacgal
spk306us
cpokerpk

Since you have the first mentioned ones on you HD (from official MAME) but scan with a xml database which doesn't have them, clrmamepro checks if it's just a renamed set...and correctly reports them.

Question would be (and I've done that on the thread on the Mameworld forum) if it is wanted behaviour that Arcade64's xml output does not list such sets which official MAME lists....

Either way, mixing collections with different databasis is not a good idea.

19

clrmame Discussion / End of month...where is a new release :-)

« on: 25 March 2026, 19:44 »

Well well well...you have to be a bit more patient, however it seems that some nice things happen:

- planning to change the way how wrong named machines are handled a bit which resolves some weird rare constellation problems plus reduces the needed code

- ZipArchive was updated to 5.0.0 which allows using zlib-ng instead zlib as basis for zip compression and some tests show some really great improvements. Just a quick rebuild with 'rezip' (3.20 gb of zip files,  unpack files individually to temp, recompress (deflate, best) to a new folder) takes around 10:48 minutes on the test hd based system...with zlib-ng as basis this shrinks to 04:47 minutes.....

So....there are some things going on.....

20

clrmame Discussion / Re: Question clrmame 0.6.3 folder handling

« on: 17 March 2026, 17:23 »

Samples have no hashes provided in the datfile/mame -listxml output, so you can't rebuild them and fix missing won't either.
So you need to manually copy the sample set buckrog to buckrogn