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 7 8 9 10 ... 160
clrmame Discussion / Re: help - un-merging a CHD collection
« on: 07 September 2022, 09:33 »
It works fine here.....if they are moved to backup they most likely aren't valid?
You've got all check/fix options enabled (and you only got all the chds on rompath root level there, so they can get sorted back?)


Set:   AI Igo (Jpn)
Name:   aiigo
File:   E:\Temp\test\ai igo (japan).chd

Wrong Place:   E:\Temp\test\ai igo (japan).chd
Right Place:   E:\Temp\test\aiigo\ai igo (japan).chd

Do you want to move the CHD?

Where a profile was created on saturn.xml and e:\temp\test is a rompath and one of the chds was moved to that rompath root. It detects the wrong placed chd and creates and moves the chd to the belonging subpath

clrmame Discussion / Re: help - un-merging a CHD collection
« on: 07 September 2022, 09:02 »
Are there any parent/clone relationships? hmm...ok...but there are most likely only unique disks...so you may currently have a parent subfolder with multiple chds in it.

Old clrmamepro:
move all chd files on a rompath root, run a scan in unmerged or split mode and it should sort the chds in the correct subfolders

Rebuilder tool:
rebuilder -x saturn.xml -m standalone -r -i 'yourOldPath' -o 'yourNewPath' -d

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

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

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.

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.

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

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.

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.

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"

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

clrmame Discussion / Re: Exclude a whole driver?
« on: 24 August 2022, 17:49 »
yeah..just saw the cpp files ;-)

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

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.

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

clrmame Discussion / clrmamepro 4.046b released
« on: 18 August 2022, 14:01 »
fixed: unsorted disk array can rarely cause random unneeded chd messages

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

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.

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

clrmame Discussion / clrmamepro 4.046a released
« on: 16 August 2022, 13:41 »
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

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 160

Page created in 0.124 seconds with 20 queries.