EMULAB Forum

clrmamepro [English] => clrmame Discussion => Topic started by: oddi on 07 May 2013, 06:01

Title: Request for little feature
Post by: 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 :)
Title: Re: Request for little feature
Post by: Roman 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?
Title: Re: Request for little feature
Post by: oddi 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:)
Title: Re: Request for little feature
Post by: Roman 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 :)
Title: Re: Request for little feature
Post by: oddi 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 :)
Title: Re: Request for little feature
Post by: Roman on 22 May 2013, 13:14: What did you edit here?
is something not working as expected?
damn...I'm lost in real life...
Title: Re: Request for little feature
Post by: Roman 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)
Title: Re: Request for little feature
Post by: Roman on 23 May 2013, 18:49: you can try this...
http://mamedev.emulab.it/clrmamepro/binaries/cmp20130523.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20130523.rar)

this takes the lastWrite timestamp from the .dat file...
Title: Re: Request for little feature
Post by: oddi 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.
Title: Re: Request for little feature
Post by: Roman on 24 May 2013, 05:14: What exactly do you mean with "Not Autofix Dats in batchmode"?
Title: Re: Request for little feature
Post by: oddi 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.
Title: Re: Request for little feature
Post by: Roman on 24 May 2013, 09:20: I do some tests...but let me know if you find a little scenario when this happens
Title: Re: Request for little feature
Post by: oddi 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">   <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">   <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>
Title: Re: Request for little feature
Post by: Roman 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....
Title: Re: Request for little feature
Post by: oddi 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 :)
Title: Re: Request for little feature
Post by: Roman on 12 June 2013, 17:29: so there is no issue ?
Title: Re: Request for little feature
Post by: oxyandy 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 ?(http://ndsxdelta.no-ip.org/f_t.png)
Title: Re: Request for little feature
Post by: Roman 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....
Title: Re: Request for little feature
Post by: Roman 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????
Title: Re: Request for little feature
Post by: oxyandy 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..
Title: Re: Request for little feature
Post by: Roman on 14 June 2013, 06:27: well...when I find a little time over the weekend I can do some more testing....

thanks anyway
Title: Re: Request for little feature
Post by: Roman on 16 July 2013, 21:06: well...I guess I found a repeatable scenario and a fix for it....
Scenario is pretty easy to build afterall, create a dat with 1 set, load it in standard mode, scan the set, 100% ok.
Now change the dat (e.g. size change of a rom), add it to the profiler again (overwrite old), and use the load in batchmode for it....it won't mark the profile red afterwards or shows the error (when you had KeepScannerOutput enabled)...

I got a fix here which I will try to test the next days a bit more....
Title: Re: Request for little feature
Post by: oxyandy on 17 July 2013, 05:13: Very nice Roman 8)

Thanks again for your great work !
Title: Re: Request for little feature
Post by: Roman on 17 July 2013, 07:07: You're welcome...guess we finally have a new release last week of July/1st of August....
Title: Re: Request for little feature
Post by: oddi on 17 July 2013, 16:56: Roman, your are great, tnx :)