281
clrmame Discussion / Re: again problem with new tag
« on: 22 February 2022, 12:17 »
thanks, grab the newest version
- 23 April 2024, 07:45
- 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.
282
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
283
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)
284
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?
285
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.
286
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
287
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.
288
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.
289
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)
290
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....
291
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.
292
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?
293
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
294
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.....
295
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...
296
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).
297
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.
298
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 09 December 2021, 07:22 »
ok, let's take that the set "aceoface" with the one and only rom "aceofaeu.bin"....
where was it placed before? (O:\Games\Emulator\Mame\Software\a7800\ ?)
Was it compressed/archived (.zip/.7z/.rar) or decompressed?
You can limit the scan to that only set (set information dialog, uncheck all, only enable that one), so it would be interesting to know what the scan message shows....if it was removed there should be some fix unneeded prompt...I need the detailed information on that.
You're saying "amout of missing roms seems random"...which is actually a bit scary since it more sounds like a totally different issue (3rd party programs interfearing like virusscanners locking/blocking files or network connections failing (see SAMBA posts here on the forum)...so...can you give some detailed information about your setup. Is O: a network share?
where was it placed before? (O:\Games\Emulator\Mame\Software\a7800\ ?)
Was it compressed/archived (.zip/.7z/.rar) or decompressed?
You can limit the scan to that only set (set information dialog, uncheck all, only enable that one), so it would be interesting to know what the scan message shows....if it was removed there should be some fix unneeded prompt...I need the detailed information on that.
You're saying "amout of missing roms seems random"...which is actually a bit scary since it more sounds like a totally different issue (3rd party programs interfearing like virusscanners locking/blocking files or network connections failing (see SAMBA posts here on the forum)...so...can you give some detailed information about your setup. Is O: a network share?
299
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 08 December 2021, 09:37 »
Only had time for a quick view on it yet...
The fix unneeded screenshot looks good to me since it mentions a cpc_flop softwarelist set ("ace of aces (uk) (1985) [original] (weak sectors).dsk" ) which does not belong to a a7800 assigned rompath (I can imagine that the a7800 corresponds to the Atari 7800 software list).
In your "after" list I can see lots of "move to rompath" messages which all belong to pippin SL sets...Again, the message is correct since it seems that you've placed the pipping chds with their subfolders in a rompath which was assigned for standard MAME ones, not Software lists. Since the rebuilder does not move/create chds, they must have been moved there on a different way...maybe manually....
The other files now listed as missing in "after", well, you said you only did a rebuild in between....maybe such files were part of the dropped/source/addpath? Please double check the settings. If a new scan removed them, you'd be prompted, so please read carefully what the prompt says.
So, please double check your folders (a7800 folders shouldn't contain cpc sets) and try to minimize the problem to 1 set where you can say: It was correctly stored before the scan and it was removed completely afterwards. By the way...do you scan a network drive or anything else which may be special to your setup?
For example, focus on "11 A Side Soccer (UK) [softwarelist: cpc_cass - folder: 11assoc - size: 55kb]" (1st entry in "after" after the pippin messages) which was not listed in "before" but as missing in "after". Try to repeat that behaviour that "it disappears". Either the rebuild did something to it (but that can only mean that you used it as rebuilder source + remove rebuilt...but then it should exists in the destination) or the scanner, but then you should see a prompt.
The fix unneeded screenshot looks good to me since it mentions a cpc_flop softwarelist set ("ace of aces (uk) (1985) [original] (weak sectors).dsk" ) which does not belong to a a7800 assigned rompath (I can imagine that the a7800 corresponds to the Atari 7800 software list).
In your "after" list I can see lots of "move to rompath" messages which all belong to pippin SL sets...Again, the message is correct since it seems that you've placed the pipping chds with their subfolders in a rompath which was assigned for standard MAME ones, not Software lists. Since the rebuilder does not move/create chds, they must have been moved there on a different way...maybe manually....
The other files now listed as missing in "after", well, you said you only did a rebuild in between....maybe such files were part of the dropped/source/addpath? Please double check the settings. If a new scan removed them, you'd be prompted, so please read carefully what the prompt says.
So, please double check your folders (a7800 folders shouldn't contain cpc sets) and try to minimize the problem to 1 set where you can say: It was correctly stored before the scan and it was removed completely afterwards. By the way...do you scan a network drive or anything else which may be special to your setup?
For example, focus on "11 A Side Soccer (UK) [softwarelist: cpc_cass - folder: 11assoc - size: 55kb]" (1st entry in "after" after the pippin messages) which was not listed in "before" but as missing in "after". Try to repeat that behaviour that "it disappears". Either the rebuild did something to it (but that can only mean that you used it as rebuilder source + remove rebuilt...but then it should exists in the destination) or the scanner, but then you should see a prompt.
300
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 07 December 2021, 12:10 »
Well, can you give a single example about the "unneeded" messages? Or one of the thousands of missing roms messages?
I highly doubt that something gets lost since all unneeded files are put into the backupfolder...so please give an example here, too.
Your setup (split of chds and sets in different folders) won't work in SL combined mode unless you really only have Cubo BIOS sets and TaitoGNet files in the chds folder (since that's what you've setup in your config). For the combined mode, you need one unique path for the given bios/standard/device...so e.g. for Area51, you need area51.zip in the 'standard' assigned path and also a subfolder in there named area51 which contains the chd.
Keep in mind, chds need subfolders named after the set, that also happens for software lists.
So....I need more information about your setup....some examples which files are placed where and why message is shown......first impression is that the split of chds/roms into different folders is simply not what you can use in the combined SL mode....
If you want to keep it, you should switch to 1-profiler-per-sl mode.
I highly doubt that something gets lost since all unneeded files are put into the backupfolder...so please give an example here, too.
Your setup (split of chds and sets in different folders) won't work in SL combined mode unless you really only have Cubo BIOS sets and TaitoGNet files in the chds folder (since that's what you've setup in your config). For the combined mode, you need one unique path for the given bios/standard/device...so e.g. for Area51, you need area51.zip in the 'standard' assigned path and also a subfolder in there named area51 which contains the chd.
Keep in mind, chds need subfolders named after the set, that also happens for software lists.
So....I need more information about your setup....some examples which files are placed where and why message is shown......first impression is that the split of chds/roms into different folders is simply not what you can use in the combined SL mode....
If you want to keep it, you should switch to 1-profiler-per-sl mode.