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.

181

clrmame Discussion / Re: What's wrong with these roms ?

« on: 15 October 2021, 18:47 »

You mean if you have sideeffects when turning off the option?
Well you will end up with some additional dupe roms (the ones which have a different naming while being byte identical). That‘s the only side effect.

182

clrmame Discussion / Re: What's wrong with these roms ?

« on: 15 October 2021, 17:07 »

erm...no it's not cmpro's purpose to "fit" MAMEs behaviour.

cmpro's purpose is to load a set collection xml definition (and there are thousand of dats which are not MAME related at all), follow specific storing rules and audit the files.

cmpro's storing rules are:
rompath\setname\file 1... file n for decompressed sets
rompath\setname.zip for compressed sets where file 1 to n is in the zip (or rar or 7z)
"name" and "merge" attributes define how the files are named.

The rules are followed, cmpro works correctly.

You clearly have to differ between emulators and auditing tools.
An audited set has nothing to do with playability in an emulator. If MAME kills the decompressed sets support completely, cmpro would not. cmpro supports rar files, MAME doesn't. So again...two programs, two worlds. MAME doesn't care at all about naming when in looks at compressed sets since it simply looks at the crc32 values...so should cmpro ignore wrong named files? No.

MAME devs already confirmed that it's lacking that special case...and the reason is simple: no one uses decompressed sets...no one reported yet the wrong behaviour, so feel free to either fix it or report it.

By the way, you can simply bypass the MAME issue by turning off the "parse rom merge tags" option and rescan/fix.

183

clrmame Discussion / Re: What's wrong with these roms ?

« on: 15 October 2021, 16:43 »

Eh? No, cmpro is fully right in its doing. There is nothing to fix. cmpro follows the correct rules how the sets should be split up and which naming should be used.

MAME is "wrong" in this case. Or better, someone forgot this case when it tries to load decompressed sets....and why? Because noone except you seem to use it
If -at all- a program needs an update, then it is MAME...but again...noone seems to care.

184

clrmame Discussion / Re: What's wrong with these roms ?

« on: 15 October 2021, 15:47 »

yes, only when the names differ.

Actually I already talked with some devs about it and they do confirm that MAME loads decompressed files by name only (packed files by crc32)...and they only try one name
I doubt it's on anybody's list to fix that since using decompressed sets is very rarely used but if you like you can "raise a ticket" at mametesters

185

clrmame Discussion / Re: What's wrong with these roms ?

« on: 15 October 2021, 12:09 »

If you keep files unzipped, you still need to follow the general storing procedure:

rompath\setname\file 1... file n (for unpacked sets)
rompath\setname.zip\file 1.. file n) (where file 1 to n is in the zip (or .7z))

That should work if it doesn't then you discovered a problem in MAME's loading mechnism for unpacked sets....


Update: Yes...it seems to be repeatable...seems to be a "lack of feature" in the MAME loading mechanism of unpacked sets.

186

clrmame Discussion / Re: What's wrong with these roms ?

« on: 14 October 2021, 17:37 »

Sorry but that's not correct. It was tested with exactly that setup and it runs fine.
where did you store your zipfiles and folders for the chds and how does your mame.ini looks like?

Easy scenario setup:

