EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

The new forum is online, hope you enjoy it!

Pages: [1]   Go Down

Author Topic: Help!  (Read 21022 times)

Legoman

  • Karma: 0
  • Offline Offline
  • Posts: 5
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Help!
« on: 09 January 2010, 13:58 »

OK, I wouldn't describe myself as a newbie, but I don't know how to fix this:-

I used to have an old MAME setup, and kept the CHDs in the same folder as my ROMs, no subdirectories of any kind, not even in the zipfiles of the ROMs. I used CLRMAME to keep the ROMS uptodate. Now, all that was about five years ago.

I've come back to it now, and expected to keep the same way going. However, I think that, for some reason, I can't - I keep seeing snippets of posts that imply a fixed directory structure, but I can't find it documented anywhere.

I'm also unsure *precisely* what a "set" is in MAME terminology, or how to program for it.

As a software developer myself, I simply can't see a reason for the change form the old way - why not keep the CHDs and the ROMs in one root folder , with a unique filename for each ROM and CHD game? And why can't CLRMAME handle CHDs as deftly as it can handle ROMs? Is it all prohibited by the MAME developers for some reason?

My worry is that I have to create a subdirectory structure for each game, all thousand odd or so. Can this be right?

Here's my CLRMAME output:-

 =====================================================
unneeded diskimage: G:\Mame\Roms\Final\a45jaa02.chd [not fixed]

unneeded file: G:\Mame\Roms\Final\chaosheatj.par [not fixed]

unneeded diskimage: G:\Mame\Roms\Final\gk922b02.chd [not fixed]

unneeded diskimage: G:\Mame\Roms\Final\gk922d02.chd [not fixed]

Dance Dance Revolution 4th Mix (G*A33 VER. JAA) [system: System 573 BIOS - folder: ddr4mj - parent: ddr4m - size: 517kb]
wrong merged ROM set: G:\Mame\Roms\Final\ddr4mj (merge to: ddr4m)
wrong placed chd: G:\Mame\Roms\Final\ddr4mj\a33jaa02.chd (move to set: ddr4m)
wrong placed chd: G:\Mame\Roms\Final\ddr4mj\a33jaa02.chd (move to set: ddr4m)
wrong name: G:\Mame\Roms\Final\ddr4mj\a33jba02.chd [wrong: a33jba02.chd] [right: a33jaa02.chd] [not fixed]
unneeded diskimage: G:\Mame\Roms\Final\ddr4mj\a33jba02.chd [not fixed]

Dance Dance Revolution 4th Mix Solo (G*A33 VER. JBA) [system: System 573 BIOS - folder: ddr4msj - parent: ddr4ms - size: 517kb]
missing but fixable (-> ddr4mj) chd: a33jba02.chd [chd-md5: N/A] [chd-sha1: 9d9fb5e65f1532f358e9c273c56d11389d11fd79]

Dancing Stage (GN845 VER. EAA) [system: System 573 BIOS - folder: dstage - size: 513kb]
wrong name: G:\Mame\Roms\Final\845uaa02.chd [wrong: 845uaa02.chd] [right: 845ea.chd] [not fixed]
missing chd: 845ea.chd [chd-md5: N/A] [chd-sha1: d3f9290d4dadb5e9b82ebe77abf7b99d1a89f716]

Fisherman's Bait - Marlin Challenge (GX889 VER. EA) [system: System 573 BIOS - folder: fbaitmc - size: 513kb]
missing chd: 889ea.chd [chd-md5: N/A] [chd-sha1: 0b567bf2f03ee8089e0b021ea502a53b3f6fe7ac]

Fisherman's Bait - Marlin Challenge (GX889 VER. AA) [system: System 573 BIOS - folder: fbaitmca - parent: fbaitmc - size: 513kb]
wrong name: G:\Mame\Roms\Final\889ua.chd [wrong: 889ua.chd] [right: 889aa.chd] [not fixed]

Fisherman's Bait - Marlin Challenge (GX889 VER. JA) [system: System 573 BIOS - folder: fbaitmcj - parent: fbaitmc - size: 513kb]
wrong name: G:\Mame\Roms\Final\889ua.chd [wrong: 889ua.chd] [right: 889ja.chd] [not fixed]

Guitar Freaks (GQ886 VER. EAC) [system: System 573 BIOS - folder: gtrfrks - size: 513kb]
missing chd: 886ea.chd [chd-md5: N/A] [chd-sha1: c0118b5539902e75853403a4979869d18c3d1b86]

Guitar Freaks (GQ886 VER. AAC) [system: System 573 BIOS - folder: gtrfrksa - parent: gtrfrks - size: 513kb]
wrong name: G:\Mame\Roms\Final\886ua.chd [wrong: 886ua.chd] [right: 886aa.chd] [not fixed]

Guitar Freaks (GQ886 VER. JAC) [system: System 573 BIOS - folder: gtrfrksj - parent: gtrfrks - size: 513kb]
wrong name: G:\Mame\Roms\Final\886ua.chd [wrong: 886ua.chd] [right: 886ja.chd] [not fixed]

