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.

401

clrmame Discussion / Re: ClrMame Pro seems slow scanning Maygay Roms

« on: 29 January 2021, 12:14 »

Erm...nope

Full standard (splitmerged/zip/no softwarelists/nosha1 deep check) MAME 228 scan takes around 46 seconds on a low cost ssd/full cache.

You may need to check if other 3rd party tools (like virusscanners) interfear.

402

clrmame Discussion / Re: Upgraded to newest version, auto-assign no longer works properly.

« on: 27 January 2021, 06:41 »

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

403

clrmame Discussion / Re: Suggestion...

« on: 26 January 2021, 07:01 »

yeah such a thing is possible to add....

404

clrmame Discussion / Re: Hope to add more option for set-info select sets

« on: 22 January 2021, 08:13 »

As mentioned, this is very unlikely in this version since only parts from the XML tree are actually used and parsed during import.
Adding new fields (which are most likely very very rarely used) is not a quick way to go....so maybe some kind of preprocessing the xml output with tools (e.g. xslt stylesheets) is a better approach for now.

405

clrmame Discussion / Re: ClrMamePro says 'wrong name' wrongly?

« on: 22 January 2021, 08:10 »

Ah ok...I now know what might have happened...
Indeed the uk6 rom is obsolete since it now belongs to a refenced device. So it should be placed in the belonging device set and not in the set itself.

Now you got it in your zipfile and cmpro detects the file where the name doesn't belong to the set, so it looks more closely by checking its hash to see if it is just a wrong named file.
Unfortunately this set also holds a hash identical file which does belong to the set (5c). The name check finds a matching hash and says that the file is wrongly named and should be named like the 5c one. It doesn't see that this file already exist. Fixing the name will most likely fail since the file already exist.

So...the name check works, the proposed name is also ok, the fact that the file is already there is not taken into account during the check.

Pretty rare case...in this case you need a little manual involvement to get rid of the file (or you turn off the "name" check and only keep the "unneeded" check).

If new sets are added via the rebuilder, such things won't happen. But it happens when the set exists in that form from a previous MAME version and MAME decided to separate a file as device or bios or parent etc....but such affect only happens when in addition you have the hash collision here...

So...actually I wonder why the .5c file is not defined as device rom as the .uk6 rom....maybe this should be double-checked by MAME devs.

406

clrmame Discussion / Re: ClrMamePro says 'wrong name' wrongly?

« on: 22 January 2021, 06:43 »

Hi again,
sorry for the quick and dirty answer yesterday...I did not look closely enough into it.

After checking the listxml output of latest MAME I see that there seems to be an issue with that one set and that file/set.
I need to check why it includes the (identical) device rom there and why this is causing the naming weirdness.
Since it doesn't do that here, I need to take a closer look.

What merge mode are you using?


Regarding software lists: I strongly recommend to keep them separated. So 1 profile per software list. This has various reasons:
- not all software lists are actually listed in MAME's -listsoftware output
- setting up 1 profile for all software lists plus MAME is a pain
- hard to actually differ between them if everything is in one
- slow
- etc...

So for each file in MAME's hash folder (these are the software list 'datfiles') create a profile. Scan them with cmpro's batcher all in a row...

407

clrmame Discussion / Re: Launching from a Network Path Broken in Latest Releases

« on: 21 January 2021, 19:33 »

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

408

clrmame Discussion / Re: ClrMamePro says 'wrong name' wrongly?

« on: 21 January 2021, 19:14 »

You need it twice then.
You can simply rebuild the set and the rebuilder will create it for you automatically...or you clone it manually.

409

clrmame Discussion / Re: Hope to add more option for set-info select sets

« on: 21 January 2021, 12:03 »

See Select Sets description.....(attached screen).
They are supported. It's very unlikely that more will come....they are not really that important to select sets....

410

clrmame Discussion / Re: Launching from a Network Path Broken in Latest Releases

« on: 20 January 2021, 07:14 »

The changes from 4.038a to 4.039a should not affect anything like that at all...but I will have a look.

411

clrmame Discussion / Re: Dates don't match

