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.

301

clrmame Discussion / Re: [SOLVED] Separate paths CHD VS nonCHD?

« on: 05 December 2021, 12:06 »

If you keep CHDs in one rompath, no problem. But they will follow the general set merge setting.

So if you have full merged sets, you need a subfolder for each parent set in there and the folder holds the parent and the clone chds. If you have split merged sets, you need a subfolder for each parent and clone set and the chds are put in their belonging subfolders. If you have not merged sets, you do the same as for split, but there might be cases where you need to double chds.

As I said...as long as you don't use system default paths or the combined SL mode, it's simply another rompath which simply holds chds (in their set-subfolder). You can keep the belonging roms (if there are any) in a different rompath, zipped/7zipped or even decompressed.

302

clrmame Discussion / Re: Separate paths CHD VS nonCHD? + Merge .chd files while keeping unmerged sets?

« on: 04 December 2021, 19:55 »

So maybe we start with merging. Either all or none.
And I think if you're talking about non merged you most likely speak of split merged....since unmerged is really really a waste of hd space and actually it's not what you might think of.

not merged or unmerged: each set got all the files it needs in it (folder or archive 7z/zip/rar). So clone sets contain the parents again in them.....a waste of bytes.....but actually that's not the full truth since sets usually also require bios roms and since some time ago also device roms....so if you really want to talk about fully stand alone not merged sets, you'd need to double/triple/etc such files and put them in the archives, too....as you can see....there is no real need to even talk about not merged/unmerged sets.

split merged: the most common storing method since you a) have a set for each set, so you have a better look on it and b) there are no (or nearly no) dupe files since the clone sets only contain the files which are unique for them. "or nearly no" because we don't support clone of clones...so there are cases where clone sets would be a able to share files, too but they don't because the parent doesn't use it

full merged: also pretty common....but not my personal favourite....only parent sets exists and they hold each clone in it, too.

When we talk about chds, it's the same....chds are simply a part of a set. A set is a collection of roms and/or samples and/or chds and they are always stored: rompath\setname\file 1... file n for decompressed sets or rompath\setname.zip (.rar/.7z) for compressed ones. Now in theory it would mean that you put the chd in the zip file too, but since they are already compressed containers, so it doesn't make much sense...that's why you put them in a folder named after the setname. Keep in mind, the chd filename doesn't need to match the setname.
For full merged sets it would mean that you have a rompath subfolder named after the parent set which holds all chds for the parent and its clones....and you got a zipfile somewhere in a rompath with all rom files.

You can keep a folder for chds as you mentioned in your last post but that won't fit with the softwarelist combined mode. In a normal clrmamepro profile, you can of course keep as many rompaths as you like and spread the sets over them as you like.

Finally, in "normal" clrmamepro mode, you can also use system default paths which allows you to split your collection by bios...but again...then you need 1 assigned rompath per BIOS...So for example SegaSP sets would have a rompath with folders for the chds and the zip archives for the roms.....


It's basically up to you...what you prefer.....as soon as a combined SL mode or sýstem default paths are used, you will be limited though.

303

clrmame Discussion / Re: Proper settings for select consoles + arcade?

« on: 03 December 2021, 15:43 »

The easiest is to keep separte profiles. One for MAME without software lists and one for each software list.

If you really want to use the combined mode, you can a) limit the number of software lists on import. After that you will have the ones you've chosen plus the ones for MAME (which are Standard, Mechanical, devices and lots of BIOS ones). All software lists paths need to be distinct and unique, the other ones don't have to be unique. Assign your setup rompaths correctly to them and you can scan.

Your problem is that you try to separate chds in a standalone path. Why? A set (let's take area51 for example) consists of a rom set and a chd which is also part of it....so splitting up chds in a different folder that the belonging roms is not really a good thing.
And you can't assign the paths in that scenario if you split them up that way. Since as I said...let's take area51 for example which belongs to "Standard" needs to be assigned to 1 rompath.... and you got 2...your roms and chdspath.

so I guess...you should switch to the separated profiles options. Simply drop MAME's hash folder entries to the profiler for the softwarelists you like to use.

304

clrmame Discussion / Re: [SOLVED] clrmamepro get stuck in a loop when trying to write to NFS remote share

« on: 30 November 2021, 07:47 »

very interesting, thanks

305

clrmame Discussion / cmpro 4.044 released

« on: 29 November 2021, 15:40 »

4.044

fixed: file can get lost under some rare rename/set conditions (MAME238 diablo68 u2)
misc: update 7Zip SDK/DLL to 21.06, update unrar SDK/DLL to 6.10.2
misc: compiled with Visual Studio 2022 / Win 11

306

clrmame Discussion / Re: clrmamepro get stuck in a loop when trying to write to NFS remote share

« on: 29 November 2021, 13:27 »

Check access writes maybe Sounds too easy but actually I don't have an idea what else should have caused this. Would be interesting if you play a bit with a minimal setup, e.g. a 1-set-1-rom datfile which you create on your own, put the file on your share and do some testing with renames/write access.

307

clrmame Discussion / Re: sets without roms are reported as missing(?)

« on: 29 November 2021, 12:04 »

well....all I can say is that people had very weird issues when using Samba...most of the times it was related to typical dir-tree-walks...where it simply stopped or better..it simply completed (but didn't run through all files and folders). Some users were able to resolve the problem by updating drivers...
Nothing I can really help since cmpro simply calls win32 api functions....

308

clrmame Discussion / Re: Can't get Software List paths set up properly

« on: 29 November 2021, 08:08 »

Batcher (select more than one profile and hit load) -> Misc -> Create rompath for new dat (specify root folder)

309

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 29 November 2021, 08:06 »

hmm....but cmpro always writes its selected paths with a \ at the end.....so I wonder how you get paths without it (unless manually editing *.cmp files which is not recommended ).

310

clrmame Discussion / Re: sets without roms are reported as missing(?)

« on: 29 November 2021, 07:06 »

Hmm...good it's resolved but still spooky. The filesystem shouldn't play a role since but if you're saying you got it "on a server" that could be the root cause, especially if e.g. SAMBA is involved somewhere. There are known weird issues connected to SAMBA (e.g. simply finished rebuild operations after e.g. 30%, etc.), which usually are connected to bad drivers or unstable connections. If you search this forum for samba, you'll find some weird things ;-)

but maybe it was just some weird bad old caching thing......keep an eye on it ;-)

