Topic: Request for little feature (Read 29248 times)

oddi · « **on:** 07 May 2013, 06:01 »

Hello Roman, i have request for little feature with profiler view, Column of dates where I can see when they added new dats. Tnx

Roman · « **Reply #1 on:** 07 May 2013, 06:54 »

Please specify....

the date when you added it to cmpro?
the date listed in the datfile header?
...or anything else?

oddi · « **Reply #2 on:** 07 May 2013, 07:05 »

I think when added it to cmpro or 2 colums - date added in cmpro and date listed in the dat file header:)

Roman · « **Reply #3 on:** 07 May 2013, 10:47 »

well...the dat header entry which is already shown is the version...and usually dat authors code a date in it

oddi · « **Reply #4 on:** 22 May 2013, 11:29 »

Hello, Roman :)I think I need to add a column with a date when added dat file in clrmame profile, because I have a strange feeling clrmame in batchmode not fix few sets from my MESS software list. Sets is t7z/merged, atm when used batchmode i uncheck this option "Dont ask before fixing". When update and scans dats with batchmode i wanna check manually dats. Tnx

Roman · « **Reply #5 on:** 22 May 2013, 13:14 »

What did you edit here?
is something not working as expected?
damn...I'm lost in real life...

Roman · « **Reply #6 on:** 23 May 2013, 16:06 »

ok..showing it is no problem...but I want to be sure which date...

datfile creation / lastWrite / lastAccess date
or settings creation / lastWrite / lastAccess date