Konami 80's AC Special (GC826 VER. AAA) [system: System 573 BIOS - folder: konam80a - parent: konam80s - size: 513kb]
wrong name: G:\Mame\Roms\Final\826eaa01.chd [wrong: 826eaa01.chd] [right: 826aaa01.chd] [not fixed]

Konami 80's Gallery (GC826 VER. JAA) [system: System 573 BIOS - folder: konam80j - parent: konam80s - size: 513kb]
wrong name: G:\Mame\Roms\Final\826eaa01.chd [wrong: 826eaa01.chd] [right: 826jaa01.chd] [not fixed]

Konami 80's AC Special (GC826 VER. KAA) [system: System 573 BIOS - folder: konam80k - parent: konam80s - size: 513kb]
wrong name: G:\Mame\Roms\Final\826eaa01.chd [wrong: 826eaa01.chd] [right: 826kaa01.chd] [not fixed]

Konami 80's AC Special (GC826 VER. UAA) [system: System 573 BIOS - folder: konam80u - parent: konam80s - size: 513kb]
wrong name: G:\Mame\Roms\Final\826eaa01.chd [wrong: 826eaa01.chd] [right: 826uaa01.chd] [not fixed]

Melty Blood Act Cadenza Ver B (GDL-0039) [system: Naomi GD-ROM Bios - folder: meltyb - size: 24mb]
missing chd: gdl-0039.chd [chd-md5: N/A] [chd-sha1: ffc7f6e113ad69422a4f22f318bdf9b1dc5c25db]

Melty Blood Act Cadenza Ver B (Rev A) (GDL-0039A) [system: Naomi GD-ROM Bios - folder: meltyba - parent: meltyb - size: 24mb]
missing chd: gdl-0039a.chd [chd-md5: N/A] [chd-sha1: e6aa3d65b43a20606e6754bcb8665438770a1f8c]

Police 911 (ver KAC) [system: Konami Viper BIOS - folder: p911kc - parent: p911 - size: 264kb]
wrong name: G:\Mame\Roms\Final\a00uac02.chd [wrong: a00uac02.chd] [right: a00kac02.chd] [not fixed]

Super Puzzle Bobble (V2.05O) [system: Taito GNET - folder: spuzbobl - size: 5mb]
missing set: Super Puzzle Bobble (V2.05O)
missing chd: spuzbobl.chd [chd-md5: N/A] [chd-sha1: 1b1c72fb7e5656021485fefaef8f2ba48e2b4ea8]

Super Puzzle Bobble (V2.04J) [system: Taito GNET - folder: spuzboblj - parent: spuzbobl - size: 5mb]
missing set: Super Puzzle Bobble (V2.04J)
missing chd: spuzbobj.chd [chd-md5: N/A] [chd-sha1: dac433cf88543d2499bf797d7406b82ae4338726]

Silent Scope EX (ver UAA) [system: Konami Viper BIOS - folder: sscopex - size: 264kb]
missing chd: a13c02.chd [chd-md5: N/A] [chd-sha1: d740784fa51a3f43695ea95e23f92ef05f43284a]

Noukone Puzzle Takoron (GDL-0042) [system: Naomi GD-ROM Bios - folder: takoron - size: 24mb]
missing chd: gdl-0042.chd [chd-md5: N/A] [chd-sha1: 984a4fa012d83dd8c748304958c847c9867f4125]

Wangan Midnight Maximum Tune 2 (Export) (GDX-0015) [system: Chihiro Bios - folder: wangmid2 - size: 5mb]
missing chd: gdx-0015.chd [chd-md5: N/A] [chd-sha1: 259483fd211a70c23205ffd852316d616c5a2740]

==========================================================

Why does Fishermans Bait want to rename 889ua.chd to *two* others - 889ja.chd *and* 889aa.chd? If it's the same rom (and it must be, as proven by the fact that it can be renamed to both), why does it need two separate filenames?

And if I try to keep them in the same directory, it keeps wanting to rename, which I allow, then it wants to rename back! It's very confusing, and since it's clear that since it can obviously be made much simpler and these issues removed by using unique filenames for everything, it's clear that whoever is responsible for choosing filenames is doing this for some reason - does anybody know why?

Can anybody please enlighten me as to how to get myself a fully working MAME set?
Logged


Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.5.7 Firefox 3.5.7
    • View Profile
Re: Help!
« Reply #1 on: 09 January 2010, 20:59 »

The official way of storing chds was always rompath\setname\chdfilename. Besides of that, MAME's official storing method for any file was always rompath\setname\file 1... file n....for decompressed sets which simply becomes rompath\setname.zip for compressed sets (file 1...file n is then inside the archive).

