Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

3281

clrmame Discussion / clrmamepro 3.130a released

« on: 12 August 2009, 22:58 »

Still busy with real life...so again, something in between:

3.130a

rename wizard:
  - improved fuzzy name compare
  - don't allow identical new names, the one with the best method wins

misc: don't replace illegal chars in description tags until you use it for writing
misc: reapplying setinformation options "incl.clones/parents" on profile load, this
      can be useful if you limit sets with "available sets" (and the parent/clone options)
      to auto-enable some renamed sets on dat update. However you still should recheck
      the limit sets after an update since limiting sets is not robust against massive renames.
misc: improved chd decompress and check hash routines slighly

fixed: checkbox init of scanner->Hash&CHD->CHD MD5/SHA1 is not always correct
fixed: header support getRealSize was still broken

3282

clrmame Discussion / Re: clrmamepro 3.130 released

« on: 09 August 2009, 11:18 »

There shouldn't be any difference in speed when rebuilding from the same folder. Only if the number of rebuilt files is bigger than for the other dat. Of course when writing the file to the destination folder, several checks are done there, too.

However, you may want to find out which file takes longer than the others...just did some rebuilts with that header definition enabled and I don't spot any speed decrease for the testfiles.....

3283

clrmame Discussion / #0020 - why limiting sets is not a good idea

« on: 07 August 2009, 06:26 »

As you might know, you can use several filters in Scanner->Set Information to scan only *some* sets of a dat.
There are some reasons why this limiting is a good idea, but people should be aware of sideeffects:

A user wondered if there were sets removed from MAME 133 to 133u1.
After some discussion he mentioned that he only has some sets enabled.

Well, there's the answer to his problem. He did not scan all sets.
He did limit the known sets by disabling them (by only enabling some) in setinfo.
This means the 'new names' of u1 are unknown and so the wrong named sets are listed as unneeded.

Limiting sets is not a good idea anyway. Why do users want to limit them? Because they don't want to see 19247394714 missing set information if they only have 3 sets.

Solution: Keep all sets enabled!!! Hide fully missing set messages via Scanner->View (popupmenu)->Hide Fully Missing Sets.

3284

clrmame Discussion / clrmamepro 3.130 released

« on: 06 August 2009, 22:14 »

3.130

a somehow "in between" release. Since I'm currently preparing a house move I
better release what I got at the moment....

added:

1st part of the upcoming new toy "Rename Wizard".

You may know about the major set renames in latest MAME, well the Rename Wizard
should help you in the future to update e.g. related datfiles (like artwork
datfiles, etc...). The basic idea is: Load an old datfile and a new datfile.
Find set renames. Apply the renames to a third datfile (e.g. artwork) either
to rom or set level and save this dat. So the 1st step is to find set renames.

Logiqx's MAMEDIFF is usually used for such a thing but MAMEDIFF isn't as
accurate as you might think. So Logiqx and myself though about other ways to
find renames. The current idea is a 6-path check (from highest to lowest prio).


1) unique set hash compare
Hash is created over all rom/disk hashes and in case of nodumps or samples over
names. Hash lookup tries to find a matching set.

2) single unique rom hash compare:
Take a single unique rom hash of old datfile
set and check if it's a single unique hash in new datfile. Use this to find a
matching set

3) single unique chd hash compare:
similar to 2) but on chds

4) fuzzy name check:
similar to cmpro's scanner set name check. Tries to find the 'best fit' name

5) lazy description compare:
try to match the descriptions

6) lazy set compare:
try to match the setname


Currently a complete set list is produced showing something like:

old name -> new name [succeeded matching method]
*old name -> new name [succeeded matching method]
old name -> ? (when no match was found....propably a removed set)
The * indicates a name change.


This part is already in...you can play around with it if you like.

The next steps will be:

- optionally disallow parent-to-clone renames (since a lot of dats
work on parent sets only)
- load and apply changes on 3rd datfile

The Rename Wizard is not directly visible at the moment...but still easy to find.
Check out popup menus if you want to know more ABOUT it.





added: warning when 'Sets' scan option is not enabled
added: dir2dat option to create a 0 byte file for empty folders
misc: show common rebuilder warnings only once and not per addpath
misc: improved fuzzy set name check
fixed: xml dats with UTF ByteOrderMark aren't listed in profiler
fixed: when using header support, rom size values are wrong
fixed: offline datfiles 0 crc/ 0 size issue

3285

clrmame Discussion / Re: Missing Sets

« on: 05 August 2009, 13:18 »

clrmamepro is absolutely right in reporting these sets as missing.

These sets are chd-only sets, i.e. they don't have roms (so of course a rom scan doesn't show any missing roms).

Since you're scanning for missing sets and don't have the sets, clrmamepro reports them correctly as missing.
If you'd enable the chd scan, too, you'd also get missing chd messages.

Keep in mind: a Set is a collection of roms and/or chds and/or samples.

For these chd-only sets you need the chd.

However you can fool cmpro's set check by simply creating rompath subfolders for the chds in question. A missing chd scan will still report the missing chds of course.


This is also described in http://www.emulab.it/forum/index.php?topic=22.msg67#msg67

3286

clrmame Discussion / Re: REQ: changed recognition of updated dats

« on: 03 August 2009, 17:33 »

The update detection is not based on the filename but the name tag inside the datfile.

3287

clrmame Discussion / Re: Clrmamepro not giving me option to scan mame 133b roms in merged sets mode?

« on: 29 July 2009, 05:48 »

Don't disable it

...for example, as any other checkbox you got the option to hide/show belonging listed warnings (after a scan).

