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

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.

441

clrmame Discussion / Re: Validating samples in clones

« on: 03 December 2020, 19:49 »

well...it's pretty easy to see....open scanner->scan results->setinformation and click on the (clone) sets...then you see if samples are listed there or not.

Either way, for sample sets it's not so important.
For roms, you either prefer full merged or split merged sets. So in split merge mode, you got a clone set with the roms which differ from the parent. In case of roms, this is pretty typical...different regions, different sprites, blablalbal... but for samples it's not. You usually don't have samples which only belong to one specific clone, so you don't really have "split" sample sets.
....and for emulator use it doesn't play a role either since e.g. MAME simply looks everywhere for the files it needs.

442

clrmame Discussion / Re: Validating samples in clones

« on: 03 December 2020, 17:07 »

I removed the parent but left the clone with the sampleof tag and I would get “Missing alternative sample folder will be added as sample-only set”. Does that mean that ClrMamePro tried to correct it and the samples will be parsed with the same name as the clone so dkongpe would be the correct sample name vs actually being dkong due to the parent being not present. Basically it separates them?

A set is generated which takes the samples from the clone and uses the name of the (not existing) sampleof element.

If I remember correctly this was also needed for invaders which had a setup where the parent did not have samples listed but each clone...or something like that....can't remember

443

clrmame Discussion / Re: Crash/Close Out /w Many Scan Result Messages

« on: 03 December 2020, 06:44 »

The exit without an error is really interesting since it means that no buffer overflow/out of memory or assertion/execption was thrown. It looks like the OS simply kills the thread nicely. Like if it seems that some app is causing lots of network traffic, it closes it. Cmpro simply uses win32 api calls to open/read files / walk through dirs...so there is nothing really evil...just lots of requests

Have to google a bit more about it.

Maybe you can play around with the thread priority (Settings->Compressor->General) and set it to something less than normal.
Or in cmpro.ini you change the following settings and restart cmpro (default was 'off' if I remember correctly, just toggle its state).
Adv_ShareRead = on
Adv_ShareWrite = on

444

clrmame Discussion / Re: Validating samples in clones

« on: 03 December 2020, 06:39 »

Good question. The normal structure would be that the clone got the sampleof element listed AND lists the samples (as it does with rom clones). Haven't used old dats in the last 15 years or so
Actually I have to check how this gets parsed. Either cmpro automatically takes over the samples from the parent if it finds the sampleof element or it ignores the sampleof element since the set does not list any samples and thinks it is a flaw in the dat....

So....I have to check what it needs....stay tuned.

Update: If I see this correctly, as long as the clone doesn't list any samples it got no samples, no matter if there is a sampleof or not.
but then - being picky -  the sampleof element should be removed. If it should use samples (from the parent), they should be listed.

445

clrmame Discussion / Re: Crash/Close Out /w Many Scan Result Messages

« on: 02 December 2020, 20:18 »

Ah...Samba...There is your issue
Not joking but years ago some user reported problems with rebuilding files using samba shares (actually you can google clrmamepro + samba .

The rebuilder simply skipped files or simply completed even if not all files were processed. The reason for this was a problem with SAMBA. If I remember correctly the user solved the problem by updating network drivers or he changed his configuration or checked his network timings.

I've did some SAMBA tests myself in the past but wasn't able to repeat such a behaviour

So really hard to say what to do.

Check if you can update network drivers, check access rights, cables, stress test the network etc...google Samba file access problems...sorry...but at the moment I don't have a better advice.

446

clrmame Discussion / Re: Crash/Close Out /w Many Scan Result Messages

« on: 02 December 2020, 18:14 »

Just scanned a huge dat without having any roms at all creating a huge scan results output and not "crash out".
Neither reported any user such a thing until today.

Maybe one of the 3rd party libraries (rar/7z) create a problem when fixing/working on a corrupt archive. So it would be interesting to find out when the problem appears.
What you can try:
- limit your amout of files (e.g. only a few files in rompaths)
- run with no fix options
- try to turn off other applications which might interfear (virusscanners)
- try different hardware (external hds, etc)
- and try to find out at which position (game description in the scan progress window) the application closes...you might get an idea which sets are affected.

447

clrmame Discussion / Re: Can't Load / Update from MESS 0.226

« on: 21 November 2020, 17:59 »

Load it as MAME, not as MESS.
The MESS exe type is for the "old" original MESS before MAME and MESS were merged.

448

clrmame Discussion / Re: Two Small Feature Requests

« on: 18 November 2020, 18:50 »

2) https://mamedev.emulab.it/clrmamepro/binaries/cmpro20201118.7z

449

clrmame Discussion / Re: 32k Path Length Issue

« on: 18 November 2020, 18:43 »

Fixed in next nightly....

funnily enough the path is exactly 260 chars long (which is identical to the system's MAX_PATH).
But hitting this means I have to auto add the 32k prefix stuff....so I had to change the check from < MAX_PATH to <= MAX_PATH

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20201118.7z

450

clrmame Discussion / Re: Two Small Feature Requests

« on: 14 November 2020, 09:00 »

1) profiler context menu  -> Hide -> red/green/grey
2) oh yes...that's something I want too

451

clrmame Discussion / Re: 32k Path Length Issue