Back in the past due to a MAME bug it was possible to store them in a rompath root.
After the big CHD update in MAME .130 (oh yes, all chds need to be updated via chdman), Devs decided to re-allow the rompath at root level storage (which is still weird since you won't see to which set it belongs...since usually chdfilenames don't match a setname anymore but are chosen by the original hd/cd/whatever device).

If you want to use chds on rompath root, you need to tell cmpro so. Scanner Advanced->Allow CHDS in rompath root.

A set is a collection of roms and/or samples and/or chds. There are CHD-only sets, there are rom only sets and other combinations. Easiest is to see a set as the archive (.zip) which holds the single roms for example. A set + name check checks the name of the zip while a rom + name check checks the romfiles inside the archive.

>Why does Fishermans Bait want to rename 889ua.chd to *two* others - 889ja.chd *and* 889aa.chd?

Because the name check is set based and depending on the set it tries to find a best fitting name. And depending on your disk tag merge settings it decides which to use. Another reason to keep chds in the offical subfolder way.


So to sum it up: clrmamepro handles chds absolutely correctly in both storing modes, but you need to tell cmpro which one to use...(and the majority of users prefers the chd in subfolder mode).
« Last Edit: 09 January 2010, 21:37 by Roman »
Logged

Legoman

  • Karma: 0
  • Offline Offline
  • Posts: 5
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Re: Help!
« Reply #2 on: 10 January 2010, 00:50 »

Thanks for the reply, Roman.

The official way of storing chds was always rompath\setname\chdfilename. Besides of that, MAME's official storing method for any file was always rompath\setname\file 1... file n....for decompressed sets which simply becomes rompath\setname.zip for compressed sets (file 1...file n is then inside the archive).

So I read. Why? Has anybody *not* on the developer teams decided to ask why they chose this mechanism?

Quote
Back in the past due to a MAME bug it was possible to store them in a rompath root.
After the big CHD update in MAME .130 (oh yes, all chds need to be updated via chdman), Devs decided to re-allow the rompath at root level storage (which is still weird since you won't see to which set it belongs...since usually chdfilenames don't match a setname anymore but are chosen by the original hd/cd/whatever device).
Yes, I had to CHDMAN -update some of the roms I downloaded - again, a process instigated by developers who think only fellow technically-adept developers have an interest in this project. I think it was naive to expect players to do this. Joe Sixpack wouldn't have bothered, just slunk away. Who knows how many gave up. I nearly did, and I'm a developer and sysadmin.

Why was this necessary, and was it the only way to achieve it? Considering that CHD's are supposed to be verbatim copies of disks from the original machines, they won't have changed or be needed to be changed, so why did they *all* need to be updated? The data on the arcade machines disks haven't changed since they were built, some of them twentyfive years ago. I've not heard of any of them needed to be updated. Therefore, my inference is that it was a sop to the emulator, maybe to help it store some kind of meta-data, or to help it run? It can't be critical as I read that pre-.130 CHDs did not need to be updated "if one could tolerate the error message". Sounds like a critical reason for updating every CHD, then, I don't think. The developers have full control of how the software interacts with the CHD's - it would make more sense to me to change MAME to work with the CHD files which could be universal and work with any other emulator. What really was this "change" supposed to accomplish?

Likewise, ROMs seem to need updating often, despite some of the machines they come from not being updated for may decades. Once a ROM is dumped, and MAME is developed to work with it, it would stay the same, surely? Any improvement to MAME's ability to run this ROM will be made to the MAME executable, won't it? So why are changes being made to ROM's?

Quote
If you want to use chds on rompath root, you need to tell cmpro so. Scanner Advanced->Allow CHDS in rompath root.
Yes, I discovered this. It even created all the directories for me - once. Never did it again, no matter how I provoked it.

I just don't understand the requirement for this extravagant folder tree, at all.

Quote
A set is a collection of roms and/or samples and/or chds. There are CHD-only sets, there are rom only sets and other combinations. Easiest is to see a set as the archive (.zip) which holds the single roms for example. A set + name check checks the name of the zip while a rom + name check checks the romfiles inside the archive.

Does an end-player need to know all this? Why can't the software just look after it all? A sane naming scheme would do this - single zip file for all roms, CHD's for any disk image (LD,HD) required, and all in the same directory to permit cross-usage by clones, etc. "Simples", as the Meerkat says. We don't need to run a tracking repository into user-land.

Quote
>Why does Fishermans Bait want to rename 889ua.chd to *two* others - 889ja.chd *and* 889aa.chd?

Because the name check is set based and depending on the set it tries to find a best fitting name. And depending on your disk tag merge settings it decides which to use. Another reason to keep chds in the offical subfolder way.

Well, this is just another kludge, in my view, to keep a disfunctional naming scheme running. It's desperately in need of a rethink.

Quote
So to sum it up: clrmamepro handles chds absolutely correctly in both storing modes, but you need to tell cmpro which one to use...(and the majority of users prefers the chd in subfolder mode).

I haven't seen a poll asking what users prefer, so I'm not convinced!

