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.

61

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 08 August 2014, 11:36 »

 
Really ?
No problem, on "To Do List" is good enough for me, I live with CMP and it's  numerous bugs.
Still the best ROM Manager in the world

62

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 08 August 2014, 07:53 »

ok...that 'issue' is fixed

http://mamedev.emulab.it/clrmamepro/binaries/cmp20140804.rar

I usually confirm your fixes as soon as I download the new build, this time I didn't, sorry..
We have a problem..
I just tried a Rebuild to test this fix.
Now here I am Rebuilding from Back-Up folder.
Problem 1. Targets already exist, so should not be Rebuilt at all.(7 Matched | 7 Created)
Problem 2. After the File from Back-Up folder is Rebuilt (Wrongly), Source file is not being Removed..


 
Note: This was tested on the Crash_Fix build (Redrawing Scanner) that came after 'this' fix.
Not tested on previous build.


LATE EDIT:
To reinforce what's happening, after the Rebuild, every matched files claims to have been Rebuilt, no source file was removed.
So if I click Rebuild again, I see an exact repeat, 7 Matches 7 Rebuilt, over & over.
I could probably make you a dat & ROMs to replicate (if you need just holler)

63

clrmame Discussion / Re: auto rename same-name different-hash roms on merge

« on: 06 August 2014, 16:04 »

@Roman Thanks, I understand your intention now

@Oddi, yes CMP 'says' it wants to rename those files:
BUT, I think you will find that name already exists in the archive with matching CRC
So, CMP will not Rename them, it will delete them ..

Parse ROM 'merge' tags
Makes archives with less internal files, and a smaller total size archive..
You could try a few (copied from your current set) watch what CMP does to them

64

clrmame Discussion / Re: auto rename same-name different-hash roms on merge

« on: 06 August 2014, 14:06 »

Oh, and there's this:



By default, is unticked, so many people end up making a Merged - say t7z ROM set:
1. Which takes longer to process (make)
2. Ends up with archives which are larger & with more (internal) files than needed.

65

clrmame Discussion / Re: auto rename same-name different-hash roms on merge

« on: 06 August 2014, 13:56 »

I brought this issue up previously:
Honestly I don't like the sub-folder idea..
I'd be happy with
Some_rom.ext
to
Some_rom.ext_alt
Seeing MAME doesn't care about file-names at all.

EDIT: Oh maybe I wasnt thinking deep enough..
Do you mean  ??
Parent.zip
\parent\rom.1
\parent\rom.2
\clone_1\rom.1
\clone_2\rom.1

66

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 06 August 2014, 08:21 »

AH Roman you are the best.. !

Great work, as usual..
Is this something from a recent change ?
Something that maybe has been there a long time ?

I replaced EXE in my CMP_CRASH_TEST folder..
Toggled maybe 100 times, of course, no crash !

67

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 05 August 2014, 06:16 »

Yeah, yeah, I know.. I am blessed..
What I will do - is install another virgin XP SP3 32 and take folder over there.
I know I couldn't repeat it on win 7 x64 Ultimate.. No matter how many times I tried, so that's a good thing I guess

68

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 04 August 2014, 20:27 »

Great, now I checked that 'other' issue
At this point in time, with toggling [Rebuilder <> Scanner] using



The magic number is 3 toggles

69

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 03 August 2014, 21:10 »

OK, here we go..
Sorry, I really don't work with Uncompressed files often.
<SNIP>
Now this is confirmed: Both folders can be on same drive
This archive contains 2 Folders - 1 called SOURCE - 1 called DESTINATION & a dat.

So extract them both to "Somewhere"
Load the DAT supplied - Jump to Rebuilder
Set Source to Source folder -  Destination to Destination folder
Now tick 'removed matched files' & Click Rebuild

Yes, I think you are going to say this relates to the file type.. 
I checked other file types, it doesn't happen

70

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 03 August 2014, 09:21 »

nah a crash comes first :-)

OK then, in another attempt to make your life just that 'little bit' easier..
Toggle between Rebuilder <> Scanner with this dat loaded... (Sometimes it takes upwards to 5 toggles Rebuilder <> Scanner  <> Rebuilder)
http://speedy.sh/GYxzM/CMP-CRASH-TEST.7z
You may need to manually edit the data before you open CMP so 'ROM path exists'.
Currently it expects Q:\MAME - ROMs (v0.154)\
Sure an empty folder will work..
While Re-drawing Last Scanner Result <CRASH>

71

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 02 August 2014, 12:55 »

