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.

1

clrmame Discussion / Re: Latest Nightly Build

« on: 12 June 2019, 09:42 »

I may think about a quick way to detect changes on startup (e.g. looking and comparing at the last write date of the datfiles folder ) and doing a refresh then......but currently I have zero time for cmpro coding

2

clrmame Discussion / Re: Latest Nightly Build

« on: 12 June 2019, 09:35 »

Yes of course something changed.
People with 1000000000 datfiles were pretty annoyed that during startup it took ages to run through all datfiles. Even if no new ones were added.
Cmpro now caches the data and reloads the cache only (plus auto refresh when new datfiles were added correclty and not manually).

If you use the official way to add datfiles (drag'n drop, add button, www profiler), it acts like before.

3

clrmame Discussion / Re: Latest Nightly Build

« on: 12 June 2019, 09:18 »

As I said, you need to add datfiles via drag'n drop (in the profiler window) or www profier or the add button.
If you do what you do (copying them manually while cmpro is closed), you need to click the refresh button

4

clrmame Discussion / Re: Latest Nightly Build

« on: 12 June 2019, 09:07 »

hmm....weird...works fine for me....how do you add new datfiles? (if you only put them manually in the datfiles folder you have to press "refresh". If you add them via drag'n drop or the add button it should work fine

5

clrmame Discussion / Re: cmpro no longer viable for me

« on: 09 June 2019, 17:28 »

false positives are nothing unusual but daily business.....there were even cases where Microsoft's own scanner marked Windows exe files and nothing worked anymore (at least till the next definitions update).......so to sum it up: virusscanners are a pain....

6

clrmame Discussion / Re: cmpro no longer viable for me

« on: 09 June 2019, 10:16 »

Regarding the "malware" topic. It's simply a false positive report of your virusscanner. Such things are pretty common and usually resolve automatically with the next update of the virusdefinitions. So nothing to worry about. For example Windows Defender took ages on my system when it tries to scan the official packed mame binaries/sources at the time when it came out last week. One day later all was fine.

Regarding the receive data topic:
cmpro runs the mame binary with -listxml parameter and redirects the output. After about 20 seconds (depending a bit on your system speed) you should see the actual sets being imported (dialog shows changing text output). If not, the MAME binary got a problem to create the listxml output file.

This can also be related to your virusscanner which may also have problems when it accesses the mame binary and blocks it.

So...either turn off your scanner for the MAME binary and cmpro binary or wait till your paid malwarebytes gets an update.

7

clrmame Discussion / Re: Struggling to complete romset Samples - help needed please....

« on: 08 June 2019, 13:23 »

don't care too much about the stats count..... an empty scan results tree window is the thing you're looking for ;-)

8

clrmame Discussion / Re: Struggling to complete romset Samples - help needed please....

« on: 07 June 2019, 14:05 »

game name="berzerk1" cloneof="berzerk" romof="berzerk" sampleof="berzerk"

it simply means that the set "berzerk1" uses the samples of the set "berzerk". So you need the sample set "berzerk".

(For easyness, I reference zip archives only)
So in a split-merged set world you got:

rompath\berzerk.zip (the parent rom set)
rompath\berzerk1.zip (the clone rom set)
samplepath\berzerk.zip (the sample set)

in a full-merged set world you got:

rompath\berzerk.zip (the parent rom set plus the files from berzerk1)
samplepath\berzerk.zip (the sample set)


The berzerk.zip romset holds the rom files (1c-0, 1d-1, ...) while the sample set berzerk.zip holds 01.wav etc.

9

clrmame Discussion / Re: Struggling to complete romset Samples - help needed please....

« on: 07 June 2019, 11:51 »

All samples for current MAME can be found here: http://www.progettosnaps.net/samples/

The problem is that you're not using the latest version of MAME.
A version for a Raspberry Pi is most likely based on an ancient MAME build. Back then, Samples were needed for Berzerk. In our times they are obsolete since the sound/voice chips have been emulated (I guess this was done in 2007...so also 12 years ago)...

...so.....you need to search the internet for such ancient stuff.....

10

clrmame Discussion / Re: Skipped files while rebuilding and zip compression

« on: 02 June 2019, 20:17 »

fixed the miss-list generation for these sample-only-sets....for the next nightly build....

11

clrmame Discussion / Re: Skipped files while rebuilding and zip compression

« on: 01 June 2019, 18:16 »

ignore stats and miss/have lists.....the only important thing is an empty scan tree output

The listed sets are sample-only sets. I should fix the miss-list routine for them....

12

clrmame Discussion / Re: Skipped files while rebuilding and zip compression

« on: 01 June 2019, 15:41 »

The link does not work for me....so I don't know what they are writing.......What do they write? Merging differences? Source code merge or set merge? Without any details I can't comment.....
Generally, clrmamepro should be able to handle all merging problems (e.g. equally named files within a parent/clone relationship but with differnt byte data/different checksums).....
There shouldn't be a problem in using a direct MAME import.

13

clrmame Discussion / Re: Skipped files while rebuilding and zip compression

« on: 31 May 2019, 20:32 »

1) There is no setting to change the compression level anymore (acutally for decades). clrmamepro uses 9 by default.
2) As soon as a source file does not match a hash it is counted as skipped and if it was rebuilt already. So for example if you got a file which is shared by 30 different sets (Without parent/clone relationship) it is rebuilt by the first match already 30 times ( so 'created' is increased by 30) and every time it is found again in the source it's counted as skipped. There are shared files even without parent/clone relationsships....e.g. devices or bios sets.