My *guess* is that people who just want to play the games don't really care, so it would make more sense if that was considered in term of choosing storage mechanism. Currently, this is far from the case, and appears to be a unnecessary enforcement of developers personal dictats. And I am a software developer, so I speak from an ashamed experience, where many of my kind have to be hit over the head with wet kippers before they can be made to understand that end users are not developers, something Microsoft has yet to embrace... (but that's another story!)

Thanks for the reply - apologies if some of my comments, particularly towards the developers, seems a little caustic, but sometimes they just have to be shown that some of their thinking is not in-line with ordinary Joe Sixpack. Absolutely, they work very hard, and I am in awe of what they produce - I certainly couldn't do it. But I do know how to manage a software development program properly, and I am stunned by how such a great piece of software could have such a letdown of a storage scheme - the forums are full of "how do I"'s over where to place ROMs and CHD's and such.

It's not uncommon - some very talented techies lack the ability to empathise with others, to "dumb-down" their strong technical abilites to the ordinary user. Some say that Aspergers Syndrome plays a part here. I'm not sure, but I personally do know that the best techs often need a novice tech to smooth them down and properly harness their abilities. Maybe that's needed here.

Clrmame doesn't seem to work as well here with CHDs, either, but I'm not sure I am working the software right to be certain. (That fact *alone* should be a wake-up call to many - the need for all these switches and boxes all over the place - doesn't it seem to you, Roman, if you stop and think about it, that it's all a bit "over-the-top"? Try explaining it all to somebody over-60, or under-20!). Clrmame is flawless for ROMS, that's certain, and I think it's great for this. I don't understand why it can't *seem* (I could be wrong) to manipulate CHD's so "automatically" - but then, I think this is in part down to the sub-folder requirement.

I just want Clrmame to be pointed at a "before" directory containing all the ROMs and CHDs, tell it to rebuild, and it produce an "after" folder with all chds in the correct folders. I've not been able to achieve it. A nice big, red, "fix-it-all-and-don't-bother-me-cos-I-just-want-to-play-MAME-and-dont-care-how-it's-stored" button, would be really nice. Not because *I* need it (but I'd use it!), but because I think many others do.

I challenge anybody to give me *one* really good reason why everything cannot be stored in one folder, ROMs and CHDs. I can see no technically or operationally beneficial reason.

Thanks for reading, and thanks for all your contributions!
Logged

Legoman

  • Karma: 0
  • Offline Offline
  • Posts: 5
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Re: Help!
« Reply #3 on: 10 January 2010, 01:00 »

Quote

>Why does Fishermans Bait want to rename 889ua.chd to *two* others - 889ja.chd *and* 889aa.chd?

Because the name check is set based and depending on the set it tries to find a best fitting name. And depending on your disk tag merge settings it decides which to use. Another reason to keep chds in the offical subfolder way.

Well, most of that went over my head. And I thought I could understand most stuff driven by a CPU - I can program in five languages, including C##.

Now, think carefully about the answer you just gave, even though I didn't understand it, and let me ask you, seeing as you do - Is that a better mechanism than simply using one filename to address the CHD, and keep the whole concept of "sets" and whatever internal to MAME out of the need to be understood by Joe Sixpack? I really can't see it being so.

One Zip file, containing a dump of the ROMs on the cabinet circuit boards. One CHD file per disk in the cabinet, so maybe multiple CHDs to cover hard disk and laser disk, tops. All files uniquely named to easily identify them, all in one directory. What needs more than this?
Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.5.7 Firefox 3.5.7
    • View Profile
Re: Help!
« Reply #4 on: 10 January 2010, 09:27 »

>One Zip file, containing a dump of the ROMs on the cabinet circuit boards. One CHD file per disk in the cabinet, so maybe multiple CHDs to cover hard disk and laser disk, tops. All files uniquely named to easily identify them, all in one directory. What needs more than this?

well, you haven't read carefully. That's exactly how MAME stores files.

