Print

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

[stecy]

Hi,

I've been trying to get clrmamepro to recognize the files in the cabinets folder using a DatFile but the program always telling me that all the files are unneeded. That is not so!!!! They are needed.

Can anyone tell me how to configure clrmamepro to properly scan the cabinets folder. As an aside, other folders are behaving the same.

Here how the datfile I have is configured:
<datafile>
  <header>
   ...
  </header>
  <game name="cabinets">
    <description>cabinets</description>
    <rom name="005.png" size="241910" crc="88effcb8" sha1="a8a14256a58a226d3425bc9222c552762c62ebd3"/>
    ....
  </game>
</datafile>

My cabinets files are located in I:\Mame\Cabinets

I've tried setting the ROMPATH for clrmamepro to I:\Mame\Cabinets
I've tried disabling SETS from the scanner

Thank you for any help.

[Roman]

There are 2 supported storing methods:

rompath\setname\file 1.... file n (for decompressed sets)
rompath\setname.zip (.rar/.7z) (for compressed sets, where the archive then holds file 1 ... file n)

Looking at the datfile you see that the setname is <game name="cabinets"> "cabinets".

"My cabinets files are located in I:\Mame\Cabinets" ....so your rompath needs to be setup to "I:\Mame" if you follow the upper rule.

Now it sounds a bit like I:\MAME is used for other stuff (which the cmpro scanner most likely will mark as unneeded), you may think about having another subpath where you put your cabinets...

[stecy]

Well, I have the following folder structure:
   I:\Mame
   I:\Mame\Cabinets
   I:\Mame\Roms
   I:\Mame\Samples
etc...

I could have a "cabinets" inside the I:\Mame\Cabinets but frankly that would seem odd.

However, I managed to do it by unchecking the "You want to scan sets" in the scanner.
Apart from having a message that it is bad having this disabled, everything succeeded.

Is there a better way?
May I suggest having the program determines that such a setup is fine?

Thank you and have a nice week.

[Roman]

Do NOT disable sets.

You need to change your storing method. Again, you need to use the storing methods:

rompath\setname\file 1.... file n (for decompressed sets)
rompath\setname.zip (.rar/.7z) (for compressed sets, where the archive then holds file 1 ... file n)

Yes, you may need to add another folder level for your files then, e.g. I:\Mame\ArtFiles\Cabinets
Depending on other profiles you may even think of another level or specify exclude folders (settings, path selector).

There won't be support for any other storing method.

By the way, if you're using decompressed sets you should disable scanner/advanced/deeper check for fixable missing files....this is usually a slow-down option when handling decompressed sets.

[stecy]

Can you explain why disabling sets is bad? Why is the option there in the first place then? 

I've scanned all my art files and everything checks out ok.

However, I am willing to give it a try but I want to be sure on how to setup properly.
So here's what I am going to start from scratch and re-run the mame extraction so that I end up with:
I:\Mame
    +------artwork
    +------ctrlr     <-- contains not compressed files
    +------docs
    +------hash
    +------hlsl
    +------roms        <-- contains compressed files, one per game
    +------samples    <-- contains compressed files, one per game
     [files... like mame.exe, mame.ini]

I'll then create the following structure inside the artwork folder:
    +------artwork
              +-------artwork     <-- bezels and layouts, one zip per game
              +-------bkground   <-- contains not compressed files
              +-------cabinets     <-- contains not compressed files
              +-------cpanel        <-- contains not compressed files
              +-------flyers         <-- contains not compressed files
              +-------icons          <-- contains not compressed files
              +-------manuals     <-- contains not compressed files
              +-------marquees   <-- contains not compressed files
              +-------pcb            <-- contains not compressed files
              +-------snap          <-- contains not compressed files
              +-------titles          <-- contains not compressed files

Will I need to amend the mame.ini configuration file to add all those subfolders or is Mame smart enough to figure it out?

Also, for now the files inside the subfolders are uncompressed and although I could compress them using 7z and a solid archive (with a small solid size) I am not sure of the impact it would have on Mame upon loading a game. It would certainly make an impact on the storage size though...

[Roman]

You turn off all set specific check options (set = collection of roms and/or samples and/or chds.....so you turn off all checks which work on the folder/archive itself. The rom checks work on the files within the folder/archive). When turned off you will e.g. not notice if the set was renamed in a future dat (I admit this is only very rarely happening for artwork based dats, but still it already happened with them).

So turning this off is in my opinion not a good workaround for a wrong storing method.

Why is there an option, well, because cmpro got an option for everything From 1997 onwards it had the ability to turn on/off any possible check/fix since some advanced users required this. The normal use case is to use the default settings (which includes enabled sets/roms/samples/chds checks).

The storing method originally comes from MAME. Well, artwork dats are - compared to MAME sets - different, since they put all files into 1 set. But still the 2 storing methods should be followed to audit them. Keep in mind that everything found in a rompath which does not belong to a set is unneeded, that's why you should separate your profile's rompaths.

