181
clrmame Discussion / Re: Rebuilder 0.02 released
« on: 07 September 2022, 06:41 »
This is currently not planned.....how much is "a lot of diskspace"? Late MAME update added >320GB unique chds....so...everything is relative....
- 18 April 2024, 22:13
- 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.
182
clrmame Discussion / Re: Slow MAME SNAP.ZIP scan and rebuild with 4.046b
« on: 04 September 2022, 08:33 »
The only time killers for snaps are: Fix Missing and maybe Scanner->Advanced->>Deeper check for fixable missing files.
If they are turned off scanning them should rather fast.
Of course it depends a bit how the snaps set is stored. Since it's one big set with thousands of pngs, any fixing operation is time intensive on it. Especially if you keep the files in a solid 7z archive for example. Then it's pretty normal that it takes hours if it has to fix lots of files (it would recompress the data over and over again).
You can try to use the rebuilder to add the update sets from progetto and then do a scan without any fix operations to see what's still wrong.....
...or think about storing them decompressed
If they are turned off scanning them should rather fast.
Of course it depends a bit how the snaps set is stored. Since it's one big set with thousands of pngs, any fixing operation is time intensive on it. Especially if you keep the files in a solid 7z archive for example. Then it's pretty normal that it takes hours if it has to fix lots of files (it would recompress the data over and over again).
You can try to use the rebuilder to add the update sets from progetto and then do a scan without any fix operations to see what's still wrong.....
...or think about storing them decompressed
183
clrmame Discussion / Re: Slow MAME SNAP.ZIP scan and rebuild with 4.046b
« on: 03 September 2022, 11:57 »
What do you expect when you run WINE ;-) Surely it's slower. clrmampro is a native windows program, no support for weird emulation bugs sorry ;-)
I don't keep older versions, however I bet you can find it somewhere....but still, there were no changes regarding speed and if it's already slow for you to toggle a radio button, it sounds more like a WINE issue.
I don't keep older versions, however I bet you can find it somewhere....but still, there were no changes regarding speed and if it's already slow for you to toggle a radio button, it sounds more like a WINE issue.
184
clrmame Discussion / Re: 7z archives
« on: 03 September 2022, 11:53 »
Solid archives are archives where you need to recompress the full archive when you do an add or delete action on it. They are usually smaller than the not-solid variant but require more effort on updating. Users which want to minimize the archives as much as possible tend to use solid archives.
However, I've just tested a solid and a non solid 7z archive and removal works in both cases.
So you should check if you got an up2date 7z (I'm using 7-Zip 22.01) and 7z.exe must be available via your %PATH% environment variable (or you specify the full path to it in compressor settings). If it still doesn't work for you, the archive in question might have a problem, you could try to use the commandline to manually run 7z.exe d -y -ms=off -mx9 archivename file_in_archive on it to see if this is working.
However, I've just tested a solid and a non solid 7z archive and removal works in both cases.
So you should check if you got an up2date 7z (I'm using 7-Zip 22.01) and 7z.exe must be available via your %PATH% environment variable (or you specify the full path to it in compressor settings). If it still doesn't work for you, the archive in question might have a problem, you could try to use the commandline to manually run 7z.exe d -y -ms=off -mx9 archivename file_in_archive on it to see if this is working.
185
clrmame Discussion / Re: Slow MAME SNAP.ZIP scan and rebuild with 4.046b
« on: 03 September 2022, 08:22 »
again...define "runs slow"...where? What do you do? Scanning? Rebuilding? Which sets (e.g. snaps are something totally different than MAME sets), are they compressed or not etc..etc... WINE on its own is of course already a problem....but you can simply exchange cmpro with an older version to see if there's a difference. The changes from 4.045 to 4.046b are not scanner/rebuilder related, they only fix stuff in underlying structures
186
clrmame Discussion / Re: 7z archives
« on: 03 September 2022, 08:13 »
Deletion in 7z archives works fine here.
Maybe double check your Settings->Compressor->7z settings. The default value for Delete is: d -y -ms=off -mx9 %1 %2
Maybe you're using solid archives, then you may have to adjust the command line parameters.
Maybe double check your Settings->Compressor->7z settings. The default value for Delete is: d -y -ms=off -mx9 %1 %2
Maybe you're using solid archives, then you may have to adjust the command line parameters.
187
clrmame Discussion / Re: Slow MAME SNAP.ZIP scan and rebuild with 4.046b
« on: 02 September 2022, 14:52 »
Ah....you're scanning snaps....sorry...didn't see that (even when it's listed as the topic ;-))
Turn off fix missing....and usually it's better to keep them decompressed.
The reason is that progettosnaps usually add placeholder dummy pics for a couple (and that can be hundreds) of sets which cmpro can detect and add. But this "look into the current zip, find the file, add it" (and that some hundred times) can really slow down the process. So...turn off "fix missing". Usually adding the missing ones with the rebuilder is faster.
Turn off fix missing....and usually it's better to keep them decompressed.
The reason is that progettosnaps usually add placeholder dummy pics for a couple (and that can be hundreds) of sets which cmpro can detect and add. But this "look into the current zip, find the file, add it" (and that some hundred times) can really slow down the process. So...turn off "fix missing". Usually adding the missing ones with the rebuilder is faster.
188
clrmame Discussion / Re: Slow MAME SNAP.ZIP scan and rebuild with 4.046b
« on: 02 September 2022, 14:15 »
How should I know what happened ;-)
There were no changes from 4.045 to 4.046b which were anyhow speed related. And since noone else reported such a slow down, it must be something on your end.....could be anything...from a busy hd (due to other threads accessing it, incl. virusscanners), to bad network drivers when it's a net drive, etc...etc.
Or maybe you've enabled things like sha1 checking or other time consuming options.
So...."What happened" is nothing I can give an answer to.
"Here it runs fine and fast"
There were no changes from 4.045 to 4.046b which were anyhow speed related. And since noone else reported such a slow down, it must be something on your end.....could be anything...from a busy hd (due to other threads accessing it, incl. virusscanners), to bad network drivers when it's a net drive, etc...etc.
Or maybe you've enabled things like sha1 checking or other time consuming options.
So...."What happened" is nothing I can give an answer to.
"Here it runs fine and fast"
189
clrmame Discussion / Re: Clarification with Merged sets, roms, CHDs and their relationships
« on: 02 September 2022, 06:02 »
"Why someone would not to parse the merge attribute (as declared inside M. A. M. E.'s XML) of a clone's rom name?"
Let's get back in time....clrmamepro was there before merging was there....and parent/clone relationships did exist before mamedevs introduced merge attributes. And there was a time where merge attributes were completely wrong or each rom had one and so on....back then it was not so reliable as today.
So...coming back from such ancient times, there needed to be a way to see which roms were shared and which were unique within a parent/clone relationship. clrmamepro did that by hash and name compare, i.e. identical hashes with different names were still 2 unique roms. And that's exactly what happens when you disable that option (which is enabled by default by the way). So it's a just a different way of finding out which roms are and which aren't shared.
Same applies for disk merge attributes.
"Hash Collision"
There are parent/clonerelations where roms have identical names but different hashes. So if you fully merge them, one gets overwritten. Unless you put them in subfolders. MAME would load them fine in subfolders when you use 7z/zips. So to prevent data loss when using full merged sets, cmpro can create such a subfolder for you (usually the name of the set but you can change it). "Single File" means, only the file in question gets the subfolder, single clone means, all (clone) files belonging to the clone with the hashcollision get the subfolder, "all clones in relationship" means, all clone files (there can be n clones for 1 parent) get the subfolder. So this option is more a matter of taste/cosmetics, e.g. if you want all or just single files with a subfolder.
"Normal mode" means, that only the set with a hash collision gets subfolders while "Hash Collision Name" means all sets (no matter if they have a collision or not". So with the latter one, you store your fully merged sets where the parent holds its roms on root level of the archive and each clone has a subfolder on its own.
"Your example"
It is correct for split merge mode.
For full merge mode, you wouldn't have mame/hotd4a/dvp-0003a.chd since it's a clone and also for chds, you would put them to the parent...so you'd have mame/hotd4/dvp-0003a.chd and mame/hotd4/dvp-0003b.chd.
Last but not least: This storing mechanism and tricks with subfolders to prevent overwriting of hash collisions isn't defined. MAME itself doesn't care. It follows the romof and deviceRef chain to locate files and doesn't care about names when loading, it loads by hash compare (at least when we talk about archived files).
Let's get back in time....clrmamepro was there before merging was there....and parent/clone relationships did exist before mamedevs introduced merge attributes. And there was a time where merge attributes were completely wrong or each rom had one and so on....back then it was not so reliable as today.
So...coming back from such ancient times, there needed to be a way to see which roms were shared and which were unique within a parent/clone relationship. clrmamepro did that by hash and name compare, i.e. identical hashes with different names were still 2 unique roms. And that's exactly what happens when you disable that option (which is enabled by default by the way). So it's a just a different way of finding out which roms are and which aren't shared.
Same applies for disk merge attributes.
"Hash Collision"
There are parent/clonerelations where roms have identical names but different hashes. So if you fully merge them, one gets overwritten. Unless you put them in subfolders. MAME would load them fine in subfolders when you use 7z/zips. So to prevent data loss when using full merged sets, cmpro can create such a subfolder for you (usually the name of the set but you can change it). "Single File" means, only the file in question gets the subfolder, single clone means, all (clone) files belonging to the clone with the hashcollision get the subfolder, "all clones in relationship" means, all clone files (there can be n clones for 1 parent) get the subfolder. So this option is more a matter of taste/cosmetics, e.g. if you want all or just single files with a subfolder.
"Normal mode" means, that only the set with a hash collision gets subfolders while "Hash Collision Name" means all sets (no matter if they have a collision or not". So with the latter one, you store your fully merged sets where the parent holds its roms on root level of the archive and each clone has a subfolder on its own.
"Your example"
It is correct for split merge mode.
For full merge mode, you wouldn't have mame/hotd4a/dvp-0003a.chd since it's a clone and also for chds, you would put them to the parent...so you'd have mame/hotd4/dvp-0003a.chd and mame/hotd4/dvp-0003b.chd.
Last but not least: This storing mechanism and tricks with subfolders to prevent overwriting of hash collisions isn't defined. MAME itself doesn't care. It follows the romof and deviceRef chain to locate files and doesn't care about names when loading, it loads by hash compare (at least when we talk about archived files).
190
clrmame Discussion / Re: Exclude a whole driver?
« on: 24 August 2022, 17:49 »
yeah..just saw the cpp files ;-)
191
clrmame Discussion / Re: Exclude a whole driver?
« on: 24 August 2022, 17:46 »
hi John,
no...I didn't hear yet....(makes me a bit nervous though...)
You can exclude on source file name.....for example:
Scanner->SetInformation->SelectSets->%s=konami/kpython.cpp -> Apply
This would enable the kpython.cpp ones.... Then hit invert (so you get all enabled except the kpython ones) and check "initial invert" (so this simulates the invert click on each startup)
update: Hmm...I see some driver updates...with some ;-) new machines....and a software list....time to get some more hd space I guess
no...I didn't hear yet....(makes me a bit nervous though...)
You can exclude on source file name.....for example:
Scanner->SetInformation->SelectSets->%s=konami/kpython.cpp -> Apply
This would enable the kpython.cpp ones.... Then hit invert (so you get all enabled except the kpython ones) and check "initial invert" (so this simulates the invert click on each startup)
update: Hmm...I see some driver updates...with some ;-) new machines....and a software list....time to get some more hd space I guess
192
clrmame Discussion / Re: [PROFILER] CANNOT manually add M. A. M. E.'s XML (-listxml)
« on: 22 August 2022, 06:59 »
Powershell redirects data in utf16 by default (and redirecting is very slow in powershell, too).
So you need to run it with utf8 encoding in powershell:
mame.exe -listxml | out-file mame.xml -encoding utf8
If you only need to use the data in clrmamepro, you don't even need to run this manually, you can simply use Profiler->Create and let cmpro point to your mame exe file.
So you need to run it with utf8 encoding in powershell:
mame.exe -listxml | out-file mame.xml -encoding utf8
If you only need to use the data in clrmamepro, you don't even need to run this manually, you can simply use Profiler->Create and let cmpro point to your mame exe file.
193
clrmame Discussion / Re: [PROFILER] CANNOT manually add M. A. M. E.'s XML (-listxml)
« on: 21 August 2022, 17:48 »
?What file are you talking about?
The full driver xml from the official page (https://github.com/mamedev/mame/releases/download/mame0246/mame0246lx.zip) works fine and also a simple redirected mame -listxml.
Maybe you've compiled one yourself and the -listxml output is simply broken/incomplete (which can happen on not clean compiles).
194
clrmame Discussion / clrmamepro 4.046b released
« on: 18 August 2022, 14:01 »
4.046b
fixed: unsorted disk array can rarely cause random unneeded chd messages
fixed: unsorted disk array can rarely cause random unneeded chd messages
195
clrmame Discussion / Re: clrmamepro 4.046a released
« on: 18 August 2022, 13:20 »
thanks...ah found it...nice one....a wrong sorted chd vector (nocase instead of lowercase)...which only failed for your dat.....that's in since ages...nice finding
196
clrmame Discussion / Re: clrmamepro 4.046a released
« on: 18 August 2022, 04:48 »
Can you give me a concrete example please? Which chd is stored where and is listed as unneeded. And since you mentioned a datfile, can you send me that one plus the belonging .cmp file from cmpro‘s settings folder and cmpro.ini please.
197
clrmame Discussion / Rebuilder 0.02 released
« on: 16 August 2022, 15:25 »
2022-08-16 V0.02 released
- since MAME can't handle subfolders in decompressed sets, decompressed sets and chds are always stored flat in folders (no clone/dependency subfolders in full or standalone mode). When kept compressed, the archives will hold subfolders
- not existing romOf reference leads to removed merge information for the machine
- since MAME can't handle subfolders in decompressed sets, decompressed sets and chds are always stored flat in folders (no clone/dependency subfolders in full or standalone mode). When kept compressed, the archives will hold subfolders
- not existing romOf reference leads to removed merge information for the machine
198
clrmame Discussion / clrmamepro 4.046a released
« on: 16 August 2022, 13:41 »
4.046a
fixed: support for other sample extensions is broken
fixed: more compatibility for standalone rebuilder tool in handling disk names in full merged mode (hash collision mode) (revert in 4.046a)
fixed: more compatibility for standalone rebuilder tool in handling of devices with romof attributes in full merged mode
misc: updated 7zip sdk/dll tp 2201
fixed: support for other sample extensions is broken
fixed: more compatibility for standalone rebuilder tool in handling disk names in full merged mode (hash collision mode) (revert in 4.046a)
fixed: more compatibility for standalone rebuilder tool in handling of devices with romof attributes in full merged mode
misc: updated 7zip sdk/dll tp 2201
199
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 23:08 »
ok...I just saw that MAME itself can't load clone chds from a subfolder. I will rollback that disk requirement in hash collision name mode.
gimme a day
gimme a day
200
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 17:11 »
no I did not...if you'd follow the right storing method you'd fine :-)
fix-missing is your problem...so for now, turn if off till I've fixed it...you can solve your problem manually or with the new rebuilder anyhow ;-)
fix-missing is your problem...so for now, turn if off till I've fixed it...you can solve your problem manually or with the new rebuilder anyhow ;-)