Please login or register.

Login with username, password and session length
Advanced search  


The new forum is online, hope you enjoy it!

Show Posts

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.

Messages - Roman

Pages: [1] 2 3 4 5 6 ... 150
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.

very interesting, thanks

clrmame Discussion / cmpro 4.044 released
« on: 29 November 2021, 15:40 »

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

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.

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....

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

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 :) ).

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 ;-)

"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.

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.

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

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....

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

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.

clrmame Discussion / Re: Bad URL...
« on: 20 October 2021, 07:51 »
Thanks....and yes...I should write one ;)

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.

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.

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.

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 :)

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.

Pages: [1] 2 3 4 5 6 ... 150

Page created in 0.142 seconds with 21 queries.