311

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 29 November 2021, 07:02 »

"In my case, the rebuilder undesirably creates software-listed roms in $mameroot\software instead of $mameroot\software\$mycustomed_system_path"

It sounds like you have $mameroot\software as a rompath which is wrong if you also have subfolders in there for the single softwarelists.
Rompaths can't contain rompaths. Please check your setup again.
If you like I can have a look at your setup if you send me your *.cmp file for your used profile (cmpro settings folder) plus cmpro.ini.

312

clrmame Discussion / Re: Can't get Software List paths set up properly

« on: 29 November 2021, 06:58 »

Well, sounds like a bad setup.

The combined mode needs unique distinct rompaths per software list. Auto assign only really works if you already have paths with some sets of the belonging software lists since it's an easy best match count wins algorithm, i.e. if a folder holds 10 Atari 2600 sets and only 8 C64 sets, the path is assigned to the A2600 software lists. If no match is found, the 1st rompath is used.

24 hours sounds long. I assume you have recompress enabled which is not really needed or you're using compressed files which don't support that (e.g. solid 7z archives).

If you haven't touched your original rom collection, why should it be screwed. Sounds more like either accidently scanned it with a wrong datfile or used it as source for rebuilding and got remove-rebuilt enabled. And in either way, roms can't be lost, the scanner puts them in the backup folder and when you did a rebuild, you got them in the destination (unless you really ticked some weird options like disabling backup and remove-only in rebuilder).
If cmpro says that your path settings are invalid, then something is wrong, so you should recheck and give detailed information how you stored them and what cmpro complains about. Manually editing the cmp file is not a good idea. Better give a detailed example. Keep in mind that you can't have rompaths in rompaths and the general storing method is rompath\setname\file 1...file n or rompath\setname.zip (.rar/.7z).


For you, I recommended to use one profile per software list. Easier to setup, easier to maintain and in combination with the batcher you can run through all profiles at once.

313

clrmame Discussion / Re: sets without roms are reported as missing(?)

« on: 27 November 2021, 10:23 »

erm...no, this should not happen and actually I can't repeat it here.

Can you send me: your cmpro/settings/*.cmp file which belongs to your profile, I assume you're not using a dat but a direct MAME.exe import (if not, send me the dat, too) and cmpro.ini

314

clrmame Discussion / Re: How do I check ROMs/ISOs split across several directories?

« on: 04 November 2021, 16:33 »

well....as long as the used datfile holds all in one set defintion (so you got a trillion isos in just 1 set), you won't succeed in testing.
You need to either:
- buy a bigger hd

- or split up the datfile...which is pretty easy. Load the datfile in a texteditor and decide where you want to split it. Generate a second set instance which holds the files from your 2nd hd), save this datfile and load it in the profiler.

This solution of course has a downside....since you need to know which parts are on the first and which are on the second disk...

...or you change the dat completely to 1 iso per set...then you don't need to care which file is on which disk, but you have to follow the storing methology which is always:
rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.rar/.7z) for compressed sets where the archive holds file 1 ... file n

always keep in mind, usually a set contains more files, like a pacman arcade dump which is a collection of various IC rom dumps (sound, grafics, code,...

So in the last case you'd need to store isos separately in subfolders....

315

clrmame Discussion / Re: How do I check ROMs/ISOs split across several directories?

« on: 04 November 2021, 12:51 »

let's discuss terminology. For me one set corresponds to 1 game

A set is a collection of roms and/or samples and/or chds....so e.g. pacman (which only has roms)

Now there are collections out there where the datfile is structured to keep all games in one set....for example a NES collection which may have some thousand single nes files in one set "NES collection".

You've mentioned 6.26 TB as set size...so I think it's more one of the latter ones?

If so, you can modify the datfile used for scanning and simply break it into 2 sets....one holding files with for example 0-9-H and the other J-Z or something

316

clrmame Discussion / Re: How do I check ROMs/ISOs split across several directories?

« on: 04 November 2021, 12:31 »

Well, generally multiple rompaths aren't a problem since you can setup as much rompaths as you want (Settings->Rompaths).
If you now say that one set is split up on two drives....I actually wonder why

If you want to fix it, a rebuild to a new destination would be good thing to do where the source are your 2 folders (either drag'n drop or multiple rebuild runs or setup the 2 paths as addpaths)

If you want to keep one set split on two drives (I still don't see any usecase for that), you will run into issues during scanning since cmpro will complain that it found a set multiple times.

317

clrmame Discussion / Re: Bad URL...

« on: 20 October 2021, 07:51 »

Thanks....and yes...I should write one

318

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.

319

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.

320

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.