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.

3501

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 21:49 »

hahaha...sillly me...the file came from MAME's playchoice 10 folder which I dropped for some testing

Ok...so here we are again at the start:

No file is rebuilt since none of the files is a NES file (not fulfilling the NES bytepattern rule).

Why do you expect a file Wagan Land (Japan).gg should get rebuilt by a NES dat/header? It's not a NES file.

3502

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 21:47 »

hmm..something's odd here. Now it didn't rebuild any file (as before)...I wonder where that "Solar Jetman - Hunt for the Golden Warpship (USA)" came from from a previous try....

will do more checks....

to answer your question: there is no limit. It's the normal rebuilder. The only difference is that the source file is unpacked and run through the header skip routine.....and after that the checksum is compared in the normal rebuilder way of doing it....

3503

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 21:10 »

what you can try is to enable rebuilder logging. It's in rebuilder advanced "create logfile". The file may give you more information.

3504

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 21:02 »

one is rebuilt to "Solar Jetman - Hunt for the Golden Warpship (USA)". I've added 1000 files to the folder and rebuilt...works fine here, no slowdown.
I expect a different file in your temp folder is causing the problem.

3505

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 19:45 »

ok...first thing....all of the files are NOT fulfilling the NES header constraints.
That's why they are skipped during rebuild. NES files start with a byte pattern of 4E4553 at offset 0. Your files don't.

The slowness if you got them inside a folder with other files is most likely based on the fact that each file in that folder gets decompressed (if zipped/rared/7zipped) into memory, the header detection logic is applied and then the normal rebuilder logic is run on that memory file. But even then it should be rather fast.....

Look at the progress window, it usually tells you which file is currently performed and if it stalls at one file you should have a deeper look at it.

3506

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 18:35 »

in the meantime I got the files....now I only need time to have a look at it

3507

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 17:23 »

ah..silly me...however currently I get a
"Sorry, the free service is at full capacity."

3508

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 16:57 »

now I only need to know where to grab the files

3509

clrmame Discussion / Re: clrmame and no-intro's header files

« on: 14 July 2009, 05:59 »

if it's not that large you can send me the dat and the romfile and I will have a look....

Generally if you work with enabled header support, each touched file has to be unpacked and analyzed (skip header, calculate checksum) which takes some time...but not really more than a normal deep check like the "unpack and calculate crc32/sha1/md5)" options.

Maybe it's a different option (like "advanced->fix missing scans all files") which touches the file in question over and over again and so you end with a longer scan time.....

so...send me the files in question....maybe plus your cmpro.ini and the used .cmp file which holds settings for the profile (in cmpro's settings folder).

3510

clrmame Discussion / #0019 - rule #1

« on: 09 July 2009, 07:28 »

Never ever disable the SETS option

Why? Because you want to see unneeded files, folders, wrong named sets, wrong placed chds etc...
It enables a lot of checks for files in your rompaths (while roms/samples/chds look inside the files/archives in your rompaths). Spot the difference.

3511

clrmame Discussion / Re: wrong missing set scans

« on: 09 July 2009, 07:25 »

The option actually *IS* for not-fixing

Since when fix missing is enabled it will do this check anyway.

If fix-missing is disabled that mentioned option will show something like
missing BUT FIXABLE rom: blabla (<where it can be found>)
if it's not enabled you will only see
missing rom: blabla

3512

clrmame Discussion / Re: wrong missing set scans

« on: 09 July 2009, 05:59 »

Usually deeper check for missing files is not a speed killer. There are some rare cases where it is but this usually depends on the used datfile (one set with 19347141 roms can be one of the cases).

"Fix missing scans all sets" is a real speed killer. "sha1/md5" checks too.

3513

clrmame Discussion / Re: CHDs not rebuild

« on: 09 July 2009, 05:56 »

Since I told you to put the chd in a rompath (and that's where sets are stored), you have to enable the sets scan.

There is no reason to turn off sets anyway.

3514

clrmame Discussion / Re: CLRMame WWW Mode

« on: 03 July 2009, 21:00 »

oops..file wasn't on the server....try again

3515

clrmame Discussion / Re: Batch scan not checking sub-folders of 'Source' path?

« on: 29 June 2009, 06:04 »

yeah it could be that it only scans the root.....if I remember correctly there is no batch option to enable subfolder support, so it would use the individual profile's setting in this case...if they don't have it enabled either, it won't be used.

Guess I will add a subfolder option for the batcher for the next version.

3516

clrmame Discussion / Re: Batch scan not checking sub-folders of 'Source' path?

« on: 28 June 2009, 16:22 »

erm...can you reexplain it a bit more?

3517

clrmame Discussion / Re: Viewing ALL profiles

« on: 24 June 2009, 12:29 »

The default is (and always was) that it's not shown. So I guess you disabled it

3518

clrmame Discussion / Re: Viewing ALL profiles

« on: 24 June 2009, 07:26 »

Sure there is a way: Select "Show [All Profiles] Folder" in the popup menu of the profiler tree part.

3519

clrmame Discussion / Re: Lesminni ROM Auditor

« on: 13 June 2009, 18:38 »

A single .nes file is of course "just a rom"..and the belonging set consists of for example that single rom.
As said before, the datfile specifies the set. The set definition can be anything...

There are datfiles which define them as single sets (i.e. you got 1 rom per set). This would look in the datfile like:

game (
   name "pac2000"
   description "another pacman clone"
   rom ( name "pacman.nes" size 4096 crc 12345678 )
)

game (
   name "ark"
   description "Arkanoid 2010"
   rom ( name "arcanoid.nes" size 4096 crc 87654321 )
)



and there are datfiles which combine single roms into bigger sets:

game (
   name "my_collection"
   description "some games"
   rom ( name "pacman.nes" size 4096 crc 12345678 )
   rom ( name "arcanoid.nes" size 4096 crc 87654321 )
)


So see the difference. One setname is my_collection and in the other part you got 2 sets. And again, this influences how you store your sets (let's take c:\roms again as rompath again):

c:\roms\my_collection.zip (where the zip contains the 2 .nes files) or c:\roms\my_collection\pacman.nes ... arcanoid.nes
and in the other example you got:
c:\roms\pac2000.zip and c:\roms\ark.zip (or folders of the same name when keeping the files decrompressed).


To confuse you even more now.....if you scan NES sets, you have enable (nes) header support, otherwise checksums won't be calculated correctly......but that's something for later...first understand the basics.

3520

clrmame Discussion / Re: Lesminni ROM Auditor

« on: 12 June 2009, 07:01 »

c) is about how you store your romsets.

The datfile defines how a romset should look like, i.e. listing the single romfiles in the set.
For example a romset (let's call it 'pacman' for easyness) consists of 3 romfiles 'a.bin', 'b.bin', 'c.bin'.

You store romsets in rompaths, i.e. a folder on your hd. Let's assume (ok..Windows style here) you store them in c:\roms. So you rompath is c:\roms.

Now the 2 possible storing methods for pacman are either as a compressed archive (pacman.zip (or pacman.rar/pacman.7z)) or not compressed.
In case of not compressed sets you need another subfolder in your rompath, named after the setname. So you will end with: c:\roms\pacman\a.bin ... bin.bin....c.bin

for compressed sets you will end with: c:\roms\pacman.zip (where the zipfile contains the bin files).

In cmpro you'd setup c:\roms as your rompath in this example.