Please login or register.

Login with username, password and session length
Advanced search  


The new forum is online, hope you enjoy it!

Show Posts

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.

Messages - Roman

Pages: [1] 2 3 4 5 6 ... 140
clrmame Discussion / Re: clrmamepro 4.038a released
« on: 11 August 2020, 16:29 »
It's working fine for me....attached 2 example dats.
Maybe you have the option disabled to remove the old one. Profiler->Options->Remove old Datfile after update...that one should be checked.

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 09 August 2020, 17:43 »

This should solve problems with not found "unneeded" sets like cricket and wrong suggested renames between software lists like dorse93.

Regarding "pro student", well yes, if you have 2 subfolders for the chds, the full merge mode will moan about it and will move the one chd to the parent. You said that "The "r" CHD is still in the prostudg folder,")...and that means the actual move failed. Why? I don't know. Maybe the folder was somehow locked by the system...the rest are sideeffects of the failed move.

"3do_m2", as mentioned, you don't have them in a direct -listsoftware import from MAME...only available in the single hash files

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 09 August 2020, 13:07 »
split/full merge mode is only available if the software list support parent/clone relationships. No relationships, no merging

regarding "3do_m2" sets, actually MAME's direct software list import (-listsoftware) does not even include this as a software list.
MAME does filter some of the hash files for whatever reason when using the -listsoftware option.
The direct import only has imsarcng for the PSX software list. That's the reason why you didn't see the 3do ones yet.
If you use the hash files directly, you can access all data.

Regarding the former "unneeded" problem, I rewrote the algorithm in the meantime, making it much more logical and not fuzzylike...
I can't repeat you  pro student problem though....

I will prepare a new build for you soon.

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 09 August 2020, 07:48 »
Thanks for testing, yes the old algorithm might mark some unneeded sets as unneeded...As mentioned I will look into that a bit more. To make it clear...this is only for combined mode and only for sets which share the same name.

1) good
2) no, fmtowns_cd has no parent clone relationship for the 2 dorse93 sets, so there is no merging. You can see that in the hash file for fmtowns, so...also ok

3) I will look into this

imsarcng/etc...I will look into this

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 08 August 2020, 20:19 »
Hmm..that file belongs to bbc_cass and not electron_cass

If you stored it in electron_cass (do you really have it there?) then it's indeed wrong...but maybe you already have it in bbc_cass, too

I actually wonder how the change of the algorithm should have an impact on this...I will double check that tomorrow

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 08 August 2020, 19:55 »
well......usually you simply drag'n drop all the files from MAME's hash holder into the profiler.
The first time when you do that you need to setup rompaths for each profile....the batcher (select more than one datfile at hit load) allows some automatic creation for them in the misc tab.
The next time cmpro should see that the files you've dropped are updates to the existing ones (like it does for other dats, too).

If you already have them due to your current setup, you may need to reassign them one on one....yeah..bit manual work to do.....

But in general the combined mode should work....I'm aware of the algorithm which may cause the problem...let me know if the tweaking helped you...otherwise I need to get rid of it ;)

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 08 August 2020, 19:09 »
hard to setup the scenario, while I got an idea about the dorse93 thing I cannot reproduce the pro student one at all.

The problematic part is part of some kind of fuzzy game match algorithm which in case of sets with double names may pick a wrong positive from time to time...*sigh*....I've done a bit tweaking on it (however it should go to the bin if you ask me) but anyway...

you may want to give this a try:


would be interesting to know if that one opens the door to other weird sideeffects or not ;-) so better run it without fix options....

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 08 August 2020, 10:20 »
Trying to build up a minimum scenario but no luck yet...

What I've tried: MAME .223 exe imported only pc98_cd + fmtowns_cd software list
setup 2 rompaths, 1st one for  fmtowns, 2nd for pc98
Systems->only enabled pc98_cd + fmtowns_cd [SOFT] lists
SetInformation->Select sets "dorse93*" + Apply -> this enables the 4 sets in question

The rompaths hold
fmtowns_cd\dorse93\dor se (special edition) '93 (japan).chd
fmtowns_cd\dorse93a\dor special edition '93 (alt).chd
pc98_cd\dorse93\dor se (special edition) '93 (japan).chd
pc98_cd\dorse93a\dor special edition '93 (alt).chd

Run a scan with default options but disabled samples in split merged mode.
Nothing bad found...result is good...