- create a new empty folder "A" somewhere
- unpack the official mame.exe (nothing more) in that folder "A"
- create a new folder in that folder "A" , name it "roms"
- put bm4thmix.zip, bs4thmix.zip and the subfolders bm4thmix and bs4thmix in that roms folder (the zips contain the files I've mentioned before, the subfolders hold the chds as mentioned before)
- open a commanline, switch to the folder "A", run "mame -cc" to create a mame.ini with default "roms" rompath
- run "mame bs4thmix" or "mame bm4thmix"
- both run fine


If you still got problems with that setup, your zipfiles (you're using zipfiles?) might have a problem. Then you can try to unpack the archives, delete the zip and pack the files to a new zip back. This can fix zip structure issues (unless you didn't get any unpack errors). Maybe the parent zip set is simply somehow corrupt and loading fails from there.

187

clrmame Discussion / Re: What's wrong with these roms ?

« on: 14 October 2021, 14:46 »

You should keep both profiler options ENABLED.

According to the definition below, bs4thmix does NOT need 847kaa03.19a plus the other 3 if the parent set holds 847jaa03.19 (and the other 3):

   <machine name="bs4thmix" sourcefile="djmain.cpp" cloneof="bm4thmix" romof="bm4thmix">
      <description>beatstage 4th MIX (ver KA-A)</description>
      <year>1999</year>
      <manufacturer>Konami</manufacturer>
      <rom name="847kaa01.6a" size="524288" crc="17c994e5" sha1="2249d9e788029d194454dc0552246262d4131e8c" region="maincpu" offset="0"/>
      <rom name="847kaa02.8a" size="524288" crc="25b2a690" sha1="90216cc7fbbaa8709eec348a7dcc5e25c7638b34" region="maincpu" offset="1"/>
      <rom name="847kaa03.19a" merge="847jaa03.19a" size="524288" crc="f447d140" sha1="cc15b80419940d127a77765508f877421ed86ee2" region="gfx1" offset="0"/>
      <rom name="847kaa04.20a" merge="847jaa04.20a" size="524288" crc="edc3e286" sha1="341b1dc6ee1562b1ddf235a66ac96b94c482b67c" region="gfx1" offset="1"/>
      <rom name="847kaa05.22a" merge="847jaa05.22a" size="524288" crc="da165b5e" sha1="e46110590e6ab89b55f6abfbf6c53c99d28a75a9" region="gfx1" offset="100000"/>
      <rom name="847kaa06.24a" merge="847jaa06.24a" size="524288" crc="8bfc2f28" sha1="f8869867945d63d9f34b6228d95c5a61b193eed2" region="gfx1" offset="100001"/>
      <rom name="847kaa07.22d" size="524288" crc="0528276a" sha1="ab4f2cdd2938a04f7da3e85f3cec9ca66c85b78a" region="k056832" offset="0"/>
      <rom name="847kaa08.23d" size="524288" crc="3c659505" sha1="ffa81d2f3823076a16422b49ac0ecfb0db376d54" region="k056832" offset="1"/>
      <rom name="847kaa09.25d" size="524288" crc="c078f7d3" sha1="2c268f1b7f1fa71c659d899a49e839128b789245" region="k056832" offset="100000"/>
      <rom name="847kaa10.27d" size="524288" crc="2f676be7" sha1="43d1844280117e76c95bb9b32ea3ca511fffc131" region="k056832" offset="100001"/>
      <disk name="847kaa01" sha1="be35c25d11892b57817ca9da90734a439d259824" region="ata:0:hdd:image" index="0" writable="yes"/>

so...check your rompaths again, it should look like (assuming you use zip files)

<your_rompath>\bs4thmix\847kaa01.chd
<your_rompath>\bm4thmix\847jaa11.chd
<your_rompath>\bs4thmix.zip with

847kaa01.6a
847kaa02.8a
847kaa07.22d
847kaa08.23d
847kaa09.25d
847kaa10.27d

<your_rompath>\bm4thmix.zip with

847jaa01.6a
847jaa02.8a
847jaa03.19a
847jaa04.20a
847jaa05.22a
847jaa06.24a
847jab07.22d
847jab08.23d
847jab09.25d
847jab10.27d

This is working in official MAME.



So maybe double check your rompath entry in mame.ini (if you don't have a mame.ini file, you can create one with mame.exe -cc)

188

clrmame Discussion / Re: What's wrong with these roms ?

« on: 14 October 2021, 12:48 »

There is no mistake.

It's pretty common that sets have byte-identical roms (or disks) but use a different naming in clones (since the original boards' IC names were different for example). That's why MAME uses 'merge' attributes in their -listxml output to show which files can be merged:

   <machine name="bs4thmix" sourcefile="djmain.cpp" cloneof="bm4thmix" romof="bm4thmix">
      <description>beatstage 4th MIX (ver KA-A)</description>
      <year>1999</year>
      <manufacturer>Konami</manufacturer>
      <rom name="847kaa01.6a" size="524288" crc="17c994e5" sha1="2249d9e788029d194454dc0552246262d4131e8c" region="maincpu" offset="0"/>
      <rom name="847kaa02.8a" size="524288" crc="25b2a690" sha1="90216cc7fbbaa8709eec348a7dcc5e25c7638b34" region="maincpu" offset="1"/>
      <rom name="847kaa03.19a" merge="847jaa03.19a" size="524288" crc="f447d140" sha1="cc15b80419940d127a77765508f877421ed86ee2" region="gfx1" offset="0"/>
      <rom name="847kaa04.20a" merge="847jaa04.20a" size="524288" crc="edc3e286" sha1="341b1dc6ee1562b1ddf235a66ac96b94c482b67c" region="gfx1" offset="1"/>
      <rom name="847kaa05.22a" merge="847jaa05.22a" size="524288" crc="da165b5e" sha1="e46110590e6ab89b55f6abfbf6c53c99d28a75a9" region="gfx1" offset="100000"/>
      <rom name="847kaa06.24a" merge="847jaa06.24a" size="524288" crc="8bfc2f28" sha1="f8869867945d63d9f34b6228d95c5a61b193eed2" region="gfx1" offset="100001"/>
      <rom name="847kaa07.22d" size="524288" crc="0528276a" sha1="ab4f2cdd2938a04f7da3e85f3cec9ca66c85b78a" region="k056832" offset="0"/>
      <rom name="847kaa08.23d" size="524288" crc="3c659505" sha1="ffa81d2f3823076a16422b49ac0ecfb0db376d54" region="k056832" offset="1"/>
      <rom name="847kaa09.25d" size="524288" crc="c078f7d3" sha1="2c268f1b7f1fa71c659d899a49e839128b789245" region="k056832" offset="100000"/>
      <rom name="847kaa10.27d" size="524288" crc="2f676be7" sha1="43d1844280117e76c95bb9b32ea3ca511fffc131" region="k056832" offset="100001"/>
      <disk name="847kaa01" sha1="be35c25d11892b57817ca9da90734a439d259824" region="ata:0:hdd:image" index="0" writable="yes"/>
....


Now clrmamepro supports both: A mode where merge attributes are ignored (so you'd have dupe files) or where it takes care of them. This option is: Profiler->Options -> Parse ROM 'merge' tags (similar 0for disks)

So you most likely have a clone set with such obsolete dupes with their original clone-names and now have that profiler option enabled (which is good).
Of course cmpro now complains about the wrong naming first (since now the merge-naming is needed) and wants to rename the files in the clones. Secondly, it will then complain about a wrong placement (since they do belong to the parent) and would move them.

Actually having all fix options enabled should simply fix your "problem".

The 4 files in question for bs4thmix for example are not required to run the game if you got the parent set with the files. If your not-official-mame-build audit reports it as missing, then something is wrong on that emulator side.

189

clrmame Discussion / Re: What's wrong with these roms ?

« on: 14 October 2021, 11:53 »

do you keep your sets fully or split merged?

190

clrmame Discussion / Re: Missing 18 Samples but 0 Sets?

« on: 09 October 2021, 07:17 »

  Simply get the new version
 

191

clrmame Discussion / clrmamepro 4.043 released

« on: 08 October 2021, 15:14 »

4.043
fixed: xml cdata parsing error
fixed: sample stats count for nodump sets which reference a sampleonly set

192

clrmame Discussion / Re: Missing 18 Samples but 0 Sets?

« on: 08 October 2021, 13:02 »

Ignore the stats.

It's actually "recel" which is a nodump set but references "genpin" as sampleset and such samples are wrongly counted as missing in the not existing sets.
The stats count gets fixed

193

clrmame Discussion / Re: MAME XML WSWAN Software list no longer reading?

« on: 08 October 2021, 12:12 »

Thanks but I'm already aware of it..... ;-)

Since it's just a commit yet and nothing was released I thought I got more time

I've fixed it already.....an update will soon be available

194

clrmame Discussion / Re: Bad URL...

« on: 03 October 2021, 12:30 »

well....you should ask the author :-)
EasyEmu isn't anything I can put my hands on....

195

clrmame Discussion / Re: Diff Scans

« on: 21 September 2021, 06:53 »

hmm...works for me...

What I did:

added GOG.com Games, DLC & Extras (5364 + 7) (20210831) datfile in profiler (created a new default profile....) went to settings, added a rompath, went to scanner, hit scan...scan done...ok...all sets are listed (since I've scanned a dummy empty rompath)

added GOG.com Games, DLC & Extras (5416 + 7) (20210909) datfile in profiler, when loading, cmpro says it's an update for the other dat:

---------------------------
Found an updated DatFile
---------------------------
'Currently available GOG games and extras'
seems to be an update to:
'GOG.com Games, DLC & Extras (5364 + 7) (20210831)'
Do you want to update?

Selecting "Yes", loads the dat, Scanner shows Diff Scan and using it will only show the changed stuff


So...everything's fine here..

What you can try is:

- profiler context menu -> Garbage Collection
- profiler -> Clear cache
...and if nothing works, you may want to test if creating a new default profile helps

196

clrmame Discussion / Re: Diff Scans

« on: 20 September 2021, 19:45 »

The dat is ok.
Diff scans are only available if you have an old datfile and a new datfile which share the same name in their headers, so cmpro sees them as an updated version.
So to test something I actually need 2 dats...an older and a newer one.

If cmpro detects a dat as being an update, it will diff them and the diff scan will only work on the changed entries.

Maybe the functionality got broken (it's rarely used)....If I find a little time this week I'll check it with some custom dats...

If you got another dat (older or newer), just send them in...

197

clrmame Discussion / clrmamepro 4.042 released

« on: 14 September 2021, 07:40 »

4.042

misc: support romof handling in device sets
misc: systems auto assign can detect empty software list folders in case they are named accordingly
misc: software list import's default setting is off
misc: changed behaviour of context menu "move all incomplete sets" to "move all sets with problems" (similar for delete).
      This also covers wrong named etc ones, not only missing files.
misc: contextMenu options Delete/Move/Copy Current/all [not fixed]/all sets with problems use the parent set in full merged mode
misc: cleaning cache also cleans hashes folder
misc: batcher's scanner merge mode overwrite does not overwrite the information from a datfile's forcemerging option
misc: batcher's rebuilder pack overwrite does not overwrite the information from a datfile's forcepacking option
misc: don't stop multiple downloads on first failure
misc: wrote a wrapper class to handle all filefind calls which weren't 32k path length ready.
      This should fix all remaining long path (32k) issues.

fixed: invalid wrong-case messages on chds with very long filenames
fixed: wrongly list valid chds as unneeded when a no dump chd of the same name exists and 'mark no dump as unneeded' option is enabled

198

clrmame Discussion / Re: support for empty folders

« on: 11 September 2021, 14:56 »

Well, it's on "the list" for ages...but don't count on it anytime soon since there is currently nearly no development of new features (just some fixing here and there and in case MAME introduces something new (hint hint))

199

clrmame Discussion / Re: Auto Assign only setting 3 [Soft] systems to the \software directory

« on: 02 August 2021, 06:26 »

Auto assign is a pretty easy best-count-wins and it works as follows:
For assigning standard/mechanical/decives/bios and software lists folders it runs through all active rompaths (not subpaths).
Then it counts +1 for per found file/folder for the belonging type. The type which gets the highest value gets this rompath assigned, otherwise the 1st rompath is used.
So you see, you need correctly named files in the paths to actually be able to assign a path, otherwise you all end up with the first rompath.
E.g. you have a rompath e:\roms\a2600 and got 99 valid atari 2600 sets in there and 50 sets of let's say C64, then that rompath gets a count of 99 for Atari 2600 (and most likely much less than the Atari 2600 count for other rompaths) and so the Atari 2600 software list gets assigned to that rompath.

The auto assign might be improved by also checking the rompath name, so e.g. an empty nes folder can be assigned to the nes software lists. That might get in in the near future....but generally the combined mode is pretty dead.

So....the combined mode is a pain to setup since auto assign would only work if you already have sets in all of your paths. And all paths have to be 1) rompaths and b) distinct (besides the 'normal' MAME ones BIOS/STANDARD/MECHANICAL/DEVICES)). Works pretty well if your collection is near perfect, but otherwise you most likely need to assign some or more paths manually.
You can't have "M:/Mame/software" as a rompath. Software lists need to be in distinct paths (which I assume are the subpaths of M:/Mame/software), so you need to add those as rompaths and not their parent paths. You can simply use drag'n drop in the settings folder to add them.


Overall, it's way more easy to use one-profile-per-software lists and run through the data separately. Why?
a) you got the batcher to scan only changed software lists
b) the batcher also allows you to auto-create and assign rompaths for you (no need to setup some hundred paths)
c) the scan results output is way more readable
d) some software lists are not exported by mame via -listsoftware while the hash files have them
e) no problems with identical sets (there are identical sets in MAME which repeat themselves in some software lists)
f) faster lookups

(batcher = select more than one profile in the profiler and hit load, then the batcher with all its options appear)

200

clrmame Discussion / Re: Cmpro dont like chd !

« on: 01 August 2021, 08:30 »

Get the latest nightly:
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210801.7z