Roman,
Please ignore Reply #32 & #33 - don't waste any time on my XP *only* crash (for the moment)
Maybe it will go away with next build ? Maybe not.. Is not a big issue to me.
(Plus I have a CMP program folder, which *repeats* the crash - I can upload this)

Reply #31 does mention a bug with Uncompressed sets though..
Time would be better spent looking into that, and your existing list
Thanks anyway.

72

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 02 August 2014, 01:16 »

Ok Roman,
Great, I found a scenario where this crash is 100% repeatable.
If I open CMP. Load the DAT and go to Scanner.
CMP loads fine, without a crash. "Redrawing last Scan Result" works. (I have a single unneeded file)

Now I open CMP load the DAT, go to Rebuilder, when I use the "Jump to Scanner" button
(Bottom Right Hand Corner of Rebuilder Window)
It crashes every single time while "Redrawing last Scan Result"
Correction: (Nearly every single time)
I guess I should try reduce down the CMP Program Folder, and send you the whole thing 'as is'

EDIT: Ok done that, CMP program folder reduced,
crash still occurs while switching between "Scanner + Rebuilder"
Going to Boot over to Win7 X64 and try same CMP folder there.

EDIT_2:It did not happen there 
I will just ignore it, see how things work out on next 'Official Release' - doesn't stop me using CMP.

73

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 01 August 2014, 18:57 »

Speaking of 'bugs..'
I have also had CMP crash (quite a bit), while "Redrawing last Scan Result"
I will keep on eye on this, it hasn't been happening with previous builds, just one of the most recent ones.
It has only been with the one dat which I used for the recent MAME update (I think)
BUT, I haven't used the newest build much as I have been away on holiday.
So, again I will persevere and let you know.
cmpro_32.exe [crc32 4CF91535] from cmp20140718.rar



 

74

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 01 August 2014, 18:02 »

misc: optimized general hash calculation / file read routine
Nice tweak, thanks

Speaking of 'uncompressed sets' CMP has a bug..
I have known for a long time..
When Rebuilding from Drive A: to Drive B: & the destination file already exists. [uncompressed]
CMP throws an error.

Want to Stop ?
Error while rebuilding:
A:\Some_File.ext
to
B:\Some_File.ext
Do you want to stop?

It's like CMP does not know the file is already present at the Destination.
Understand ?
I could make an example Dat & Files (If needed)
 

Edit: Drive A: to Drive B:
Drive letters just example of course..

75

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 31 July 2014, 19:53 »

logfile naming based on the dat name

Would be great.
However, if I have 2 instances of CMP open using the same dat file, then using same log_file is a problem.
So sequential numbering ?
001_Dat_name.log
So if exist (001_Dat_name.log)
log_name = 002_Dat_name.log
etc

I was thinking %Date_Time_Stamp%_Dat_Name.log
However - really not needed - and they often don't sort well. So nah.

Yes as a Batch option (like "Always Compress Files" works now) would work, too
However, I see that as just a distraction for the 'Regular User'
So nah, again.

So I conclude a line in cmpro.ini - which would need to be manually edited.

Code: [Select]

Pro_GlobalLogging = OnLogging by %Dat_File_name%
Then when I load a 'New Dat'....
No need to remember to enable logging (or set a log file name)
And ... if  we can do what is currently not possible, allow for 2 instances by sequential number.
I know this would also mean a new log would be made for each time that DAT is loaded and that may very well be useful too
001_Dat_File_Name.log
002_Dat... etc

76

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 31 July 2014, 18:35 »

hmm...global logging...hmmm....I will think about it

Thanks Roman,
Have been away on holidays myself

77

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 22 July 2014, 03:39 »

Hi 'again' Roman,
(For anyone reading this should be done with CMP closed)
In CMP_Program_Folder\settings\
1. I opened all settings_files with Notepad++
Batch replaced
Rebuilder_CreateLogFile = off
with
Rebuilder_CreateLogFile = on

Rebuilder_AppendLog = off
with
Rebuilder_AppendLog = on
And
Rebuilder_Logfile = \n
Rebuilder_Logfile = Rebuilder_Logfile.log\n
(Logging in CMP_Program_Folder\ is just fine for me, but I really don't want all DATs using same log file.)
= quick & dirty

SO, what I ask is there some kind of string I could use so logs are created per Dat_Name
as in Rebuilder_Logfile = %Dat_Name%.log  ??

I know this is a quick way to enable 'Global Logging' - is there some other method ?

2. I messed up - I either forgot, had 2 instances of CMP open - when I closed (one or the other) it over-wrote the settings etc.
But anyway I did a Rebuilder run, thinking logging was enabled and well, it wasn't, oops, hehe.
So is it possible default "Global Logging" logs written by "Dat Name.log" ?

Thanks
Oxy

EDIT or maybe even
as in Rebuilder_Logfile = %timestamp%_%Dat_Name%.log
or (Specifically to deal with 2 instances of CMP being open simulataeously using same DAT)
Rebuilder_Logfile = %sequential_numbering%_%Dat_Name%.log
001_Dat_name.log
002_Dat_name.log
So if exist (002_Dat_name.log)
log_name = 003_Dat_name.log
would do fine too;)