3288

clrmame Discussion / Re: [3.129] DATs with headers support bug

« on: 28 July 2009, 22:00 »

use these until a new version is out:


32bit: http://mamedev.emulab.it/clrmamepro/binaries/header_fix_cmpro.rar
64bit: http://mamedev.emulab.it/clrmamepro/binaries/header_fix_cmpro64.rar

3289

clrmame Discussion / Re: [3.129] DATs with headers support bug

« on: 28 July 2009, 20:14 »

You're sure you enabled the belonging header definition?

If yes, send me a datfile in question + the used header xml and an explanation what is reported wrong. When using header support, the sizes and checksums are from the file without the header of course.

3290

clrmame Discussion / Re: Clrmamepro not giving me option to scan mame 133b roms in merged sets mode?

« on: 28 July 2009, 17:24 »

ok..let's rephrase rule 1: as a standard user, don't disable sets. As a pro you know that there are other things to do with it

3291

clrmame Discussion / Re: Clrmamepro not giving me option to scan mame 133b roms in merged sets mode?

« on: 28 July 2009, 14:24 »

ok..rule #1: There is no reason on earth to disable the "SETS" option.

A set is a collection of roms and/or samples and/or chds.

Pacman is a set which consists of let's say 10 single roms. Sets have parent/clone relation ships. You can merge sets. You can store sets packed or unpacked.

The general storing method is: rompath\setname\file 1... file n for unpacked sets and rompath\setname.zip (.rar/.7z) for packed sets.

Having "sets" enabled, the cmpro checks check for example if "pacman.zip" is correctly named, while with only "roms" enabled it will look inside "pacman.zip" to see if the single rom files are correctly named. Similar applies to unneeded...."blabla.zip" in a rompath can be an unneeded set....maybe it's a valid set with a wrong name.....
Unneeded check on "roms" will look inside "pacman.zip" and maybe detects a readme.txt as unneeded.

So I think it should be clear now:

SET checks/fixes work *on* sets (the archives if you like to call it this way) and ROMS checks/fixes work *in* the sets.


again, rule #1: There is no reason on earth to disable the "SETS" option. So keep it enabled!!!!!!

3292

clrmame Discussion / clrmamepro 3.129 released

« on: 27 July 2009, 23:03 »

3.129

misc:  added some more support for offline dats. Parsing romTitle tags etc...
misc:  don't allow "." at the end of a rom name anymore
misc:  parser warning about double named rom entries but different hashes include nodumps (MESS .133)
misc:  fixing an unpacked wrong file name (where the new name already exists) backups and replaces the existing file now instead of reporting not-fixed.
fixed: batcher-rebuilder always scan/never scan subfolder options aren't saved correctly

3293

clrmame Discussion / Re: clrmame and MESS 0.133

« on: 27 July 2009, 20:13 »

it's automatically enabled but currently it only works for non nodumps. In the next version I enabled it for nodumps, too....so it will rename one file (most likely the good dump....but hey...it's a start)

3294

clrmame Discussion / Re: clrmame and MESS 0.133

« on: 27 July 2009, 19:03 »

well...a quick fix would be to enable the current "detect double named roms with different hashes" check for nodumps as well...This would prompt for either removing the file or renaming it. However it doesn't prefer the non-nodumps...so that the good dump might get a different name.

3295

clrmame Discussion / Re: clrmame and MESS 0.133

« on: 27 July 2009, 18:39 »

hmm..nice finding...I will do some further checks on this. Thanks

3296

clrmame Discussion / Re: clrmame and MESS 0.133

« on: 27 July 2009, 17:15 »

That file is a nodump file, i.e. it does not exist, it's not yet dumped.

Looks like MESSUI falsely complains about nodumps.

Clrmamepro doesn't list nodumps as missing (since they don't exists) unless you use a datfile which forces nodumps as needed.

3297

clrmame Discussion / Re: Clrmamepro not giving me option to scan mame 133b roms in merged sets mode?

« on: 27 July 2009, 14:23 »

Possible reasons:

- you've loaded a datfile which does not have any parent/clone relationships defined
- you've loaded a datfile which uses "force merge mode" settings
- (most likely) during parsing the mame data you see several warnings about sets which can't be merged since they contain equally named files with different hashes. Merging them would kill one file as long as you don't use subfolders. clrmamepro shows a warning and asks you if you want to remove the parent/clone relation from them or force you to split-merged mode.

Go to profiler, click clean cache and reload the datfile to get the prompts again (and be sure to have "show common" enabled in Profiler->options->datfile errors)

3298

clrmame Discussion / Re: 2 issues, 1 request

« on: 27 July 2009, 11:31 »

ok...regarding 2) I will have a look. Sounds like it's for unzipped files only.....but if it's a png inside a set then the "move wrong named set to backup" doesn't play a role since we then talk about a "rom" and not about a "set". Anyway, I will have a look

3) nope, backup root stays global for now. I put it on my wish list that there should be an option to switch between global and local ones......but don't count on it in the near future.

3299

clrmame Discussion / Re: clrmame and MESS 0.133

« on: 27 July 2009, 06:21 »

I will have a look later today

3300

clrmame Discussion / Re: 2 issues, 1 request

« on: 27 July 2009, 06:21 »

1) I will have a look
2) for this the belonging scanner advanced option (move not renamed sets to backup) has to be enabled (if you got it enabled, send me example files where it doesn't work for you)
3) actually the backupfolder is a a general setting but only specifies the rootname. Each datfile produces its own subfolder in there.