If you keep them decompressed or compressed is fully a personal taste.

Last but not least you need to keep in mind that when it comes to filenames and paths generation (e.g. when fixing or reading files), cmpro will generate rompath\setname\ or rompath\setname.zip(.rar/.7z). So if you don't follow the storing methods you will end in chaos sooner or later...

[retaliator]

Sorry, maybe this sounds a bit noob, but I need some guidance of you guys.

Attached a datfile I want to use, never got it to work properly with uncompressed files. As an example the first file of the dat and my folder structure for it:
C:\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz

Clrmame (latest build) don't recognize them as a valid set, same file zipped works fine.

Any hint what I'm doing wrong?

TIA for any advice!

[Roman]

You need to follow the correct storing method:

rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.rar/.7z) for compressed sets (where the archive holds file 1...file n for that one set)

So assume you got it stored like this:

E:\temp\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz

then e:\temp is the rompath you have to setup....

in your example C:\ would be the rompath (but I guess you don't want that, since everything in C:\ which is not part of the dat will be marekd as unneeded).
So, I suggest to add a folder level, e.g. C:\GameCube  ...then this is the rompath ...and you store it like
E:\GameCube\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz

[retaliator]

C:\ was only for example. My rompath is "\\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)".

So the complete path for the mentioned set is "\\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz". But this isn't working at all, still getting no sets in place and Clrmame is asking to remove them. But as soon as I put them in a zip container it's fine.

[Roman]

with such a long path, you may hit the pathlimit.....either use the latest nightly build or use  \\? prefix (see https://www.emulab.it/forum/index.php?topic=22.msg17279#msg17279)

I've tried it with a standard (relatively small rompath) and it worked fine

or map a drive letter to \\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit) and use that one then...

[retaliator]

I'm already using the latest nightly build.

Also mapping the rompath as a network drive isn't working either and \\? don't do it. Why should it change a thing while zipped files with the same rompath are working fine?

[Roman]

It works fine for me with a 'normal', drive letter based rompath, like e:\temp\gamecube
but you're right, even "\\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz" shouldn't hit the path limit.

"Clrmame (latest build) don't recognize them as a valid set" ...so what exactly does this mean in detail? what does it say?

For a test you may want to copy it on a non network drive....if it's working there, there might be an issue with the network...

...or you give me access to the zip file somehow...so I can do further tests

[retaliator]

Tested on a local drive and it works. Still the question why it works on the netwwork path as zipped files but not as uncompressed. Weird...

They sets are marked as unneeded, that's what I meant with none valid.

I don't think that my network is the issue as all of my collection is located there and there's no problem at all. Only as soon as they're uncompressed...

[Roman]

Can be anything...access rights, 3rd party tools (virusscanners) interfearing...etc...
There are for example known SAMBA issues where large files cause problems (bad network drivers)...

The are a lot of differences while working with zip files versus files. For example when calculating the hash for the files. In zip/7z/rar mode it simply takes the hash from the stored crc32 information (unless you don't check sha1 as well, then the file is decompressed to memory) while for a decompressed file it reads the file and calculates the checksum (on network drives this means all data is transfered).
It can also be Window specific library calls which may have a problem with the network when accessing/reading files...an we're talking here about larger files.

I try to rebuild the scenario with a bigger file in a longer path on a network drive...

What you can do...well....you may want to disable virusscanners for that folder....by the way...is it the only file which is listed as unneeded or all of that datfile?

[retaliator]

All of the datfile is listed as unneeded, verifies fine as zipped. There're also far bigger and more files I audit on this NAS with Clrmame (all in rar or zip, btw.), so I don't think that's the problem. Virusscanner isn't the problem either, Windows specific, maybe...

The only reason I don't want to zip in the case is, that you can use this format (gcz) directly with the emulator Dolphin and it's already compressed. Only 2 options for me left: zipping only as stored or no auditing. Not really sadified with both.

[Roman]

Yeah, see your point...any chance you can provide
- your cmpro.ini
- the used datfile (guess I got that) and the belonging *.cmp file from cmpro's settings folder
- one of the failing files in the rompath

[retaliator]

I will send you a link with those files.

Edit: Done!

[Roman]

thanks...

[oxyandy]

Hi Roman, hope you are well ! 
Long time no posts from me..
I have always wished your wonderful program - with so many uses beyond emulation,
could handle unarchived files in a single folder - IE. dir2dat pointed to a folder at root level
contents indexed and able to be recreated / scanned from a dat.
Cheers

[oxyandy]

You need to follow the correct storing method:

rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.rar/.7z) for compressed sets (where the archive holds file 1...file n for that one set)

Like an option to simply 'ignore setname' this way an existing dat such as:
NINTENDO GameCube (Redump.org)
..\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz
Could be used to store / scan all files at root level 'minus' the subfolders.