Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Roman]

3.133b

added: support for mess software lists (either as hash/*.xml file or via -listsoftware output)
misc:  don't show archive errors for no entries in rar part files (partxx.rar format only)
misc:  64bit version uses version64.ini and version.ini as fallback
misc:  slight speedup for several routines
misc:  showing chd region count in title when not enabling all
misc:  trim filenames in dats and remove "." from end of folders and files in datfile
fixed: wrong "illegal download" message on clean install
fixed: rare wrong named chd stats count issue

[etabeta]

3.133b

added: support for mess software lists (either as hash/*.xml file or via -listsoftware output)

thanks a lot, Roman

[Ricky74]

3.133b

misc:  64bit version uses version64.ini and version.ini as fallback

Thanks !!!

[Firewave]

Regarding the softlist support - it seems, that changes to the .xml are not being detected and even when I update it with "Add DatFile..." I still need to clear the cache, so it will use the new data.

[etabeta]

pre-release exe (32bit) worked perfectly fine here: I was able to Add the modified datfile (which overwrote the original one) and next time I selected the correspondent profile the new dat was used (e.g. a New Scan was needed and changed names were detected). Actually I was using this feature all the time

I will test tonight with released 0.133b

[Roman]

Regarding the softlist support - it seems, that changes to the .xml are not being detected and even when I update it with "Add DatFile..." I still need to clear the cache, so it will use the new data.

not repeatable here...and very unlikely. cmpro stores the crc32 of the datfile in the cache file, too (and actually it's named after its crc32). If you change the dat in any way, its crc32 will change (assuming that the chance of hitting a hash conflict here is minimum) and the dat is read in instead of using the cache.

[Firewave]

not repeatable here...and very unlikely. cmpro stores the crc32 of the datfile in the cache file, too (and actually it's named after its crc32). If you change the dat in any way, its crc32 will change (assuming that the chance of hitting a hash conflict here is minimum) and the dat is read in instead of using the cache.

OK, tested it again and it worked fine. Only thing I recognized, that the state in the Profiler still showed green, although it is actually undetermined. Unfortunately I didn't check the "Scan" state, which should also be invalid in that case.

[Roman]

hmm..well..normally a replaced/overwritten dat should reset the profile icon status....I will check this.

[etabeta]

I confirm that the icon is not updated (it remains green) but that, correctly, only New Scan is available when you load the new profile.

[Roman]

Then try to 'official way' :O)....don't replace the file, but let cmpro update it when it asks you if you want to create a new profile or update an old one....
I may look into the color thing somewhere in 2011

[Firewave]

What's the 'official' way? I use "Add DatFile..." to load the updated version and it detects, that there is already a file with that name and asks me, if I want to replace it. Since it won't detect changes to the .xml by itself I see no other way.

[Firewave]

I reproduced the other issue I was having.
I was updating the SCV set in MESS the way I described. It was just a changed set name and I had a complete set. I ran a "New Scan" and it showed the renamed set is missing a rom, but not the complete set (although it just contains the single rom). I checked the archive and it was renamed and it had the proper file inside. Then I once again chose "New Scan" and suddenly I had no missing roms anymore without changing the archive. So something is fishy there.

[etabeta]

what happens here is similar but not exactly the same: the first run renames the zipfile but marks the content as wrongly named; the second run asks me to rename the rom inside the zipfile and then it gives me the correct result.

I haven't checked, though, if the rom inside the zipfile got corrected at the first run (and just not correctly reported in the statistics) or not renamed at all. I thought it was due to the order clrmame tries to fix the incorrect names, so I didn't investigate any more the problem.

[Roman]

can you give a step by step description of what you do, which files you change...prepare me a package of files...
however I won't be able to look at it before monday evening...

"I ran a "New Scan" and it showed the renamed set is missing a rom"
This sound wicked since it should list the set as wrong named with no additional things about roms....

[etabeta]

I think I have reproduced the problem by running a batch scan (with all fixes enabled) using more than 1 profile, after having changed e.g. a single set in a single dat (but both setname and romname). both names get fixed properly during scan, but the statistics report the rom as wrong named.
at a second scan they are correctly reported as good in the statisctics.

[Roman]

batcher is just a sequentially profile load and scanner call. I need some step by step example with the files to repeat this here. as mentioned, no work until monday evening. enough time to send me some examples

[Firewave]

I will prepare the data for the issue later.

I ran into a possible other issue. When you are rebuilding a set and the disk runs out of space it asks you, if you want to stop processing the roms. If you do some clrmamepro will leave a 0-byte file (I think in case, that it was trying to pack the first/only file in the archive - was rebuilding n64 stuff).

[Roman]

well...but where's the issue?
ok...it doesn't clean up the failed rebuilt file....but hey...it's not that bad, ain't it I will check the code for that...

...the other reported one is more interesting....

[Roman]

ok...found out what's happening with the 2 pass wrong name/missing rom thingie...will be fixed for next version