"all in one directory" - that's your rompath (ok, usually people use more than one since they want to group sets
"one zipfile containing a dump of the ROMs" - correct, that's the 'set'.
"CHDs..." - there you got the choice how to store them, either 'your' way in a rompath root or in a set-subfolder (where the roms stay in their zipfile)
(Like d:\mame\roms\area51\area51.chd and d:\mame\roms\area51.zip (for the roms).

MAME supports zipped and unzipped sets, in case of an unzipped set, you quickly see the general storing method: rompath\setname\file 1 ... file n.


But of course, MAME also supports merging of sets....where you merge parent/clone sets in one or split them up.......but that's a different story.
« Last Edit: 10 January 2010, 09:31 by Roman »
Logged

Legoman

  • Karma: 0
  • Offline Offline
  • Posts: 5
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Re: Help!
« Reply #5 on: 10 January 2010, 14:28 »

>One Zip file, containing a dump of the ROMs on the cabinet circuit boards. One CHD file per disk in the cabinet, so maybe multiple CHDs to cover hard disk and laser disk, tops. All files uniquely named to easily identify them, all in one directory. What needs more than this?

well, you haven't read carefully. That's exactly how MAME stores files.

I understand that. What nobody seems to be able to tell me, is why. It's complex, requires fore-knowledge of every single file to place it correctly, is not intuitive, is ambiguous, and is unnecessary. I'm open to correction from anybody on this subject, but so far nobody has come forward and said so.

Quote
"all in one directory" - that's your rompath (ok, usually people use more than one since they want to group sets
"one zipfile containing a dump of the ROMs" - correct, that's the 'set'.
"CHDs..." - there you got the choice how to store them, either 'your' way in a rompath root or in a set-subfolder (where the roms stay in their zipfile)
(Like d:\mame\roms\area51\area51.chd and d:\mame\roms\area51.zip (for the roms).

MAME supports zipped and unzipped sets, in case of an unzipped set, you quickly see the general storing method: rompath\setname\file 1 ... file n.

I follow - but it doesn't answer either my issue with MAME's storage model, nor my own issues.

Quote
But of course, MAME also supports merging of sets....where you merge parent/clone sets in one or split them up.......but that's a different story.

Actually, merged sets is what I've always used.

This is my latest clrmame output, produced from a "fresh" install - a rebuild from a directory of ROMs (which I am certain are correct), and a manual copy of CHD's (which, again, thanks to SHA-1 confirmation am sure that they are correct post-0.130) into the root. Clrmame is then run, and correctly creates the directory tree and moves all the CHDs into their correct subfolders. This should be it. Except....

==========================================================
Dance Dance Revolution (GN845 VER. UAA) [system: System 573 BIOS - folder: ddru - parent: dstage - size: 513kb]
missing but fixable (-> dstage) chd: 845uaa02.chd [chd-md5: N/A] [chd-sha1: d3f9290d4dadb5e9b82ebe77abf7b99d1a89f716]

Fisherman's Bait - Marlin Challenge (GX889 VER. AA) [system: System 573 BIOS - folder: fbaitmca - parent: fbaitmc - size: 513kb]
missing but fixable (-> fbaitmc) chd: 889aa.chd [chd-md5: N/A] [chd-sha1: 0b567bf2f03ee8089e0b021ea502a53b3f6fe7ac]

Fisherman's Bait - Marlin Challenge (GX889 VER. JA) [system: System 573 BIOS - folder: fbaitmcj - parent: fbaitmc - size: 513kb]
missing but fixable (-> fbaitmc) chd: 889ja.chd [chd-md5: N/A] [chd-sha1: 0b567bf2f03ee8089e0b021ea502a53b3f6fe7ac]

Fisherman's Bait - Marlin Challenge (GX889 VER. UA) [system: System 573 BIOS - folder: fbaitmcu - parent: fbaitmc - size: 513kb]
missing but fixable (-> fbaitmc) chd: 889ua.chd [chd-md5: N/A] [chd-sha1: 0b567bf2f03ee8089e0b021ea502a53b3f6fe7ac]

Guitar Freaks (GQ886 VER. AAC) [system: System 573 BIOS - folder: gtrfrksa - parent: gtrfrks - size: 513kb]
missing but fixable (-> gtrfrks) chd: 886aa.chd [chd-md5: N/A] [chd-sha1: c0118b5539902e75853403a4979869d18c3d1b86]

Guitar Freaks (GQ886 VER. JAC) [system: System 573 BIOS - folder: gtrfrksj - parent: gtrfrks - size: 513kb]
missing but fixable (-> gtrfrks) chd: 886ja.chd [chd-md5: N/A] [chd-sha1: c0118b5539902e75853403a4979869d18c3d1b86]

Guitar Freaks (GQ886 VER. UAC) [system: System 573 BIOS - folder: gtrfrksu - parent: gtrfrks - size: 513kb]
missing but fixable (-> gtrfrks) chd: 886ua.chd [chd-md5: N/A] [chd-sha1: c0118b5539902e75853403a4979869d18c3d1b86]

Konami 80's AC Special (GC826 VER. AAA) [system: System 573 BIOS - folder: konam80a - parent: konam80s - size: 513kb]
missing but fixable (-> konam80s) chd: 826aaa01.chd [chd-md5: N/A] [chd-sha1: be5f8b31fd18ba631fe98c2132c56abf20193419]

Konami 80's Gallery (GC826 VER. JAA) [system: System 573 BIOS - folder: konam80j - parent: konam80s - size: 513kb]
missing but fixable (-> konam80s) chd: 826jaa01.chd [chd-md5: N/A] [chd-sha1: be5f8b31fd18ba631fe98c2132c56abf20193419]

Konami 80's AC Special (GC826 VER. KAA) [system: System 573 BIOS - folder: konam80k - parent: konam80s - size: 513kb]
missing but fixable (-> konam80s) chd: 826kaa01.chd [chd-md5: N/A] [chd-sha1: be5f8b31fd18ba631fe98c2132c56abf20193419]

Konami 80's AC Special (GC826 VER. UAA) [system: System 573 BIOS - folder: konam80u - parent: konam80s - size: 513kb]
missing but fixable (-> konam80s) chd: 826uaa01.chd [chd-md5: N/A] [chd-sha1: be5f8b31fd18ba631fe98c2132c56abf20193419]

----------
Missing
·Sets                 0/8517
·Roms                 0/123978
·CHDs                 11/420
·Samples              -/2512
·Bytes                0/76gb

Fixed Wrong Case
·Sets                 0/0
·ROMs                 0/0
·CHDs                 0/0
·Samples              -/-

Fixed Unneeded
·Sets                 0/0
·ROMs                 0/0
·CHDs                 0/0
·Samples              -/-

Fixed Wrong Name
·Sets                 0/0
·ROMs                 0/0
·CHDs                 0/2

Fixed Wrong Size
·ROMs                 0/0

Fixed Wrong Date Time
·ROMs                 0/0

Wrong Hashes
·Wrong CRC32 ROMs     0
·Wrong SHA1 ROMs      0
·Wrong MD5 ROMs       0
·Wrong SHA1 CHDs      332
·Wrong MD5 CHDs       332

Corrupt Containers    0

---------------------------------------

Active Sets           8517/8517
·Parents              1771/1771
·Clones               4059/4059
·Others               2639/2639
·BIOS                 48/48

Active ROMs           123978/123978
·Parents              26786/26786
·Clones               61693/61693
·Others               33420/33420
·bad dumps            634/634
·no dumps             1266/1266
·verified dumps       0/0
·BIOS                 179/179

Active CHDs           420/420
·Parents              59/59
·Clones               85/85
·Others               194/194
·bad dumps            34/34
·no dumps             48/48
·verified dumps       0/0
·BIOS                 0/0

Active Samples        2512/2512
·Parents              522/522
·Clones               1766/1766

Active Bytes          76gb/76gb

==========================================================

What are all these "missing but fixable" CHD's? If they're fixable, why doesn't Clrmame fix them? What do I need to do to fix them?

And why do I keep seeing 0/2 on "fixed wrong name CHDs", every time I run?

Thanks for your help!
Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.5.7 Firefox 3.5.7
    • View Profile
Re: Help!
« Reply #6 on: 10 January 2010, 20:14 »

Well, "missing but fixable" can be fixed by turning on 'fix missing'.

However you don't need these chds since they are identical to the chd in their parent sets. And there, they already exist (since cmpro reports them already as fixable). So your output is a bit weird unless you used "not-merged sets".

So, please check the following (actually these are default settings...I doubt you changed them):

Profiler->Options->Parse Disk Merge Tags should be enabled (this is needed to allow the merging of disk images in case of they are have differently names defined)
Profiler->Options->Don't create dummy clones should be disabled

Your prefered merge mode is fully merged as you already told me, so that should be fine.

Then please do a "new scan" to recheck if these messages reappear.

...and of course I assume you're using a MAME binary to get the database data from and no 3rd party dat file...
Logged

Legoman

  • Karma: 0
  • Offline Offline
  • Posts: 5
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Re: Help!
« Reply #7 on: 12 January 2010, 19:01 »

Well, "missing but fixable" can be fixed by turning on 'fix missing'.

Hehe - I did *that*!!!  ::)

Quote
However you don't need these chds since they are identical to the chd in their parent sets. And there, they already exist (since cmpro reports them already as fixable). So your output is a bit weird unless you used "not-merged sets".

Story of my life...!  :P

Quote
So, please check the following (actually these are default settings...I doubt you changed them):

I'm a techie - so I wouldn't assume that!  ;D

Quote
Profiler->Options->Parse Disk Merge Tags should be enabled (this is needed to allow the merging of disk images in case of they are have differently names defined)
Profiler->Options->Don't create dummy clones should be disabled

Both were set to the opposite, so have changed them back. This was an update over an old CMPro - must have been changed back in the mists of time.

Quote
Your prefered merge mode is fully merged as you already told me, so that should be fine.
Indeed - should I be parsing merge tags on the ROMs, too?

Quote
Then please do a "new scan" to recheck if these messages reappear.

That dispelled them a treat, and I now have an almost-perfect report! Just one last item, the Fixed-Wrong-Name shows CHDs as 0/5, instead of 0/0 like ROMs and sets. Is this fixable?

Quote
...and of course I assume you're using a MAME binary to get the database data from and no 3rd party dat file...

Yes, I always generate them from the executable. Always seemed an obvious way to remove the possibility of old or defective DAT's creeping in.

BTW, what are your thoughts over my earlier comments?

Clrmame is a fantastically powerful tool, but also a very manual one - it would benefit from offering a few automated mechanisms working, or maybe a few software "wizards" - I assume that the vast majority of users just want to shepherd their collections into a finite sate, and since (I think) there is only, at best, three complete finite states (merged, split, or split-merged), and those states are easily defined, it should be easy to code routines that just go ahead and blitz the provided source folders and produce a complete MAME installation as a finished product, without user-knowledge of roms, CHD's samples, sets, or anything else.

A "Just-fix-it!" button, if you will!

Thanks for your help!


Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.5.7 Firefox 3.5.7
    • View Profile
Re: Help!
« Reply #8 on: 12 January 2010, 19:12 »

> Both were set to the opposite, so have changed them back. This was an update over an old CMPro - must have been changed back in the mists of time.

Not really. They were never exchanged or pointed by default to a different value. Anyway, you found it, you changed it, perfect.

> Just one last item, the Fixed-Wrong-Name shows CHDs as 0/5, instead of 0/0 like ROMs and sets. Is this fixable?

If chd + name + fixname is enabled they should have been fixed and if nothing is in the scan tree, perfect, you're fine.
Which ones are still listed as wrong named after a new scan?
Maybe the 'new name' already exists as a file and that's why the rename operation fails. In this case you can manually remove the 2nd instance.

> A "Just-fix-it!" button, if you will!

Well, 1st of all, clrmamepro grew to a monster over the last 13 years (it's 'PRO' :)) due to the input from several in-deep-collector groups, devs etc who got some weird requests which the common user doesn't have to care about.
For the common user it's actually set to some good defaults already and he/she only has to:
1) load a dat in the profiler
2) setup a rompath in settings
3) go to the scanner and hit scan.....This lists everything which is wrong...and if you enable the fix options, it will fix them....