14

clrmame Discussion / mame .210 / software lists

« on: 31 May 2019, 09:14 »

Just a reminder that for correct size recognition in some software list files (megadrv/quacksht to name one), you need the latest cmpro nightly build (if you already loaded the new software list files, you need to clear the cache after replacing the exe).

15

clrmame Discussion / Re: "The following not empty rompath don't contain any valid set"

« on: 27 May 2019, 17:07 »

"I know the rompath is right"
....well....I would say...no, it's not ;-) So, please give details how your files are arranged. As mentioned in a previous post, checking snapshot dats is easy since it follows the general standards, however, the rompath/folder structures may look a bit weird.

The titles datfile (not including software lists) got 1 set named "titles", so you got somewhere a folder named "tiltes" and this folder contains the single *.png files. Or you got a 7z/rar/zip archive named "titles.7z" (.rar/.zip) which holds the single png files.
Now the rompath you need to setup is the PARENT folder which holds either the titles folder or the archive file.
This follows the general rules:
rompath\setname\filename 1... filename n (for decompressed sets)
rompath\setname.zip (.rar/.7z) (for compressed sets where the archive holds the single files)

So double check your setup.
If you're still sure the strucute is correctly setup, you might use a wrong datfile for right files or vice versa.

"The ROMS being referred to are standard Winzip documents" ....sounds weird, since for titles you only need 1 archive, not multiple (as long as you don't include snapshots for softwarelists).

Generally speaking, you need to describe your setup a bit more.....one time you talk about tiles, one time about roms and your free text error message does not make sense either.

16

clrmame Discussion / Re: Dates older than 1980 = Invalid?

« on: 22 April 2019, 20:06 »

update:

there is a check during datfile parsing which checks given dates against MS-DOS (1980+) date format...so such dates won't be accepted, no matter if NTFS will be able to handle it (you'd run into trouble with zipfiles anyway....).

I will do some additional tests for pure ntfs/7z/rar later and may remove the initial check.

update 2:
removing the initial check is not enough since there seem to be some file attribute routines which won't accept files < 1980 either and will convert your 1970 file to something in 2008 ;-) ....so....as mentioned I will do some further investigation but don't count for it in April

17

clrmame Discussion / Re: Dates older than 1980 = Invalid?

« on: 22 April 2019, 06:48 »

MS DOS:
The MS-DOS date format can represent only dates between 1/1/1980 and 12/31/2107.

NTFS:
A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).

Statndard ZipFiles use Date in MS-DOS format

So in theory, using uncompressed files should work and zip files shouldn't. However due to holiday I haven't checked this yet and I don't know the day formats in rar/7z...have to check that later.

18

clrmame Discussion / Re: statistics wrong

« on: 08 April 2019, 18:35 »

ok....in case of exisiting separated bios files, the missing rom count will be adjusted....in the next nightly build

19

clrmame Discussion / Re: statistics wrong

« on: 05 April 2019, 17:28 »

The count is not wrong...it's just how the stats counts work. The rom count does not care about bios/merge but works on the plain defintions. If you miss a set, every file in its definition is counted as missing (as well as each file is counted for the total). There is a slight exception if no dump chds or no dump roms are included. But such files do not exist at all, while the chd belonging to the set is 'real'.

loveber3cn is a set which consists of a chd (mda-c0071) and bios rom (mb_eeprom_exp.ic54s).
Since you don't have the chd, you don't have the set and so the bios rom is counted as missing (and the set is counted as missing, too).

You don't see a message about a missing chd, since the scan tree output hides it when you disabled chds.
You don't see a message about a missing bios rom, since the scan tree output will only list it inside the bios sets themselved.
You migh not see a missing set message if you're using merged sets since then the existance of the parent + biosrom is enough...

You see....Statistic total/missing counts are based on set definitions, not parent/clone/bios relationsships....forget about the numbers...they don't bring you anything....Look at the scan tree output...if it's empty, you're good...but only related to your chosen check options.


Update: However, I will have a 2nd look at it since if biossets are separated and are available it should be counted as available.....but anyway...don't care too much about these numbers...

20

clrmame Discussion / Re: MAME 208 and latest nightly, miss all orionpro_flop sets

« on: 05 April 2019, 17:17 »

hmm.....I can't repeat this problem here.

Please double check your setup paths. Ensure that your rompath for orionpro_flop sets really contains the sets (e.g. bascom.7z) and it's correctly assigned to the sysdefault path belonging to the software list orionpro_flop (and not e.g. orion_flop).

I checked with a MAME + single software list import of orionpro_flop but no other lists....do you include more (if not all)?

However, if it does not see a single one of orionpro_flop sets it seems to be more a setup path problem rather than a problem in cmpro....