141
clrmame Discussion / Re: clrmamepro 4.044b released
« on: 25 February 2022, 17:18 »
The packages were replaced.... now it's showing "b" ;-)
- 30 March 2023, 07:18
- Welcome, Guest
News:
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.
142
clrmame Discussion / clrmamepro 4.044b released
« on: 25 February 2022, 10:34 »
4.044b
fixed: xml parser comment/cdata issue (once and for all....)
4.044a
fixed: xml parser comment/cdata issue
fixed: falsely prompt for creating not existing but not active sysdefpaths
fixed: xml parser comment/cdata issue (once and for all....)
4.044a
fixed: xml parser comment/cdata issue
fixed: falsely prompt for creating not existing but not active sysdefpaths
143
clrmame Discussion / Re: MAME v0.241 snes.xml
« on: 25 February 2022, 08:59 »
oops...yes...my fault....gonna fix it today
144
clrmame Discussion / Re: again problem with new tag
« on: 22 February 2022, 12:17 »
thanks, grab the newest version
145
clrmame Discussion / Re: cmpro 4.044 released
« on: 11 February 2022, 17:29 »
nobody uses the merger, it's obsolete, don't use it
And also limiting the set list is not that common either....one place to do it is more than enough
And also limiting the set list is not that common either....one place to do it is more than enough
146
clrmame Discussion / Re: cmpro 4.044 released
« on: 08 February 2022, 14:07 »
SetInformation -> Select Sets (and all the other options there) enables/disables sets for all scenarios, scanner, rebuilder, merger. So it's a global setting.
You can see that in the window title that only a subset is active (then it lists something like x of y)
You can see that in the window title that only a subset is active (then it lists something like x of y)
147
clrmame Discussion / Re: RVZ Support?
« on: 22 January 2022, 13:23 »
Sorry but this is currently not planned. Would be interesting to see why RVZ was considered over CHD....since both seem to use LZHA and both are just a compressed container. Why reinventing the wheel?
148
clrmame Discussion / Re: Trying to use ProgrettoSnaps MAME datfiles, running into some trouble
« on: 18 January 2022, 20:39 »
Dats without crc32 won't work...easy as that. You need a given hash value to identify roms. Besides of that, it's 2022 and the current MAME version is .239....there is really no need to collect MAME sets by old versions. It's fun to see old dats...but preservation wise there is no need.
149
clrmame Discussion / Re: Merged Sets Scans
« on: 10 January 2022, 13:16 »
Again: Forget the miss/have lists. They don't check anything. They only look if pacman.zip is available or not (just to give an example). Such list generators don't check the content at all. The purpose of such list generators is (or was...since I said it was most likely used by 2,3 users back in 2000) to generate a list of pre-scanned sets.
So...look at the scan results tree output. Everything listed there needs fixing, no matter which merge mode you've chosen.
If you only looked at miss/have lists in the past, you were wrong
So...look at the scan results tree output. Everything listed there needs fixing, no matter which merge mode you've chosen.
If you only looked at miss/have lists in the past, you were wrong
150
clrmame Discussion / Re: Merged Sets Scans
« on: 09 January 2022, 11:35 »
"I thought that my merged sets were always complete until I used the 'non-merged' scan.
I've figured that I will just need to manage the clones/bootlegs via the 'non-merged' scan"
Sorry but that does not make any sense
The scanner shows all missing files (if you got any) when you run a scan with "you prefer -> merged". It will also list missing clones/bootlegs in the scan results tree output.
There is no reason at all to switch to "non-merged".
Do you have a specific example of a full merged set where the scanner doesn't show any issue but a MAME32 audit does?
There are some options in cmpro which may hide information from you (e.g. not enabling all systems, all sets, all chdtypes or completely hiding fully missing sets....), so maybe it's just such an option in your setup which makes you think it's not working as you expect.
I've figured that I will just need to manage the clones/bootlegs via the 'non-merged' scan"
Sorry but that does not make any sense
The scanner shows all missing files (if you got any) when you run a scan with "you prefer -> merged". It will also list missing clones/bootlegs in the scan results tree output.
There is no reason at all to switch to "non-merged".
Do you have a specific example of a full merged set where the scanner doesn't show any issue but a MAME32 audit does?
There are some options in cmpro which may hide information from you (e.g. not enabling all systems, all sets, all chdtypes or completely hiding fully missing sets....), so maybe it's just such an option in your setup which makes you think it's not working as you expect.
151
clrmame Discussion / Re: Merged Sets Scans
« on: 08 January 2022, 11:05 »
"miss" and "have" lists are simply doing a quick lookup by setname. It's not reliable at all and not really used for auditing purposes. Actually I think they aren't used in the last 20 years
The only real thing to do is using a scan and looking at the scan results tree window.
Not merged sets is also pretty uncommon. People use split or full merged sets. Personally I think split a bit more intuitive since you actually see the clone sets as arvchives and not included as files in the parents.
"How to you scan using "Merged" Sets for ROMs that are actually missing clones/bootlegs?"
So...first of all, you need to be sure what you mean with "merged". Split and Merged are both merged types, the latter one is "full merged", i.e. only parent set archives exists and the clone sets are part of them. Split means that you got an archive for each set (no matter if parent or clone) but the clone sets only hold the clone files and not again the shared ones from the parent. Keeping them split is (as far as I know) the most common method.
So to achieve your goal, simply choose the "you prefer" mode and do a scan (with fix options). Everything which appears in the scan results tree window then needs fixing.
The only real thing to do is using a scan and looking at the scan results tree window.
Not merged sets is also pretty uncommon. People use split or full merged sets. Personally I think split a bit more intuitive since you actually see the clone sets as arvchives and not included as files in the parents.
"How to you scan using "Merged" Sets for ROMs that are actually missing clones/bootlegs?"
So...first of all, you need to be sure what you mean with "merged". Split and Merged are both merged types, the latter one is "full merged", i.e. only parent set archives exists and the clone sets are part of them. Split means that you got an archive for each set (no matter if parent or clone) but the clone sets only hold the clone files and not again the shared ones from the parent. Keeping them split is (as far as I know) the most common method.
So to achieve your goal, simply choose the "you prefer" mode and do a scan (with fix options). Everything which appears in the scan results tree window then needs fixing.
152
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 16 December 2021, 08:13 »
Do NOT use the merger.
It's not compatible with the combined SL mode and will simply put equally named sets together.
It's an outdated module which actually has no real use since scanner and/or rebuilder do the same job better.
The normal "procedure" when a new MAME version is out is actually this:
- run a full scan with all fix options enabled (after that you should only have missing files, the newly added ones)
- drag'n drop the new files into the scanner window, this internally uses the rebuilder to add them. (requires a rebuilder where the destination points to your existing collection)
There is no need for Merger and there is no need for full rebuilder reruns (which I read here and there in the internet)
It's not compatible with the combined SL mode and will simply put equally named sets together.
It's an outdated module which actually has no real use since scanner and/or rebuilder do the same job better.
The normal "procedure" when a new MAME version is out is actually this:
- run a full scan with all fix options enabled (after that you should only have missing files, the newly added ones)
- drag'n drop the new files into the scanner window, this internally uses the rebuilder to add them. (requires a rebuilder where the destination points to your existing collection)
There is no need for Merger and there is no need for full rebuilder reruns (which I read here and there in the internet)
153
clrmame Discussion / Re: beginner with starting problems
« on: 13 December 2021, 17:25 »
what the ....
never ever happened here.....and I did some billion Windows 10 clean installations....
never ever happened here.....and I did some billion Windows 10 clean installations....
154
clrmame Discussion / Re: beginner with starting problems
« on: 13 December 2021, 16:46 »
If even cmp4044_64.exe (which is an installer) fails for you, most likely your virusscanner software blocks it.
155
clrmame Discussion / Re: beginner with starting problems
« on: 13 December 2021, 16:24 »
Simply download the latest version from https://mamedev.emulab.it/clrmamepro/#downloads. I'd go with the zipped version (and of course decide if 32 or 64bit depending on your system). Unpack it to a non UAC controlled folder (i.e. NOT C:\Program Files) and double click the exe. The zipfile holds all necessary dlls and files, so you don't need anything additional.
No need to modify or create any ini file on your own.
If you start it for the first time you'd should see a welcoming prompt in the middle of the screen after some seconds.
Which Windows 10 version do you have?
No need to modify or create any ini file on your own.
If you start it for the first time you'd should see a welcoming prompt in the middle of the screen after some seconds.
Which Windows 10 version do you have?
156
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 12 December 2021, 10:37 »
You can't have profiles based on the same mame.exe where one is with and one is without SL!
You will run into cache issues since the cache key is based on the binary's hash value, so the one without SL will load the cache information from the one with SL or vice versa (depending on which was created first). The only possibility would be to always clean the cache before loading one of such profiles. Every time!
And again, please stop creating new scenarios and focus on:
https://www.emulab.it/forum/index.php?topic=6337.msg21264#msg21264
You will run into cache issues since the cache key is based on the binary's hash value, so the one without SL will load the cache information from the one with SL or vice versa (depending on which was created first). The only possibility would be to always clean the cache before loading one of such profiles. Every time!
And again, please stop creating new scenarios and focus on:
https://www.emulab.it/forum/index.php?topic=6337.msg21264#msg21264
157
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 11 December 2021, 13:01 »
"It appears that the previous processes actually merge the arcade sets and SL sets into one parent."
And that's the only problem and open question you need to find an answer for.
You're always saying you did a scan which ends ok, then a rebuild and then another scan which shows unneeded (such "wrong merged" sets). So it seems that the rebuild operation added the files, but that's why I asked if the files don't exists before and are clearly created by the rebuilder (before the new scan and anything in between). We need to be clear on such steps before checking anything else.
The only thing I can think of is that you used the "MERGER" instead of the rebuilder in between...which can be the cause of this since that module is outdated and not really aware of SL.....
And that's the only problem and open question you need to find an answer for.
You're always saying you did a scan which ends ok, then a rebuild and then another scan which shows unneeded (such "wrong merged" sets). So it seems that the rebuild operation added the files, but that's why I asked if the files don't exists before and are clearly created by the rebuilder (before the new scan and anything in between). We need to be clear on such steps before checking anything else.
The only thing I can think of is that you used the "MERGER" instead of the rebuilder in between...which can be the cause of this since that module is outdated and not really aware of SL.....
158
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 10 December 2021, 08:25 »
Random indeed sounds weird.
I can tell you what I did for testing:
- clean cmpro installation (4.044 is current )
- added a profile "mame 0.238" based on official mame.exe, imported the data with all SL enabled, all prompts answered with OK/YES
- quit cmpro, generated all your "O:" paths, replaced cmpro.ini and mame 0.238.cmp with your files
- put your provided aceoface zip (which actually includes all a7800 and cpc_flop versions) in your rebuilder source folder
- ran cmpro again, did a scan...everything was missing...well...sounds good
- ran a rebuilt
- ran a scan again, nothing is unneeded and the rebuilt files were ok (cpc in the cpc folder, a7800 ones in the a7800 path)
Did that several times....it is always ok...
Maybe you can setup such a clean install, separated scenario, too....maybe on a different drive...that "random" thing sounds really a bit like something is weird...maybe just bad cache data...
I can tell you what I did for testing:
- clean cmpro installation (4.044 is current
)- added a profile "mame 0.238" based on official mame.exe, imported the data with all SL enabled, all prompts answered with OK/YES
- quit cmpro, generated all your "O:" paths, replaced cmpro.ini and mame 0.238.cmp with your files
- put your provided aceoface zip (which actually includes all a7800 and cpc_flop versions) in your rebuilder source folder
- ran cmpro again, did a scan...everything was missing...well...sounds good
- ran a rebuilt
- ran a scan again, nothing is unneeded and the rebuilt files were ok (cpc in the cpc folder, a7800 ones in the a7800 path)
Did that several times....it is always ok...
Maybe you can setup such a clean install, separated scenario, too....maybe on a different drive...that "random" thing sounds really a bit like something is weird...maybe just bad cache data...
159
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 10 December 2021, 07:25 »
Sorry but posting screenshots doesn't really help. Please focus on one set as I said before.
Don't get me wrong, I really appreciate your testing, but we need to find something which can be repeated in a small scenario.
If you get random effects, something totally different (even maybe outside of clrmamepro) might cause it. So try to limit scans, maybe do a clean cmpro installation or setup a new clean profile from scratch.
From what you've said and showed, I see no problems with the scanner since it always reported things which do make sense.
The old scenario was:
you've got a rather good sets with maybe some files missing, you do a rebuild and another scan then shows unneeded files which of course should not happen. And here it is important to only look at one of now unneeded files. Did it exists before the rebuild (hopefully no) and did it appear after the rebuild (but before the scan). This information would be important since it would clearly show that the rebuilder added the files.
In the concrete example it was an ace of aces set (a cpc_flop SL set) which was rebuilt to a path which from the name implies to be the a7800 SL list.
Surely the scanner afterwards complains about it that it's unneeded there.
So the question is: Is this small scenario repeatable? And if so, why does the rebuilder put files there. I've tested that and I can't repeat it. I will do another round with your latest provided cmp/ini files (thanks for that).
Don't get me wrong, I really appreciate your testing, but we need to find something which can be repeated in a small scenario.
If you get random effects, something totally different (even maybe outside of clrmamepro) might cause it. So try to limit scans, maybe do a clean cmpro installation or setup a new clean profile from scratch.
From what you've said and showed, I see no problems with the scanner since it always reported things which do make sense.
The old scenario was:
you've got a rather good sets with maybe some files missing, you do a rebuild and another scan then shows unneeded files which of course should not happen. And here it is important to only look at one of now unneeded files. Did it exists before the rebuild (hopefully no) and did it appear after the rebuild (but before the scan). This information would be important since it would clearly show that the rebuilder added the files.
In the concrete example it was an ace of aces set (a cpc_flop SL set) which was rebuilt to a path which from the name implies to be the a7800 SL list.
Surely the scanner afterwards complains about it that it's unneeded there.
So the question is: Is this small scenario repeatable? And if so, why does the rebuilder put files there. I've tested that and I can't repeat it. I will do another round with your latest provided cmp/ini files (thanks for that).
160
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 09 December 2021, 11:04 »
(This is actually a reply to the post before.....you've updated the forum in between....)
Several things happen here:
the scanner is right in removing the files since (according to the names) they aren't a7800 files at all, they are cpc_flop ones and so the scanner is fully right with removing them since they don't belong there.
backup is correctly created, so no files are lost.
"the removed ones are reported as missing"...well, maybe because they are missing for the cpc_flop software list
"running a rebuilder from the backup path does not recreate anything". Can be various reasons: e.g. the files do exists in their right destination already...rebuilder log could be useful.
But there is one main question:
where do the cpc_flop sets in the a7800 folder come from?
Did the rebuilder put them there? Are you sure that before rebuilding they are not in the a7800 folder and the rebuilder puts them there? Since I can't repeat that behaviour at all with the settings at all (7800 files are rebuilt to the assigned 7800 folder and cpc_flop to the assigned cpc_flop one) it's hard to say what is going on on your system.
Maybe you used a different profile for rebuilding with different settings?
Double check the assigned folders for cpc_flop and a7800.
Can you please send me (again): your *.cmp file for the used profile, cmpro.ini
The merge mode should not matter at all.
Several things happen here:
the scanner is right in removing the files since (according to the names) they aren't a7800 files at all, they are cpc_flop ones and so the scanner is fully right with removing them since they don't belong there.
backup is correctly created, so no files are lost.
"the removed ones are reported as missing"...well, maybe because they are missing for the cpc_flop software list
"running a rebuilder from the backup path does not recreate anything". Can be various reasons: e.g. the files do exists in their right destination already...rebuilder log could be useful.
But there is one main question:
where do the cpc_flop sets in the a7800 folder come from?
Did the rebuilder put them there? Are you sure that before rebuilding they are not in the a7800 folder and the rebuilder puts them there? Since I can't repeat that behaviour at all with the settings at all (7800 files are rebuilt to the assigned 7800 folder and cpc_flop to the assigned cpc_flop one) it's hard to say what is going on on your system.
Maybe you used a different profile for rebuilding with different settings?
Double check the assigned folders for cpc_flop and a7800.
Can you please send me (again): your *.cmp file for the used profile, cmpro.ini
The merge mode should not matter at all.