EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: Roman on 07 November 2014, 19:54
-
....cough cough....shouldn't there be an update already?
erm...well..yes...but the last weeks were exhausting...a lot of real-life work project work kept me extremely busy...
So what's the status on the hash collision thing..(subfolder idea..)...actually...I'm pretty much annoyed of it. You run into issues here and there if you have subfolders and switch modes (from full to split or vice versa). To sum it up...I'm not really happy with the solution at the moment...
I may release a test version with it enabled sooner or later or change the subfolder idea to something else...or roll that change back and release the small other updates...
In the meantime (most likely because I was annoyed looking at the old code) I played a bit (just some minutes actually...) with pugixml (pugixml.org) and was surprised how fast it is....and had the idea of keeping the DOM as internal storage basis and have some xpath layer upon it to work with it...
For a second I was in the mood to write a MAME-only scanner/rebuilder from scratch with all the new ideas..and a totally different way of how things work. Not endless lists of options, not supporting this and that, not cleaning the xml which MAME provides...not exporting here..no batch jobs there....scan/fix/rebuild...done...but again...I'd need more time...
So...please be patient...I guess the current main version works fine...maybe some little fixes soon....
-
Well well well... as you might notice...still no new version...
and you know already the answer...the bloody author is busy...yep..I am...and currently I'm so much more interested in doing a rewrite...and watching https://www.kickstarter.com/projects/thimbleweedpark/thimbleweed-park-a-new-classic-point-and-click-adv (https://www.kickstarter.com/projects/thimbleweedpark/thimbleweed-park-a-new-classic-point-and-click-adv)
So actually...I'm closer to a new version since I'm sick of having the code hanging on my harddrive...and so I decided to change the subfolder idea a bit....but stick to the idea of handling hash collisions differently (no splitting of relationships in split merge mode and 'handling' of it in full merge mode).
So I guess I make it the following...for full merged mode, hash collisions get a pre or postfix setname plus delimiter for the problematic files... like pacman2_1b.bin (for clone pacman2 where 1b.bin got a hash collision). The delimiter (in this case "_") will be stored in the cmpro ini file and can be changed...and actually you could change it to "/" and you get subfolders...(as mentioned before, this mode will have some hickups here and there, use it on your own risk).
Now what do you think....prefix or postfix and what should be the default delimiter?
Edit: or maybe I add the entry to the cmpro.ini where you can put together variables like %s_%r, %s/%r or %r___%s or %r_%c (for %s etname, %r omname, %c crc32) or something like this....
-
The idea of using variables in .ini is wonderfull.
Maybe it could be that you split the .ini in 2 files: gui.ini and engine.ini
In this way, people could share engine.ini and be sure to create the exact same set of roms, leaving them free to have different gui settings on their respective PCs.
-
hehe...well...we'll see....guess for a start it can be in the cmpro.ini...if there are hardcore users out there, they will find it anyway...
for now I'm sick of it (the source code)....playing around with boost/pugixml seems to be more fun..but also no real time for it...
-
seems to work... (attached screenshot of some collisions with a hashcollide naming string "%1 [%x]"...where %1 is always the romname and you can use %x for hash value lowercase (crc32 for roms, sha1 for chds)....and lots of other variables which you may know from rebuilder advanced destination prestring...)
and another one with "%f_%1_%X" ...with prefix setname and postfix uppercase crc
and another with with a static prefix
and a last one with subfolders and year ;-)
-
It looks GREAT!
-
well...as mentioned...as long as you don't use "/" it should run perfectly fine...."/" may cause some weirdness if you switch from split to fully merged or vice versa....but time will tell..
I guess I add an input box somewhere so you don't have to manually edit cmpro.ini for this setting....still thinking about a good default/initial one...my personal favourite is "%1 [%x]" at the moment (the first screenshot)....
guess I can put out a test version soon...maybe tonight....
-
Roman, agree with u, i watching screens - first or second screen is good .
First - u safe original dump name .
second - my old idea with prefix :) :) :) - name of collisions_rom dump name , checksum is your idea :)
..and wait new test build, i wanna destroyed again my mame/mess sets.
Have a nice day :)
-
well...the removal of subfolders where there still were some files in it was fixed some months ago already...
and it's up to you to change the hash collision naming as you want....
-
as promised..
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141126.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141126.rar)
...and I used %1 [%f] as default now...
-
Roman now test over my mame set 0.156 full /t7z merged, see result after first scan :
(http://store.picbg.net/pubpic/1F/39/e6e6c8e136851f39.jpg)
Previous versions of cmp not correct check chds ?
see first chd, absolutly same ,Post code only from this chd
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\863hdda01.chd >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file: g:\MAME\WIP_SVN\CHDs\863hdda01.chd
File Version: 5
Logical size: 3,228,696,576 bytes
Hunk Size: 4,096 bytes
Total Hunks: 788,256
Unit Size: 512 bytes
Total Units: 6,306,048
Compression: lzma (LZMA), zlib (Deflate), huff (Huffman), flac (FLAC)
CHD size: 595,749,009 bytes
Ratio: 18.5%
SHA1: 0b8dbf1c9caf4abf965dbc6e1a8e6329d48b1c90
Data SHA1: 293b5430bc4946dcf506a935957064549c28540c
Metadata: Tag='GDDD' Index=0 Length=35 bytes
CYLS:6256,HEADS:16,SECS:63,BPS:512.
----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\863hdda01_1.chd >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file: g:\MAME\WIP_SVN\CHDs\863hdda01_1.chd
File Version: 5
Logical size: 3,228,696,576 bytes
Hunk Size: 4,096 bytes
Total Hunks: 788,256
Unit Size: 512 bytes
Total Units: 6,306,048
Compression: lzma (LZMA), zlib (Deflate), huff (Huffman), flac (FLAC)
CHD size: 595,749,009 bytes
Ratio: 18.5%
SHA1: 0b8dbf1c9caf4abf965dbc6e1a8e6329d48b1c90
Data SHA1: 293b5430bc4946dcf506a935957064549c28540c
Metadata: Tag='GDDD' Index=0 Length=35 bytes
CYLS:6256,HEADS:16,SECS:63,BPS:512.
btw - this idea with %1 [%f] is good
and not rename chds, maybe need manually , dont know
(http://store.picbg.net/pubpic/9D/65/4916344aa29b9d65.jpg)
OPSS, me stop here, have any problem with chds , with every start of scanning CMP wanna move chds:
(http://store.picbg.net/pubpic/29/F8/e8523f24876729f8.jpg)
if click yes, next start scaning same window !
[PS] About second shot: afetr second scan this 2 chds is missing :
cap-jjk-2.chd and cap-jjk000.chd , not inside folders not in cmp backup folder
chds is deleted !!!
-
well the chd is not bad but wronlgy placed. so cmpro wants to move it...could be that there is a little hickup with fully merged sets under some circumstances...will check it in the evening....
-
Test:
Source .155 ZIP merged set
Load .156 DAT - Configure Full Merged Settings, then "New Scan"
(http://ndsxdelta.no-ip.org/CMP_test_1.png)
I allowed that to continue to completion.
Now rebuilding from Back-up (took a few tries to pick up all available files in back-up folder), then Rebuilding Updates in.
Assuming the Updates were packed & prepared properly..
I should have a full set, but not so..
Miss list is interesting.. I would say I had all these in 0.155 (Example below)
18 Wheeler (set 2) [folder: 18w2 - parent: 18w - size: 8kb]
missing rom: 18w_b1.rom1 [18w2] [size: 2048] [CRC32: cbc0fb2c] [SHA1: 66b14f0d76baebbd64e8ed107e536ad811d55273]
Donkey Kong 3 (bootleg with 2xAY8910) [folder: dkong3abl - parent: dkong3 - size: 61kb]
missing rom: dk3ba-1.3l [size: 8192] [CRC32: d4a88e04] [SHA1: 4f797c25d26c1022dcf026021979ef0fbab48baf]
missing rom: dk3ba-2.3m [size: 8192] [CRC32: f71185ee] [SHA1: 6652cf958d7afa8bb8dcfded997bb418a75223d8]
missing rom: dk3ba-3.4l [size: 4096] [CRC32: 67ac65d4] [SHA1: d28bdb99310370513597ca80185ac6c56a11f63c]
missing rom: dk3ba-4.4n [size: 4096] [CRC32: 84b319d6] [SHA1: eaf160948f8cd4fecfdd909876de7cd16340885c]
missing rom: dk3ba-5.7f [size: 4096] [CRC32: 07d3fd88] [SHA1: 721f401d077e3e051672513f9df5614eeb0f6466]
missing rom: dk3ba-6.7g [size: 16384] [CRC32: 31b8401d] [SHA1: 0e3dfea0c7fe99d48c5d984c47fa746caf0879f3]
missing rom: dk3ba-7.7i [size: 16384] [CRC32: a9263275] [SHA1: c3867f6b0d379b70669b3b954e582533406db203]
Frogger (bootleg on Amigo? hardware) [folder: froggeram - parent: frogger - size: 22kb]
missing rom: 1.d2 [size: 2048] [CRC32: b680e622] [SHA1: 233dbefa2aae6e85cb61acd60c49480bd4a3388d]
missing rom: 2.e2 [size: 2048] [CRC32: 32c56a50] [SHA1: 4d215fff6ff002e23aa889292c9c5eb242975f5d]
missing rom: 3.f2 [size: 2048] [CRC32: 4223a053] [SHA1: c19555d2fee4172dff99d7cf65ebb44d1336c06e]
missing rom: 4.h2 [size: 2048] [CRC32: bcd02aa7] [SHA1: 987c35bf9af8bb1083ccbf4d9f912be8d74b3d1f]
missing rom: 5.j2 [size: 2048] [CRC32: b11b36f7] [SHA1: d4e9342be7fa23f30565d7b75fa0fb8c6c82669d]
missing rom: 6.l2 [size: 2048] [CRC32: a239048a] [SHA1: a8dcc0b4bdb51f6e391832d69ba3a8727be59ae7]
CONTINUED>>>>>
Yes, it seems those .155 ROMs were delicious, CMP & 'The Void' has consumed them :o
Oh boy, I rebuilt some of those Missings into the set,
Scanner Results shows improvement..
But then, exporting a fix_dat ...
Ummm looks like whole .156 DAT was saved.
-
eh?....
nothing really has changed when it comes to standard scanning or unpacking....weird
you are using full merged sets?
-
Only for info, now reverse to previous CMP , after full scan results:
(http://store.picbg.net/pubpic/2F/E8/01da8cc8d45a2fe8.jpg)
This chds is forever removed, not found cmp backup folders or any other folders, scan full hhd - nothing
No problem about that - i have full backups of mame/mess sets.
Tnx :)
oddi "the braveheart" vs "monster" CMP
first round:
0 vs 1
-
Yes Roman,
full merged ZIP
I just made my last edit to my previous post, so I wont touch that anymore.
Maybe I will edit this one a few times more.
Instead of fix.dat whole .156 dat is saved..
Sorry to be the bearer of bad news.
.156 dat states..
<rom name="7408.13b" size="524288" crc="1a947f3b" sha1="ad8d52de54c5a507dd759604613e1d85e13db5fd"/>
<rom name="7408.13b_9efe4c60" merge="7408.13b" size="1048576" crc="9efe4c60" sha1="6462dca2af38517639bd2f182e68b7b1fc98a312"/>
New test CMP Build never solves this problem, it rebuilds the match (7408.13b) in..
A new scan - wants to take it out - wrong size
I could make mini dat - rom combinations for repeating bug & fixing.
-
I'm at the office now...so I can't do anything before tonight...
So let's summarize:
- some weird wrong placed chd warning with removal of them (well...I have an idea about that since I've added a last minute change for wrong place chds...so that should be an easy fixing..)
- unpack errors with some removal of them (ok..that's weird)
- saving of fix dat exports all....(even weirder since that wasn't touched since ages)...
As my brave little testers know...it's a test version, use it on your own risk and only if you know how to get deleted files back ;-)
Ok..now real time work....see you in 12 hours or so....
-
CMP Stable (Merged)
\Funky CMP - MAME v0.156
funkyfig.zip
funkyfiga.zip
CMP Funky Beta (Merged)
\Funky CMP - MAME v0.156
funkyfig.zip
(http://ndsxdelta.no-ip.org/Funky-CMP_1.png)
(http://ndsxdelta.no-ip.org/Funky-CMP_2.png)
(http://ndsxdelta.no-ip.org/Funky-CMP_3.png)
"New Scan", "New Scan" = Loop Forever, DAT attached
Required ROMs
funkyfig.zip
funkyfiga.zip
-
Hey Roman,
You knows me makes easy 4 u to find/repeat bug..
Enjoy DAT, fix this bug first, other not reported bug vanish... haha
Dont u luvs me Engrish.
Later
-
you're killing me
-
So if you're reading this Roman,
then clearly you are looking for an excuse to get your head out of lines of code...
So is there any progress ?
:)
-
All I can say for now is: funkyfiga is a very very evil set....
<rom name="7407.11b" merge="7408.13b" size="1048576" crc="9efe4c60" ...
<rom name="7408.13b" size="524288" crc="1a947f3b" ...
so it maps 7407.11b to 7408.13b (in the parent) which has a different hash than 7408.13b in the clone.....did I mention that I hate merge attributes.....
...and with some other fix your problem or readding files over and over again is fixed...now to the next issue....
-
IMHO the funkyfiga problem should be addressed by MAMEDevs and not by cmpro.
-
well...yes...it looks a bit weird...especially if you compare sizes etc..
however I found a workaround....
still have other things to fix...jeezus....did this ever work here....
-
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141127.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141127.rar)
fixed:
- wrong placed chd issue
- export issue
- funky set
I wasn't able to repeat the unpack issue or the data loss of romfiles which oxyandy reported though...lemme know if you still got them...(maybe it was fixed with one of the other fixes)....
-
(maybe it was fixed with one of the other fixes)....
.........maybe,
I suggested fixing Funky would make 'other not yet reported problems vanish'
- well, as expected those problem are gone now too.
Great work.
I restored my MAME 0.155 ZIP merged set to what it was... (before 1st CMP Funky Beta)
Just downloaded "Sexy Beta II", ready to destroy my ROM set now.
1. No more unpack errors
2. 'New Scan' completed - no errors.
3. I have not done a Scan and fix on old .155 set then Rebuilt from .156 update pack
(might try this later - this is what I did first time & this is where I lost some files, during initial "New Scan", before updates)
4. This time I would have had heaps of .156 files in back-up folder (not cleared those)
Heading out to lunch, so far, so GREAT ! - Zero miss....
Second 'New Scan' had fix prompts,
Third 'New Scan' fix prompts,
Fourth 'New Scan' = no errors, no prompts
I am not testing CHDs
Later guys
-
About chds:
CMP move 3 chds to ROMs folder
(http://store.picbg.net/pubpic/0F/65/edb170f990280f65.jpg)
inside have :
jojojr1/cap-jjk-2.chd [jojojr1]
jojojr2/cap-jjk000.chd [jojojr2]
sfiii3r1/cap-33s-1.chd [sfiii3r1]
i dont touch chds and start again full scan, when start cmp say:
(http://store.picbg.net/pubpic/92/9F/c8deb2d7b6f9929f.jpg)
click "Yes to all" and cmp move chds to him backup folder and report missing chds:
(http://store.picbg.net/pubpic/3F/1C/0d6a8a56e83f3f1c.jpg)
manualy move chds to chd folder and again start full scan, report :
(http://store.picbg.net/pubpic/D7/4A/eff0398cc042d74a.jpg)
if move chd to parent set "jojo" cmp wanna again remove chd :
(http://store.picbg.net/pubpic/57/A0/6e642c60588957a0.jpg)
see the last 2 shots: cmp first remove chd from "jojojr1" folder, second shot - cmp remove chd from "jojo" folder
May have any problem with this chds and correct check main set
post shots from first chd, for other 2 chds is same history.
if i manually add chds to correct parent folders after next scan cmp wanna remove again
Ps: Check chds with chdman, all is correct !
----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-jjk000.chd [jojojr2] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file: g:\MAME\WIP_SVN\CHDs\cap-jjk000.chd [jojojr2]
File Version: 4
Logical size: 65,821,824 bytes
Hunk Size: 9,792 bytes
Total Hunks: 6,722
Unit Size: 2,448 bytes
Total Units: 26,888
Compression: zlib (Deflate)
CHD size: 45,108,605 bytes
Ratio: 68.5%
SHA1: 09869f6d8c032b527e02d815749dc8fab1289e86
Data SHA1: d5a11315ac21e573ffe78e63602ec2cb420f361f
Metadata: Tag='CHTR' Index=0 Length=45 bytes
TRACK:1 TYPE:MODE1 SUBTYPE:NONE FRAMES:26888.
----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-jjk-2.chd [jojojr1] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file: g:\MAME\WIP_SVN\CHDs\cap-jjk-2.chd [jojojr1]
File Version: 4
Logical size: 65,449,728 bytes
Hunk Size: 9,792 bytes
Total Hunks: 6,684
Unit Size: 2,448 bytes
Total Units: 26,736
Compression: zlib (Deflate)
CHD size: 53,553,201 bytes
Ratio: 81.8%
SHA1: 0f5c09171409213e191a607ee89ca3a91fe9c96a
Data SHA1: 74fb14d838d98c3e10baa08e6f7b2464d840dcf0
Metadata: Tag='CHTR' Index=0 Length=49 bytes
TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:26736.
----------------------------------------------------------------------------------
INFO: "<<< g:\MAME\WIP_SVN\CHDs\g:\MAME\WIP_SVN\CHDs\cap-33s-1.chd [sfiii3r1] >>>"
----------------------------------------------------------------------------------
chdman - MAME Compressed Hunks of Data (CHD) manager 0.156 (Nov 26 2014)
Input file: g:\MAME\WIP_SVN\CHDs\cap-33s-1.chd [sfiii3r1]
File Version: 4
Logical size: 100,916,352 bytes
Hunk Size: 9,792 bytes
Total Hunks: 10,306
Unit Size: 2,448 bytes
Total Units: 41,224
Compression: zlib (Deflate)
CHD size: 67,848,619 bytes
Ratio: 67.2%
SHA1: 2f4a9006a31903114f9f9dc09465ae253e565c51
Data SHA1: 47c7ae0f2dc47c7d28bdf66d378a3aaba4c99c75
Metadata: Tag='CHTR' Index=0 Length=45 bytes
TRACK:1 TYPE:MODE1 SUBTYPE:NONE FRAMES:41224.
ps: Sorry the last image, if click No to all result:
(http://store.picbg.net/pubpic/6C/B3/234a365ed8c66cb3.jpg)
-
Hi Roman,
I do not understand Oddi's CHD problem. :o
(I have suggested "dont list mismatches for bad dumps" <---CMP CHD option should be ticked !)
(http://ndsxdelta.no-ip.org/CHD_Options.png)
I do know those CHDs are v4 bad dump flagged.
His get moved to back-up, mine stay put, repeated "New Scan" = no fixes/changes prompted.
I do see a problem with CHDs as follows:
MAME .156 FULL MERGED SET in CMP Scanner/Rebuilder
(Using dat file supplied by Oddi, yes the same DAT file & CHDS, he is having a problem with, I have no problem)
Parse DISK merge tags (TICKED)
I expect to see
\jojo\cap-jjk000.chd
\jojo\cap-jjk-2.chd
\jojo\cap-jjk-3.chd
\sfiii3\cap-33s-1.chd
\sfiii3\cap-33s-2.chd
Instead I see:
jojo\cap-jjk000.chd [jojor2]
jojo\cap-jjk-2.chd [jojor1]
jojo\cap-jjk-3.chd
jojojr1\cap-jjk-2.chd [jojojr1]
jojojr2\cap-jjk000.chd [jojojr2]
\sfiii3\cap-33s-1.chd [sfiii3ur1]
\sfiii3\cap-33s-2.chd
\sfiii3r1\cap-33s-1.chd [sfiii3r1]
See 5x CHDs vs 8x CHDs - Kill the damn dupes will ya :P
EXAMPLE: cap-jjk000.chd [jojor2]
The [jojor2] has now become part of file-name ???
(http://ndsxdelta.no-ip.org/jojo_nono.png)
-
Just a note...
Of course there can be differences in some sets if you scan/fix with developer build and latest productive version....
There are some sets which will now be in a parent/clone relationship while they were not when you used the lastest official version of cmpro...
and so of course you might have some dupes getting alerted/removed now....maybe the mentioned chd sets are some of them...
I will recheck them tonight...
...and if you used a custom dat, send it....or directly include cmpro.ini, <profilename>.cmp and the dat.....
...and also keep in mind that such changes may require two (!) scans...there are some cases (and such parent/clone stuff can be one of them) may have some left overs shown in the scan results tree....(maybe I fix this one day...)..So..please be sure you do 2 scans....
-
Later tonight when time permits, please re-read my previous post Roman, ::)
Problems with CHDs
1. When "Parse DISK merge tags" is ticked, CHDs are being duplicated in clone_name folders. (Unticking "Parse DISK merge tags" makes a better set, without dupes)
Please stop dupe chds being created.
2. Instead of CHDs having the file extension *.chd, some now have the extension *.chd [clonename]
Please standardise all file extensions for CHDs to be only *.chd
Once you have done this and created a new build "Sexy Beta III",
we will re-visit Oddi's (some needed chds being moved to back-up folder problem)
Thanks !
EDIT:
Ok I just tested with ARMAX's (0.156 CHD ONLY DAT) I can not reproduce the exact problem.
For replicating this bug, his dat is useless, it makes a chd set as I expect.
However, (see above *.chd [clonename]) once CMP has renamed chds to this extension,
CMP itself, no longer recognises the files (*.chd [clonename]) as chd files !
This IS Oddi's problem.
1. CMP is changing the default file extension to a file extension to an unrecognisable file ext. (Even by CMP)
2. Oddi is then placing these unrecognisable (*.chd [clonename]) manually in wrong folders
SO, fix 1. & 2. above, Oddi's problem = fixed
Dont over complicate this bug fix :)
DAT file to reproduce ?
If you don't already have one from EXE & CMP, either one of us will upload one for you..
Oddi & myself are presently using exact same dat file..
-
1) Actually parse disk merge tags should create less dupes...so..what did you do?
2) hmm..ehe...well...if you got hash collisions, the chds get renamed exactly the same as roms....internally the name ends with .chd.....but I can change that easily...however I wonder if MAME is able to load chds by hash compare (as it does for roms)...
if not, maybe we have to disable the hashcollision handling for chds for now....(if there are disk-hash-collisions anyway).
3) (comment from post above so it's not forgotten...keep in mind that such changes may require two (!) scans...there are some cases (and such parent/clone stuff can be one of them) may have some left overs shown in the scan results tree....(maybe I fix this one day...)..So..please be sure you do 2 scans...)
-
What did "I" do ? haha you make me laugh, try again what did CMP do ?
No, that's not fair on CMP, CMP did not write itself, a developer did..
Shoot the developer..
Anyway I am sure is a straight forward fix, you have all required info
(I EDITED MY PREVIOUS POST)
Enjoy
Let me know if anything is needed :)
Thanks
-
ah ok...the ".chd" fix is clear to me...fine...yeah....should be an easy fix.
(however I still wonder if MAME loads a renamed chd file by hash compare as it does for roms....I mean area51.chd -> blabla.chd....looks stupid...and I bet MAME fails on this...hehe)
but what about 1) again? you got an example where it created a dupe? ...yes I'm too lazy to read through the posts again ;-)
so tasks for this evening:
- chd extension should be added at the end of the new name (easy...)
- double check if MAME supports loading of renamed chds
- fix 1) whatever it is...
-
a renamed chd file by hash compare as it does for roms....I mean area51.chd -> blabla.chd.
- double check if MAME supports loading of renamed chds
Better idea ? Disable the renamed CHDs.. Leave their damn names as they are ?
CMP Stable, had no problem with merging a CHD set, it's handling of chds needed no further development, did it ?
Yeah, as for 1. I have no idea why CMP now suddenly is:
- ignoring the merge tags for chds
- creating the clone folder & dupe chds..
But if I (we) whine enough, you might just look into why :P
-
ah ok..I will have a look at 1)
...regarding the renames of chds....first I will check if there are existing DISK hash collisions within MAME...
...if there are...I will check if MAME loads renamed ones...which I somehow doubt...
if not I may disable the feature for disks...or introduce the old one (removal of parent/clone relationship) for disk hash collisions...
-
;D
That all... sounds great !
I feel confident you know the exact problem we are facing, which should help you get to the root cause quickly..
Thanks Roman...
-
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141128.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141128.rar)
and now...sleep...till tuesday ;-)
-
Hi Roman,
Good & Bad.
The Good:
Problem with chds (few I tested - not whole set) is fixed.
The Bad:
Memory & CPU usage has increased dramatically.
Switching between [Scanner to Rebuilder] 50% CPU & taking over 2 minutes ?
After clicking CMP [Scanner to Rebuilder] whole CMP vanishes from view for 2 minutes (only taskbar icon visible)
(via right hand lower corner button in Rebuilder window) - I had 0.156 MAME dat loaded
[Rebuilder to Scanner] not so bad, but not like it used to be.
Anyone else seeing this ?
EDIT: DAT I had loaded, http://speedy.sh/u7zMF/M.A.M.E.-v0.156-Nov-26-2014-r242067.xml.7z (http://speedy.sh/u7zMF/M.A.M.E.-v0.156-Nov-26-2014-r242067.xml.7z)
trying new folder setup now.
EDIT2: New CMP Folder setup seems to have fixed it.
Tired too, back to bed..zzzzz
-
Confirmed, cmp work fine with roms/chds :)
for info, fast testing where Mame watching , names, checksums or other :)
[PS] Little play with QMC2/Romalyzer and roms /chds , for roms - we know Mame search checksums, no problem if rom name is rom.bin [set name].
For chds not luck :) , chdname.chd [set name],Romalyzer say: " u not have chd" blabla :)
Roman we wait official cmp out , good job again, many tnx :)
Updates:
sets "royal cards"
cmp add crc32
2.bin -> 2.bin_85e77661 [set name]
2.bin_85e77661 [royalcdfr]
2.bin_85e77661 [royalcrdd]
2.bin_85e77661 [royalcrdg]
and confirmed - new cmp work very slow
-
well why do you compare a dat with an exe based profile. most likely they do differ.
the mentioned royalsomething set got as bad naming and merge tags as funkysomething. mamedevs should have a look at it.
of course scanning with the latest official cmpro gives other results than checking with the test builds (parent clone relationships differ)
the slowdowns. hmm havent really changed a lot from last night build compared to the obes before. maybe a compiler issue. will do a clean build on tuesday. till then tada
-
Roman, about rom names , i think that is not a problem - i retest all my mame sets with maually rename few roms name with random name and etc etc, reload cache database in QMC2 and used Romalayzer for checking roms and play rename game roms - all is fine, game playble, Romalayzer report - checksums fine . I see problem with names only when mame/mess collectors sync databases over internet - - trackers , ftp's and etc etc and used differents CMP versions.
About mame code - yesterday with Oxyandy we found few little bugs "maybe" , 2 or 3 duplicates chds , missing tags "merge=something" and etc.
For atm i used the last test build and think all is fine with my mame/mess roms/chds.
My opinion :)
-
Roman I have done a bit further testing...
I took the new Beta III binaries you posted,
dropped them into a fresh official 4.015 download, over writing the existing files..
Configured everything from scratch.
All seems to be working great ;D
Nothing to report
Rest well
NOTE:
Others testing Roman's latest beta should do the same (as above) dropping into an existing pre-configured CMP folder is not advised.
I'm sure feedback is welcomed, how's does it work for you ?
Oddi, yes the DAT we were looking at, has some missing <merge tags> which could prevent duplicate chds being created.
Not cmp related, hopefully a future MAME release has those omissions corrected.
-
with all ok you mean no slowdown? havent checked the release binaries yet and wont do before tuesday.
regarding naming mame 156 got 4 or 5 sets with some naming issues where merge tags result in double romnames which cmpro also handles with some postfix checksum. I will check if there is a better solutiion. ..... next week
-
with all ok you mean no slowdown?
Correct, no slowdown
-
Interesting......
....and I guess I found now a proper solution to the double roms issue with lucky8a royalcdfr royalcrdd royalcrdg and that funky set....
-
I saw your post yesterday, then it's edit..
Is there anything you want tested / feedback with ?
Let us know.
-
well...I found a way how the double roms. of 156 are read in correctly so you dont need the crc poststring....currently I got two more things on my todo list which I need to get sorted before we come closer to a (test) release....I will shout if I got something....
-
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141204.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141204.rar)
well...only change is the new double-rom handling (lucky8/lucky8a, royalcdfr/royalcrd/royalcrdd/royalcrdg, funkyfig/funkyfiga in MAME .156)....the double roms (based on some weird merge tags) don't really need a rename (crc poststring) since in split mode, you won't be able to create overwrites and in full merge mode, the new hash collision naming will solve the problem...
-
Roman, u are Master !!! :), test this build - fix problem with "evil" funky and "royal" sets and etc etc.
Have one question :
"Normal mode" and "Hash collision names"
Normal mode - CMP add [set name] only if have collision.
Hash collision name - CMP add [set name ] to all merge sets with or without collision
thats right ?
and tnx :)
-
Well...normal mode means that you got the full merge mode as you know it...from the past...from the current version...with one exception: In case you got a clone set which got a hash collision with its parent/other clones, this set will have different rom names (the way the name is formed can be setup by yourself).
"hash collision mode" (well...I know 1 user who may need this mode ;-) ) means that you can arrange ALL sets in such a new-naming-way....so each clone can be named differently...Actually this may only be useful if we use a pattern which allows subfolder usage....."%f/%1"
-
Many tnx for answer :)
About variables %f [%1] - me think dont touch this parameres , good show :)
That is my opinion.
Btw -fast test my mame sets with "hash colision" enable - and CMP wanna rename million roms , heheh :) , normal mode is good choice because CMP safe original roms names and rename only colisions.
Again very good job :)
-
I still wonder if it makes sense that - in case of a hashcollision - what gets renamed:
- in the wip version it's "the affected cloneset, but all rom files, no matter if only 1 had a hash collision"
you might also think of
- "only rename the affected romfile(s)" (pro: less renames, con: maybe visibility quality within a full merged set)
- "rename all roms in all clones of the current parent/clone relationship" pro: better visibility con: more renames
opinions please....
-
I thnik - rename only affected roms not sets:)
So Mame dumps will be as close to their original names, only few affected roms have differents names.
-
but it looks stupid if you use subfolders ;-)...then you got some rom files of clone A in a subfolder (the files with collision) while the rest of clone A stays in root....
...that's why currently all roms of A end in the subfolder...
...I only wonder if clone B, C ... should also get their own subfolder/naming....even if they don't have collisions...
-
No no Roman, idea with subfolders is closed! finito , fin , end :)
i say about rename affected roms - rom.bin [ set name ] , this idea i like it when cmp rename only affected roms. :)
Now CMP the last beta work perfect, CMP rename only affected roms and dont touch others :)
-
no...currently it renames ALL rom files of the cloneset which got at least one hash conflict...not only the romfile which got the conflict...
-
ok boss, i agree with u and wait final version :)
-
found a little hickup regarding the hash collision change with nodumps though. (nspirit)...fixed now....
...and oops..I was wrong...currently it already renames all roms in all clones of affected sets... (and not only the clone which got a collision)
...and added a check for "release" element users...(if you don't know what it is...don't worry...)
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141206.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141206.rar)
-
Fast testing my suffered full mame set ,
i do not see anything for notes , whole is perfect :):):)
Bug - with every start and scan CMP wanna rename royal card set roms. attach set
-
hmm...yes...have to check that again....*sigh*
-
ah yeah..the just added nodump fix had a little sideeffect...wow..these weird double rom sets with hash collision and nodumps are annoying..
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141207.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141207.rar)
-
Tnx, now - problem with royal fixed, cmp too remove many double roms, think that is good, atm not found bugs. :)
-
Next Steps...
hmm...so may mood now says keep as less renames as possible....but since my mood changes often, I simply add some radio buttons which will allow you to use what you prefer:
- single file (only the clone rom file with the hash collision gets renamed)
- clone set (only the complete clone set where a hash collision happened)
- all clones (all clones within this parent/clone relation)
....and I guess I will switch to subfolders as default again ;-)
Timeline...well....hope to put out another test maybe tonight......and a release...maybe next week....or January ;-)
-
http://mamedev.emulab.it/clrmamepro/binaries/cmp20141211.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20141211.rar)
now with %f\%1 as default naming which mean set subfolders...hurray ;-)
...and a "profiler options" option to select how many files get renamed....
- single file ...only renames the clone file with a hash collision
- single clone ... all files within this clone
- all clones ... all files in all clones of the currently affected parent/clone relationsship
(this option aren't used when you turn on the hash collision full merge mode....but that's a different story..)
default is sinlge file for now to achieve less renames as possible...and with subfolders you don't really have renames anyway...
Such options can be switched without restarting cmpro/reloading profile.....also merge modes can be switched as you like..
happy testing ;-)
-
Roman, all is fine :) , need other users for mass testing.
i change options to:
(http://store.picbg.net/pubpic/32/4F/900ca5164d3f324f.jpg)
and safe my suffered mame sets :)