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.

3381

clrmame Discussion / Re: unable to rebuild certain filenames

« on: 16 August 2009, 16:14 »

well...
a) it does use a weird character in the filename which is suspicious
and b) for testing I need the belonging datfile...so send me that
and c) if you want to rebuild weird characters you need to disable the oem/ansi conversion in settings->compressor->general

3382

clrmame Discussion / Re: Rename Wizard wip

« on: 14 August 2009, 21:13 »

ok..new version up...

- linefeeds in files should be fine now
- assertion in 6th check fixed
- correct handling of newly added sets (the thrild2 issue mentioned before)
- correct showing the * in all cases (the other thrild2 issue mentioned before)


http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090814.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090814.rar


now looking into tweaking the best guess check....

3383

clrmame Discussion / Re: Rename Wizard wip

« on: 14 August 2009, 19:21 »

yeah..as I said..I'm not yet fully happy with the fuzzy name/best guess check...I will try to tweak it a bit more....

3384

clrmame Discussion / Re: clrmamepro 3.130 released

« on: 14 August 2009, 19:19 »

I put it on my wish list....

next weeks I will be rather busy with moving to a new place....

3385

clrmame Discussion / Re: Clrmame not reporting missing roms + CHD ?

« on: 14 August 2009, 09:29 »

hide fully missing sets...yeah yeah...an evil little option....guess I will add a warning next time

3386

clrmame Discussion / Re: Clrmame not reporting missing roms + CHD ?

« on: 14 August 2009, 08:07 »

Erm...you jumped from 129u4 to 133u1 and you wonder that you're missing stuff?

Besides of endless rom changes in between, the chd format changed in .130 where you have to update all your chds using chdman.


Anyway....You should see all issues in scanner's result tree, as always. It lists in detail what is missing (see attached screenshot)


Of course you should...

- be sure you got at least sets+roms+chds check enabled
- be sure you got all checks (missing, name, unneeded, size, etc...etc...) enabled

- be sure you didn't disable any sets (in set-information) or any systems (in 'systems') or any chd types (in 'hash & chd -> Available Regions'

- be sure you don't hide fully missing sets (Scan Tree window->popup menu->view->hide fully missing sets

3387

clrmame Discussion / Rename Wizard wip

« on: 13 August 2009, 22:57 »

Done

- list control for the result
- sorting support by column
- copy to clipboard (|-separated, no header, all columns)
- save to disk (|-separated, no header, all columns)
- export as mamediff format (oldname, newname + filenames as header)

To Do

- improve fuzzy / best guess test
- option to forbid parent renames (since some dats only work on parents)
- auto patching a 3rd (or maybe more) dat(s) on game or rom level
- save positions, sorting, more messages blabla...



Hey s_bastian, I guess you want to test this....

...check later posts for updated urls...

*edit* yes..I', aware of the "thrild2" issue when comparing 133 vs 132.

 |thrild2a|?|
*|thrild2|thrild2a|matched by single unique rom hash
*|?|thrild2|

so what happened here....
a) there's a missing * in the first line
b) why does the 3rd line show thrild2 as a new file (in the 2nd it's an old)

The reason for both is the "not allow double renames" and the best guess rename finder.
thrild2a is normally a best guess rename to thrild2a but we already have a higher prio rename by single unique rom hash. That's why it gets the ?.
The missing * is simply a bug which doesn't set the indicator in this case....
The 3rd line is simply also a bug based on this higher prio rename just the other way around..

I will look into this over the weekend....anyway...Rename Wizard is WIP

3388

clrmame Discussion / Re: clrmamepro 3.130 released

« on: 13 August 2009, 21:16 »

well...read the text again and check for uppercase things..... 

3389

clrmame Discussion / Re: clrmamepro 3.130a released

« on: 13 August 2009, 11:33 »

Well the current list with the renames (which you can copy/paste btw...) is just for testing the detection
I'm still tweaking the tests a bit....still not happy with some renames (132->133 viper is annoying since the sets mainly have a chd and that changed....)

But I keep your remarks of course.....

3390

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

3391

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

3392

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.

3393

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

3394

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

3395

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.

3396

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

3397

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

3398

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.

3399

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

3400

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