78

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 21 July 2014, 02:40 »

feel free to provide a new better xml.....

Hmm, well in all honesty I do see people get confused (often) with the
No-Intro NES dat and it's usage with CMP.
However, as I have seen the No-Intro provided Header Skipper is flawed.

So if CMP was to come with a NES header skipper XML
Then it would have the name.
no-intro_NES.xml

Code: [Select]

<?xml version="1.0"?>

<detector>

  <name>iNES Header Skipper</name>

  <rule start_offset="10">
    <data offset="0" value="4E45531A"/>
  </rule>

</detector>
And you would dump the one you currently provide

EDIT: From specs you provided above
"9: Flags 9"
I confirmed Nestopia uses "09" bits 01 as PAL & 00 as NTSC

79

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 20 July 2014, 19:42 »

Hi Roman,
Yes thanks, I had a play I understand it much better now.
This rule works fine for creating a dat (Source files headered) & scanning a set stored (without any headers)

Code: [Select]

<?xml version="1.0"?>
<detector>
  <name>iNES Header Skipper</name>
  <rule start_offset="10">
    <data offset="0" value="4E45531A"/>
  </rule>
</detector>I found for my needs this works perfectly

As you pointed out iNES 2.0 Headers do use bytes in range 08 to 0C

And because some header polluted files do exist (such as DiskDude!) which uses bytes all the way to 0F
Then this check can never exist.
    <data offset="8" value="0000000000000000" result="true"/>
If source files being datted contained polluted headers (such as DiskDude!) then the resulting dat would be a mix of files some with 'whole file' hashed and the rest as they should be (hash = whole file minus first 16 bytes)

I get it now, sorry to disturb you
Thanks for the response

80

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 20 July 2014, 18:24 »

Hi again Roman,
Logging is working great,
I have a problem with "Header Skipper XML's"

Code: [Select]

<?xml version="1.0"?>
<detector>
  <name>No-Intro NES Dat iNES Header Skipper</name>
  <author>Yakushi~Kabuto</author>
  <version>20070321</version>
  <rule start_offset="10">
    <data offset="0" value="4E4553"/>
  </rule>
</detector>This works great for 'Making a DAT' but fails with scanning because of a few files which have
NESM = 4E 45 53 4D in bytes 16-19

Code: [Select]

4E 45 53 1A 02 01 01 00 00 00 00 00 00 00 00 00
4E 45 53 4D 1A 01 01 01 80 80 80 80 84 80 53 6FSo I tried using yours:

Code: [Select]

<?xml version="1.0"?>
<detector>
  <name>Roman's NES Header Skipper</name>
  <author>Roman Scherzer</author>
  <version>1.0</version>
  <rule start_offset="10" end_offset="EOF" operation="none">
    <data offset="0" value="4E45531A" result="true"/>
    <data offset="8" value="0000000000000000" result="true"/>
  </rule>
</detector>When using your "Header Skipper" to make a dat, I quickly discovered that 85 files I had were
datted as the 'whole file' = no bytes were skipped in the HASH calculation.
Some had 16 Byte - iNES 2.0 headers and the rest had 'dirty headers' with 'odd' bytes between 8-16
Examples
4E 45 53 1A 04 04 C0 30 00 01 00 00 00 00 00 00
4E 45 53 1A 04 04 80 C0 00 01 00 00 00 00 00 00
4E 45 53 1A 20 40 52 00 04 00 00 00 00 00 00 00
Anyway, I guess the easiest fix is to add the 1A

Code: [Select]

<?xml version="1.0"?>
<detector>
  <name>No-Intro NES Dat iNES Header Skipper</name>
  <rule start_offset="10">
    <data offset="0" value="4E45531A"/>
  </rule>
</detector>
This is new to me - so tell me is this line in your rule expecting bytes 8-16 to all be Zero ?
    <data offset="8" value="0000000000000000" result="true"/>
So if a header is polluted with DiskDude! your skipper will 'not ignore' the header when hashing ?

Oxy