Maybe the rewrite in 2026 will bring you a one-touch only functionality.

>Should I be parsing merge tags on the ROMs, too?

If you like...you will gain a little bit of diskspace...but in days of multi-terabyte hds...who cares ;)
« Last Edit: 12 January 2010, 19:56 by Roman »
Logged

Specialt1212

  • Member
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 28
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #9 on: 22 April 2010, 06:44 »

Hello,

I followed your above instructions about

Profiler->Options->Parse Disk Merge Tags should be enabled (this is needed to allow the merging of disk images in case of they are have differently names defined)
Profiler->Options->Don't create dummy clones should be disabled

but I'm still getting the below error

Code: [Select]
Dance Dance Revolution Best of Cool Dancers (GE892 VER. JAA) [system: System 573 BIOS - folder: ddrbocd - parent: ddr2m - size: 513kb]
missing but fixable (-> ddr2m) chd: 895jaa02.chd [chd-sha1: cfe3a6f3ed62ba388b07045e29e22472d17dcfe4]

DrumMania 2nd Mix Session Power Up Kit (GE912 VER. JAB) [system: System 573 BIOS - folder: drmn2mpu - parent: drmn2m - size: 517kb]
missing but fixable (-> drmn2m) chd: 912jab02.chd [chd-sha1: 19dfae94b63468d3e16d3cc4a3eeae60d5dff1d7]