« on: 12 November 2020, 18:43 »

did you use the lastest nightly?

If no, try it. If yes, send me the dat, the file in question, your *.cmp file (cmpro's settings folder) and cmpro.ini

452

clrmame Discussion / Re: 4.038a - Extremely long scan time (titles.zip resource)

« on: 05 November 2020, 11:21 »

"Why did ClrMAMEPro re-zip them into the 7z archive?"

If it does that on your machine then you're using 7z archives. Simply as that.

cmpro autodetects how you stored your sets (either not compressed or rar/zip/7z). So you store your snaps in titles.7z it of course adds found missing files into that 7z. "Adding" can mean different operations. Adding from one zip archive to another takes no time since it copies the compressed data. Adding from a decompressed file to an archive takes compression time for that file. Adding to a solid 7z archive means repacking the full archive.

Again, for progretto snaps I'd go with decompressed sets (at least for checking).

453

clrmame Discussion / Re: 4.038a - Extremely long scan time (titles.zip resource)

« on: 04 November 2020, 06:03 »

Titles/Snaps/Bosses/etc etc don't have to be zipped/7z'ed/rar'ed at least not for checking. For the actual use it depends on the frontend.
Regarding fix progetto snaps, I usually do the following:
- run a scan with all fix options but fix missing
- use the rebuilder to add the update packs and if something is still missing you may rebuild the backup folder to readd stuff which was put there. Most of the time you end up with 100% if not you may want to take a manual look at it

454

clrmame Discussion / Re: 4.038a - Extremely long scan time (titles.zip resource)

« on: 03 November 2020, 18:20 »

If I add it yes, for now: no
For such 1 sets-100000 files sets it's currently better to follow my advice from the start of this post

455

clrmame Discussion / Re: 4.038a - Extremely long scan time (titles.zip resource)

« on: 03 November 2020, 05:38 »

Turn off fix missing and belonging advanced fixed missing options.

The reason is that progetto sets consist of 1 set with thousands of files and often it holds a pretty large amount of pngs placeholders (identical 'default' pngs). So if you miss them, cmpro looks into the set (and addpath, backup), finds it somewhere and adds it (recompress), then the next one...same procedure again...and again...when using compressed sets it's evil....when using solid 7z archives it's hell.

For progetto snaps it's better to add files with the rebuilder instead of using fixmissing...and consider simply using not compressed files instead of archived ones.

456

clrmame Discussion / Re: Missing ROMs but empty scan results

« on: 26 October 2020, 17:06 »

So what's confusing? fixing missing files works exactly like that.

hng64 missed 3 files and cmpro found the files in other places, so "fix missing" automatically added them and so hng64 won't appear in the scan results tree since it's ok now. If you don't turn on the fix options and you got the 3 files missing in hng64, you will see hng64 in the tree appearing. So it works as expected since the tree result only shows problems. The stats most likely shows something like 3/3 missed/fixed whatever.

cmpro looks in addpaths, backup folder and parent/clone relationship sets for missing files and in your case it found them somewhere there....

457

clrmame Discussion / Re: Missing ROMs but empty scan results

« on: 26 October 2020, 10:29 »

here we go: https://mamedev.emulab.it/clrmamepro/binaries/cmpro20201026a.7z

458

clrmame Discussion / Re: Missing ROMs but empty scan results

« on: 25 October 2020, 16:41 »

Well, I actually thought that your intention was to use not merged sets ;-)
...but there's a lack in your plan. Device sets. Nearly each set requires device sets, too...and they aren't put in a non merged sets and currently they are not handled like non-separated-biossets.
I already got requests to add something similar for device sets but had no time yet to add it.

For sure I will double check the missing tree print out very soon.

459

clrmame Discussion / Re: Missing ROMs but empty scan results

« on: 25 October 2020, 13:25 »

ok...I can now for sure tell you that your stats/scan results tree mismatch is based on the disabled "separate bios sets" option.

If this mode is enabled and the bios sets itself misses files (but all the sets using this bios got the bios files included already) show no entry in the scan results tree but stats count them as missing.
This is of course a wrong behaviour. It should list the bad bios set in the tree. I will check why it does not appear (for whatever reason cmpro might saw the existing files in the single sets and didn't pop out the bios itself).

Thanks for helping me by sending your config.....but you should really think about split merged mode and separated bios sets....you will gain diskspace.

460

clrmame Discussion / Re: Missing ROMs but empty scan results

« on: 25 October 2020, 13:18 »

One thing I've spotted in your settings is Scanner->Advanced -> you got "Separate BIOS sets" disabled. This means you waste pretty much space by keeping the bios files in each and any set instead of keeping them separated (e.g. each neogeo set keeps the neogeo bios files instead having 1 neogeo.zip holding them). Disabling that option is very very very rarely used...actually so rarely used that I can imagine it's the cause of your stats issues. I will do some checks on that option but you should turn that option on. The same option exists in rebuilder->advance.
And you're using non-merged sets...again, not a good idea. You waste a lot(!) diskspace and actually nobody uses this
The common modes are split merged or fully merged sets (split sets / merged sets).

So...really think about switching your merge mode to something common ;-)

Regarding chd versions...no luck here to repeat the behaviour yet.