So maybe you should send me your cmpro.ini and your belonging used cmpro_folder\settings file for the used profile.

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 08 August 2020, 06:55 »
do you use split or merged sets?

A quick setup in a combined mode and only pc98_cd and fmtown_cd sets enabled doesn't show any problems though...Need to find more time to look deeper into it.

clrmame Discussion / Re: clrmamepro 4.038a released
« on: 07 August 2020, 20:53 »
You are using the combined software list mode or each softwarelist got its own profile (prefered method)

But I will look at it a bit closer over the weekend.

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 07 August 2020, 15:02 »
thanks for reporting/testing...now get the update 8)

clrmame Discussion / clrmamepro 4.038a released
« on: 07 August 2020, 15:01 »
added: support for zip/rar/7z aliases (e.g. jar/cbz/cbr/cb7, etc) in Settings->Compressor tabs.
       So you can now scan e.g. jar files like zip files etc
       The alias settings allow multiple values separated by space, so e.g. .cbz .jar .war
added: zip property tab in Settings-Ccompressor with e.g. zip compression level setting option
misc:  use a private use utf8 char for internal set subfolder handling, so all kind of apostrophes
       'ยด` in rom/setnames are allowed again and won't be replaced
misc:  speedup multi 7z/rar delete opertions by using filelists
misc:  updated rar dll
fixed: some zip circular rename operations could kill files
fixed: some zip renames could create dupes (4.038a) (MAME .223 v4mdice v4monte issue)

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 07 August 2020, 11:33 »
as discussed...seems they are caused by some dupe entries in the zip.
Will do addtional testing and try to fix it as quick as possible.

By the way, "Settings->Compressor->General->list archived files with double names in warnings window" helps you to find such dupes.

Seems that only v4mdice and v4monte got the dupes problem, in the meantime I fixed the problem and will release a new version soon.

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 07 August 2020, 09:02 »
But if the zip file content is the same as before (no additional files, no missing files, same files bytewise), why does torrentzip create a different output then...sounds to me more like a torrentzip weirdness....or do you see differences in the content?

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 07 August 2020, 08:20 »
Thx, I will have a look...but again...torrentzip is not something I care for....and especially not the size of a zipfile.

It's only important that the zips are correct in terms of content.

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 07 August 2020, 06:44 »
TorrentCheck? What does a torrent check size compare tell you about the correctness of romsets? Nothing. Especially not the size of the zip itself.
A circular rename renames in 2 steps, so it may even alter the order in the zip twice.

So, please give me a repeatable example with standard clrmamepro and such sets and tell me where it goes wrong.

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 31 July 2020, 11:06 »
Fixed for the next version..thanks again

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 30 July 2020, 21:16 »
ok it seems to be a problem within the used zip library's rename operation when having constellations where you got sort of circular renames
...need some more time to dig deeper into this. By the way, only zip is affected, rar/7z archives work fine in this scenario.

Thanks for reporting.

clrmame Discussion / Re: CMP 4.037a scanner ROMs deleted
« on: 30 July 2020, 15:46 »
>I'm not sure why CMP comes to the conclusion that they need to be renamed.

Because they changed their name (you need to go by sha1)

<rom name="mslug3h58\256h58.p2" size="4194304" crc="9e2064e6" sha1="d807eb56aebd7f5e8b43b67291856ebb07130c1b"/>
<rom name="mslug3h48\256h48.p2" size="4194304" crc="7593474c" sha1="fcdd76013069eff64dc6842c672870854a53c0f2"/>

<rom name="mslug3h58\256h58.p2" size="4194304" crc="15bb1f0d" sha1="bf0a6bf38a4addcf9a7a08b04943594666347d6a" />
<rom name="mslug3h48\256h48.p2" size="4194304" crc="9e2064e6" sha1="d807eb56aebd7f5e8b43b67291856ebb07130c1b" />

Since I don't have the romsets (neither .222 or .223) I can't check deeper.....but I don't think something is lost. There are cases where things are put to backup and need a 2nd scan to get readded or get rebuilt......You said you tried that and didn't work....so I first need the files for doing another check.

ok, replaced the internal use of ` with a real private use utf8 character which then allows all apostrophe types again in your dat/files.
No new nightly build yet since I'm just back from holiday and have to deal with real life a bit first ;-)

Pages: [1] 2 3 4 5 6 ... 140

Page created in 0.104 seconds with 20 queries.