Guitar Freaks 3rd Mix (GE949 VER. JAB) [system: System 573 BIOS - folder: gtfrk3ma - parent: gtrfrk3m - size: 517kb]
missing but fixable (-> gtrfrk3m) chd: 949jab02.chd [chd-sha1: ad629c9bafbdc4bf6c679918a5fae2bcfdb39332]

should I be doing something else?
Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #10 on: 22 April 2010, 08:20 »

here we go..

Set = a collection of roms and/or samples and/or chds. You can have sets which for example only consist of a chd.


A little bit CHD storing technique history..

When MAME introduced chds a long time ago, they need to be stored in the official way how MAME loads files:
rompath\setname\file 1...file n

MAME looks into a rompath, seeks a folder named after the set or a zipfile named after the set and then loads roms/samples/chds from that position. Yes, back at that time it was also possible to put a chd into the roms zipfile which is of course nonsense because chds are zlib compressed containers on their own.
So you store e.g. the area51.chd in d:\mame\roms\area51\area51.chd. Looks easy..but don't get fooled, \area51\ is the setname here while area51.chd is the chd filename. They don't necessarily are identical. Usually the filename follows the hd/cd/whatever image's orginal hardware name.

Later on in that history, due to a bug in the implementation, it was possible to have chds on rompath rootlevel (d:\mame\roms\area51.chd). Well, as you can see, you won't be able to see to which set the chd belongs to. As long as a chd is named after the set...ok fine...but have a look at e.g. Naomi or Konami chds...

That bug was fixed and for a long time the official storing method was used again.

With MAME .130 or something, the chd format was updated and because people had to convert a lot of chds manually, some developer reenabled the usage of chds-on-rompath-root level again. So currently, both methods can be used and it's up to you which one you prefer...(most people prefer the official one with setsubfolders).

Enough history talk....

If you want to have chds on root level, you need to tell cmpro this...Scanner->Advance->allow chds on rompath root.

