3301
clrmame Discussion / Re: clrmame and MESS 0.133
« on: 26 July 2009, 16:08 »
Which file?
- 05 October 2024, 07:27
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
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.
3302
clrmame Discussion / clrmamepro 3.128b released
« on: 23 July 2009, 22:15 »
3.128a
misc: increased scanner speed slightly
misc: wrong named chds on root level (and with root mode enabled) are detected and can be fixed
misc: you can add/drop *.xml files as datfiles, too now
fixed: offline xml dat parser (however naming is currently limited to release number + name + extension)
fixed: "double description/folder" renames during parsing can create double counter extension
fixed: old style dat parser is broken in 3.128a
misc: increased scanner speed slightly
misc: wrong named chds on root level (and with root mode enabled) are detected and can be fixed
misc: you can add/drop *.xml files as datfiles, too now
fixed: offline xml dat parser (however naming is currently limited to release number + name + extension)
fixed: "double description/folder" renames during parsing can create double counter extension
fixed: old style dat parser is broken in 3.128a
3303
clrmame Discussion / clrmamepro 3.128 released
« on: 20 July 2009, 19:28 »
3.128
added: batcher-rebuilder always scan/never scan subfolder options
misc: enhanced "Can't merge set due to equal names" check to work with chds, too
misc: increased memoryfile size which is used for header support. This should increase speed when header detection is done on zipped files
misc: added shareRead and shareWrite options to cmpro.ini. Setting them to "on" will allow general file read/write sharing. Use it on your own risk
removed: fix missing scans all set. An old resource hog...rarely used
added: batcher-rebuilder always scan/never scan subfolder options
misc: enhanced "Can't merge set due to equal names" check to work with chds, too
misc: increased memoryfile size which is used for header support. This should increase speed when header detection is done on zipped files
misc: added shareRead and shareWrite options to cmpro.ini. Setting them to "on" will allow general file read/write sharing. Use it on your own risk
removed: fix missing scans all set. An old resource hog...rarely used
3304
clrmame Discussion / Re: clrmame and no-intro's header files
« on: 16 July 2009, 22:49 »
ok...it seems related to a too small memoryfile buffer....which results in long mem-reorganization when hitting a huge zip file.....
3305
clrmame Discussion / Re: clrmame and no-intro's header files
« on: 16 July 2009, 21:04 »
ok..what's the idea you wonder...
...well...I always wondered what causes the SAMBA/NAS/USB problems. It's most likely the fact that files are locked. In most cases clrmamepro tried to open files in an exclusive read or write mode. Now if the file is locked, you usually see "file x is used by a different program". The rebuilder skips such files. I've now added shareRead/Write modes....that theoretically should solve the rebuilder weirdness.....
...well...I always wondered what causes the SAMBA/NAS/USB problems. It's most likely the fact that files are locked. In most cases clrmamepro tried to open files in an exclusive read or write mode. Now if the file is locked, you usually see "file x is used by a different program". The rebuilder skips such files. I've now added shareRead/Write modes....that theoretically should solve the rebuilder weirdness.....
3306
clrmame Discussion / idea....
« on: 16 July 2009, 19:23 »
I got an idea, please send me an email, I'd like to send you a special build
3307
clrmame Discussion / Re: clrmame and no-intro's header files
« on: 15 July 2009, 19:50 »
The issue usually comes with a NAS, network drives and SAMBA.
It has been reported several times and all users came back with something like "My NAS was crap, got a different brand and it's ok now" or "I changed access rights and it's ok now".
So if you use a NAS, network drives or SAMBA, don't be afraid of the message above but give it a try to use a normal hd on your pc.
It has been reported several times and all users came back with something like "My NAS was crap, got a different brand and it's ok now" or "I changed access rights and it's ok now".
So if you use a NAS, network drives or SAMBA, don't be afraid of the message above but give it a try to use a normal hd on your pc.
3308
clrmame Discussion / Re: clrmame and no-intro's header files
« on: 15 July 2009, 06:23 »
Just ran 10000 sets (non nes) through a nes header rebuild and had no issues at all.
By the way, are you talking about a network drive / samba usage?
Because there are known issues sometimes where wrong configured networks cause timing issues which may result in such a reported behaviour.
If not, you may want to check if virusscanners interfear.
By the way, are you talking about a network drive / samba usage?
Because there are known issues sometimes where wrong configured networks cause timing issues which may result in such a reported behaviour.
If not, you may want to check if virusscanners interfear.
3309
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.
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.
3310
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....
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....
3311
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.
3312
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.
I expect a different file in your temp folder is causing the problem.
3313
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.
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.
3314
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
3315
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."
"Sorry, the free service is at full capacity."
3316
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
3317
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).
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).
3318
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.
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.
3319
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
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
3320
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.
"Fix missing scans all sets" is a real speed killer. "sha1/md5" checks too.