« on: 11 January 2021, 08:34 »

Actually the latest nightly works like this:

- Rebuilding to zip with recompress enable, creates the right date from the dat
- Rebuilding to a decompressed file on NTFS, rar and 7z creates a file where the offset to UTC is included..

- Scanning/fixing a zipfile works fine
- Scanning/fixing decompressed/rar/7z will create a fixing loop due to the UTC offset

I love it...*sigh*...working on the decompressed/7z/rar time handling.....till then..use zip


ok...tried to handle decompressed files now as UTC based (which also is the reason for 7z/rar)

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


This should fix the upper stuff...again I find it hard to say what is right if we talk about preservation...and especially if you look at it....you see the dat with 00:00:00 and you look at the archive or the file and you see an offset based value......something to think about when I got more time...but at least you shouldn't run into scan time fixing loops.

412

clrmame Discussion / Re: Dates don't match

« on: 10 January 2021, 19:55 »

It does, the problem is your filesystem which applies local timezones...so e.g. for me setting 00:00:00 will end up with 02:00:00 due to the local offset.
I'm working on it...

413

clrmame Discussion / Re: Dates don't match

« on: 09 January 2021, 19:54 »

Ah sorry...... I falsely looked the fix dat which does list 1970 and for 1970 all my comments are correct. Your original dat indeed lists 2010-04-06 which is not parsed correctly and it is reset to 1970 since it's not in correct format. It's being reset since the datetimestamp is missing. The date attribute should hold a date time string... YYYY-MM-DD HH:MM:SS.... or YYYYMMDDTHHMMSS

But I guess I can support a YYYY-MM-DD, too


Indeed I can.....
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210109.7z

414

clrmame Discussion / Re: Dates don't match

« on: 09 January 2021, 18:22 »

Erm....you're mixing 2 things.....file definitions and actual filesystem dates.

Your datfile defines the files as 1970-01-01 00:00:00. When scanning/fixing decompressed files on an NTFS filesystem, cmpro will fix the last modified date of the files. Windows won't show it correctly though but on commandline level it is shown as 1970-01-01.

Then you got archivers like rar/zip. The rar/zip format uses MSDOS date format which means the earliest date is 01/01/1980.

And if you create a fix datfile cmpro simply dumps the datfile again but limited to your missing files.

415

clrmame Discussion / Re: Dates don't match

« on: 09 January 2021, 08:42 »

If you create uncompressed files you see on commandline level that the date is correctly set.

Archives (rar/zip etc) store dates in standard MS-DOS format which only allows dates from 1980 onwards....

Bits 00-04: day
Bits 05-08: month
Bits 09-15: years from 1980


So...everything is fine

416

clrmame Discussion / Re: Error in rebuilding some TOSEC dat with long path and zip compression

« on: 08 January 2021, 17:49 »

Cache doesn't play a role here....but good to hear it's working for your.

417

clrmame Discussion / Re: Error in rebuilding some TOSEC dat with long path and zip compression

« on: 07 January 2021, 18:19 »

ok...found the problem, it was related to the length and there was one place in the zip code where the auto-32k support was not enabled yet...
Will be fixed in the next nightly (whenever that is coming).

Thanks.

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

418

clrmame Discussion / Re: Error in rebuilding some TOSEC dat with long path and zip compression

« on: 06 January 2021, 19:16 »

Thanks...I will have a look in the next days...

419

clrmame Discussion / Re: Error in rebuilding some TOSEC dat with long path and zip compression

« on: 05 January 2021, 18:34 »

Can you provide the files somehow?
Besides the roms, cmpro.ini, the used datfile and the belonging *.cmp file from cmpro‘s settings folder.

420

clrmame Discussion / Re: ..SL CHDs and right place problem

« on: 04 January 2021, 15:10 »

There is nothing wrong. The chd is detected as unneded and moved to backup when you tick yes/yes to all.
Your datfile has no parent/clone relationship between the 2 dbz sets (the official MAME .227 one does have a relationship), so the file in the wrong folder is unneeded. Of course cmpro can auto-move it to the correct place if you simply put it in a rompath root.