If you want to have your chds in setsubfolders (then disable the upper option), cmpro can help you to do the move part and the subfolder creation. Simply put the chds in a rompath root and scan/fix with sets+roms+chds+unneeded+name check (or simply got all enabled...). Cmpro will then move the wrong placed chds to their correct place.


Now to your log...

"wrong merged ROM set:"

Well, you decided to have fully merged sets.
This means that you keep only a parent set and all belonging clones are merged into this. This includes CHDs. This means for you got one zipfile for the roms and one setsubfolder for all chds of that set (parent and clone). Of course only if you use the setsubfolder chd mode. Other clone zips and clone setsubfolders can be removed.

"wrong placed chd"

Exactly what is written above, cmpro tells you to move the chd to the correct (parent) folder

"missing chd"

well...you don't have it...get it :)

The fisherman's bait etc naming weirdness....Or in other words...Konami....yes..it might look weird...and it is a combination of the konami chds definition in the database and your used storing method. Konami uses different names for identical clone chds..which look a bit weird (and depending on the profiler option to parse or not parse disk merge tags it plays a role if you need them multiple times or not...so keep that option enabled).

So, first decide how to keep chds, then enable or disable the beloning allow-chd-on-rompath-root level option depending on your selection.

Then scan again and let cmpro fix the files for you.
Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #11 on: 22 April 2010, 08:26 »

ok great....too early...no coffee....I've replied to the oldest thread not the newest...

So again, Konami weirdness and "clones of clones".

If I remember correctly there are some konami clones which share chds within the clones only.

For example:

Parent set: CHD_A
Clone set 1: CHD_A and CHD_B
Clone set 2: CHD_B

now in this example CHD_B is identical within the clones so you got something like a clone-of-clone. And such a thing isn't supported because split-merging means that you got all sets, where the parent holds the parent files and each clone only holds the files belonging to the clone.

Long talk.....you need to clone the chds in this case, yes, two instances of one and the same file....or switch to fully merged sets (which I would not prefer...)

In times of Terabyte HDs a little bit of CHD overhead ain't an issue....
« Last Edit: 22 April 2010, 08:27 by Roman »
Logged

Specialt1212

  • Member
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 28
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #12 on: 22 April 2010, 12:49 »

Thank you for the response I appreciate it!

If I understand correctly I have to go into my CHD folder and make copies of the 3 following files

- 895jaa02.chd
- 949jaz02.chd
- 912jab02.chd

Which I did, then I placed them in the root of my CHD folder and not in any subfolder i.e.

MAME => CHD

I then reran clrmamepro and got the following errors

wrong placed chd: C:\Users\Special T\Desktop\MAME\CHDs\895jaa02.chd (move to set: ddr2m)

wrong placed chd: C:\Users\Special T\Desktop\MAME\CHDs\912jab02.chd (move to set: drmn2m)

wrong placed chd: C:\Users\Special T\Desktop\MAME\CHDs\949jaz02.chd (move to set: gtfrk3mb)
Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #13 on: 22 April 2010, 13:00 »

Actually you can simply use the fix-missing option to let cmpro create the chd for you at the right place.

Your manual copy and placement in a rompath root will lead to the funny situation that
a) cmpro sees the copied ones there and (if you don't keep chds at rompath-root-level) sees that they are wrongly placed there.
b) now it looks for a best fitting position and here it takes the position where you cloned the files from.....running in circles here....it's not so clever to see that they already exists there and should search for a better position....(reminds me to put this on the todo list). It simply used the first best fitting place...where it should use the 2nd ;)

So either use the fix-missing option or move the chds manually to the correct subfolder and rescan.
Logged

Specialt1212

  • Member
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 28
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #14 on: 22 April 2010, 13:42 »

I would definitely prefer clrmamepro to fix it for me so I don't make any mistakes but I already have the fix-missing option selected? Do I need to alter any other settings?

Logged

Roman

  • Global Moderator
  • Member
  • ***
  • Karma: 112
  • Offline Offline
  • Posts: 3287
  • Operating System:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #15 on: 22 April 2010, 14:05 »

Hmm..ok...looks like fix-missing doesn't do what it should with the chd...(another point for my checklist).

How do you keep the chds? Do you allow chds on rompath root level (scanner->advanced) or not?

Assuming you don't allow them on rompath-root (which is the more common way),
then create subfolders in your rompath
ddrbocd
drmn2mpu
gtfrk3ma

and move the chds to their belongings folder
895jaa02.chd -> ddrbocd
912jab02.chd -> drmn2mpu
949jab02.chd -> gtfrk3ma
Logged

Specialt1212

  • Member
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 28
  • Operating System:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
Re: Help!
« Reply #16 on: 22 April 2010, 14:41 »

Thank you for the help copying the following roms into those folders cleared up the errors.

895jaa02.chd -> ddrbocd
912jab02.chd -> drmn2mpu
949jab02.chd -> gtfrk3ma
Logged
Pages: [1]   Go Up
 

Page created in 0.128 seconds with 20 queries.

anything
anything