(e.g. settings lastAccess/lastWrite one will be 'the last time you've scanned or loaded the profile in the profiler....while lastWrite/lastAcess date for datfile would be the date when the datfile was added to the profiler folder (or modified...e.g. when you renamed it)

Roman · « **Reply #7 on:** 23 May 2013, 18:49 »

you can try this...
http://mamedev.emulab.it/clrmamepro/binaries/cmp20130523.rar

this takes the lastWrite timestamp from the .dat file...

oddi · « **Reply #8 on:** 24 May 2013, 02:51 »

Many tnx Roman, perfect

Now easy check cmp not autofix dats in batchmode or the only way I think.

Roman · « **Reply #9 on:** 24 May 2013, 05:14 »

What exactly do you mean with "Not Autofix Dats in batchmode"?

oddi · « **Reply #10 on:** 24 May 2013, 07:53 »

Opss, sorry for my stupid explain, mean for this option "Dont ask before fixing", i tihnk when this option is enable cmp not fixing t7z/merge sets. Now with timestamp i sort the last new dats and manually rescan for test. I want to be sure that the problem really.

Roman · « **Reply #11 on:** 24 May 2013, 09:20 »

I do some tests...but let me know if you find a little scenario when this happens

oddi · « **Reply #12 on:** 12 June 2013, 07:26 »

Hello Roman , i found where is problem with batchmode - snes.xml. Cmpro in batchmode create dummy roms:
that is fragments from snes.xml . Only two sets have dummy roms in softlist - "clay fight 2" and "boogerman". When i check archives inside have dummy roms, removed "dummy roms" and test snes.xml in batchmode - no problem atm. Maybe that is very rare bug , dont know.

Code: [Select]

<software name="clayfgt2up" cloneof="clayfgt2" supported="no"> <!-- incomplete dump -->
		<!-- Notes: incomplete dump, only 3 out of the 6 chips are available, the original prototype board is unknown -->
		<description>Clay Fighter 2 - Judgment Clay (USA, Prototype)</description>
		<year>1995</year>
		<publisher>Interplay</publisher>
		<part name="cart" interface="snes_cart">
			<feature name="slot" value="hirom" />
			<dataarea name="rom" size="3145728">
				<rom name="clay 2 1995.u1" size="524288" crc="3998e4b9" sha1="a0b91861b4e67c290d6621f607560366d8ef7ec4"                 offset="0x000000" />
				<rom name="2.u2"           size="524288" crc="19c4b39f" sha1="86df3dd37504dba24a84eac5bbf50ba26c84b194"                 offset="0x080000" />
				<rom name="3.u3"           size="524288"                                                                status="nodump" offset="0x100000" />
				<rom name="4.u4"           size="524288" crc="dc5e95b5" sha1="b695e6c1f25381d159cb2b3efa8b3a44bed85a86"                 offset="0x180000" />
				<rom name="5.u4"           size="524288"                                                                status="nodump" offset="0x200000" />
				<rom name="6.u6"           size="524288"                                                                status="nodump" offset="0x280000" />
			</dataarea>
		</part>
	</software>

Code: [Select]

	<software name="boogerup" cloneof="booger" supported="no"> <!-- incomplete dump -->
		<!-- Notes: incomplete dump, only 1 out of the 6 chips are available, the original prototype board is unknown -->
		<description>Boogerman - A Pick and Flick Adventure (USA, Prototype)</description>
		<year>1995</year>
		<publisher>Interplay</publisher>
		<part name="cart" interface="snes_cart">
			<feature name="slot" value="hirom" />
			<dataarea name="rom" size="3145728">
				<rom name="boogerman ver13 1.u1" size="524288" crc="601cbe5f" sha1="fe250a8acf5fbd366e15039cbb11be8c59883324"                 offset="0x000000" />
				<rom name="2.u2"                 size="524288"                                                                status="nodump" offset="0x080000" />
				<rom name="3.u3"                 size="524288"                                                                status="nodump" offset="0x100000" />
				<rom name="4.u4"                 size="524288"                                                                status="nodump" offset="0x180000" />
				<rom name="5.u4"                 size="524288"                                                                status="nodump" offset="0x200000" />
				<rom name="6.u6"                 size="524288"                                                                status="nodump" offset="0x280000" />
			</dataarea>
		</part>
	</software>

Roman · « **Reply #13 on:** 12 June 2013, 11:52 »

Can you describe your problem a little bit more in detail? Maybe with a step-by-step description or screenshots...and give me access to all relevant files....

oddi · « **Reply #14 on:** 12 June 2013, 16:13 »

Maybe problem it's me:). Progress testing with disable option in batchmode "Use scan when possible ( instead of new scan) ".
Have a nice day

Roman · « **Reply #15 on:** 12 June 2013, 17:29 »

so there is no issue ?

oxyandy · « **Reply #16 on:** 12 June 2013, 18:22 »

Hi Roman,
oddi has mentioned this to me previously.
Here is a summary of what I have seen..

Say you take a ZIP MESS full softlist which is split.
In August 2012, you use CMP in Batch Mode & convert it to a 7z Merged set.

You have "Use scan when possible (instead of new scan)" ticked.

Now as xml updates come along, you replace the old xmls with the updated ones and do a "No Rebuilder Run" with each update - some are complete, some are "Red" so you do a Batch,
"Rebuilder Run before Scan" using your "Fresh Downloads" folder as a source.
All sets are returned to zero miss state after the "Batch Run" is complete.

OK, so that is our usage pattern, seems to 'do the job' everyone is happy.

Time ticks by, many times we repeat the above process again & again.
Everything seems just fine.
We are always doing Batch and always have
"Use scan when possible (instead of new scan)" ticked.

Now it's June, we UNTICK...
"Use scan when possible (instead of new scan)".
And do a full Batch Scan only, with "Don't ask before fixing" UNTICKED

So comes the question,
Should we expect not to be prompted to fix anything in your opinion ?

Cause after all these dat changes & Scans over & over for the past 10 mths
CMP has always reported - after the Batch runs, that all sets are complete.

Well, let me tell you in my experience on a couple of sets, I will be asked to fix a few things..
Normal ?

Thanks
Oxyandy
Oddi, is this what you are seeing too ?

Roman · « **Reply #17 on:** 12 June 2013, 20:19 »

hmmm...
a scan (not a new scan) is possible if the underlying dat was not changed and a previous new scan has been done. if the dat changed, cmpro detects this and removes the cache and fastscan folder information and the scan button is disabled.

theoretically, a batch operation should work identically since the dat/profile loader is responsible for this and it's one and the same for batch and normal mode.

I need to do some tests for this specific scenario, now that I understand it

thanks for the head up....

Roman · « **Reply #18 on:** 13 June 2013, 19:08 »

hmm...I can't really reproduce this...
so what I did:

created a bunch of dats...loaded them (not batch), did a full scan for each...all are 100% ok...fine...
now I modified one of these dats (renamed a single rom inside one set) readded it to the profiler), and ran a batch run on all dats again with "Use scan when possible (instead of new scan)" enabled....

the profile gets red in the profiler afterwards and the scanner shows the error...

So....am I missing something here?

oxyandy · « **Reply #19 on:** 14 June 2013, 00:15 »

I'm sorry Roman,
I think you know by now, if I could have given you an easily repeatable scenario I would have

Hence why I gave the example of after nearly a year of scanning and dat updates, very broad.
(of course maybe even a few cmp.exe updates along the way !)

I don't want you to do anything more, keep it in the back of your mind.
I will look out for a repeatable scenario and if I actually can find one you will know about it.
This is not my bug report, but at least now you know what Oddi is trying to say..

News:

Author Topic: Request for little feature (Read 29248 times)