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.

361

clrmame Discussion / Re: Running from NAS

« on: 28 April 2021, 16:20 »

What did you expect? ;-)
Of course using a network drive is slow. It always been and always will be...compared to a local ssd.
A full scan on a decent system on a SSD is less than ~ 1minute.
Besides of the general time drop due to lots of file access tasks over the net, you might run into problems with SAMBA which were discussed several times on this board in the past. There were buggy drivers which caused all kind of issues...mainly simply dropping files and stop operations.

So what should you do?
If data import is already slow, you should check your setup (since this is just a redirect of MAME's -listxml output). You should keep cmpro close to the drive where your files are....and avoid SAMBA.

362

clrmame Discussion / Re: Create automatic or whit less effort possible xml dat from only dirs/size files

« on: 15 April 2021, 17:33 »

The built-in dat creator works on file basis, not http links. But of course there might be other datfile generators out there....
however, a datfile should contain a hash, i.e. you somehow need to read the full file to calculate sha1/crc32s

363

clrmame Discussion / Re: Create automatic or whit less effort possible xml dat from only dirs/size files

« on: 15 April 2021, 15:25 »

Hmm...I don't really understand your request fully....

Normally you use Profiler->dir2dat to create a datfile from a selected folder from your storage media....it runs through the folders, calculates the hashes, sizes etc and forms a datfile from it.

What is your source? I mean what exactly do you mean with "from only dirs/size files"?

364

clrmame Discussion / Re: Scanner does not check crc32?

« on: 08 April 2021, 13:02 »

No everything is fine and of course the crc32 is checked.
But such old MAME versions used bitwise inverted crc32 values to mark a bad dump in the datfile.
So your file is actually ok (but  a marked bad dump):

4fafa1e7 = BOOLEAN-NOT b0505e18

There's an option in the profiler options to enable the inverted crc32 mode, then the rebuilder also rebuilds it.


Yeah...there are some weird things in 20 year old MAME versions....that's one of the reason why people should stick with the current one

365

clrmame Discussion / Re: Unpack failed on file

« on: 07 April 2021, 16:19 »

That zip is packed with the deflate64 compression method which is not supported. You can unpack it with e.g. 7z/winrar and pack it again as a zip and it will work.

366

clrmame Discussion / Re: Folders "Magnavox Odyssey 2/Philips Videopac" vs. "Philips Videopac/Odyssey 2"?

« on: 02 April 2021, 07:22 »

There is only the following in MAME .230: videopac.xml <softwarelist name="videopac" description="Philips Videopac / Odyssey 2 cartridges">

Maybe MAMEDevs used a different file before with a different description and you only unpacked the latest MAME over your existing installation (no clean install).

367

clrmame Discussion / Re: Split vs Merge

« on: 25 March 2021, 18:02 »

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

368

clrmame Discussion / Re: Split vs Merge

« on: 24 March 2021, 17:47 »

I had a quick look, simple fix.
However, it should also affect the rebuilder batch (merge) options and (being picky) a possible forcepacking should also influence batcher's rebuild pack options....

Guess I find some minutes this week to add this

369

clrmame Discussion / Re: Split vs Merge

« on: 24 March 2021, 14:14 »

Well, I actually guess that a datfile forcemerging tag should be something with a higher prio in any case...
Such things are so rare and are put in the dat to really force the collection to be split/full/unmerged...so I think any batcher overwrite should still accept the forcemerging information from the dats.

Have to check if it's actually stored in the profile. Normally, the profiler reads the dat and sets the merge mode accordingly and doesn't allow changes...have to check if it also stores if the datfile actually has got a forcemerging tag..


I will check it.....

370

clrmame Discussion / Re: Split vs Merge

« on: 24 March 2021, 11:24 »

Well....The batcher options for scanner are either "per profile merge options" (so it doesn't change anything and keeps it from the profile) or you select an mode which overwrites the one from the profile

So yes, forcemerging tags are ignored since you do force an overwrite of the batcher scanner merge mode settings.

So...from this point of view it is expected

371

clrmame Discussion / Re: Continued from MAMEWorld...

« on: 19 March 2021, 06:08 »

That 32/64 bit thing is interesting.....actually in the 64bit version you got a version64.ini file with the needed url for update and for the 32bit version you got a version.ini with the same content (the split has some historical background).
Would be interestining to know which files you had before the update worked (which exe, which version file). (Backup?) Maybe a mixed setup is the cause of all trouble.

Autorefresh www dats...hmm..shouldn't play a role at all...but I will check it, too.

Thanks for testing!

372

clrmame Discussion / Re: Continued from MAMEWorld...

« on: 18 March 2021, 15:02 »

can you test the following if you got the update problem:
download https://mamedev.emulab.it/clrmamepro/binaries/cmpro_updatetest.7z and unpack one of the exe over yours.

Then run it, go to about and "check now". This version is hardcoded to "1.0", so it should detect the latest update and should start the update process (if you accept it). Then the download of the package starts and your versions (this test version) gets replaced.

So what is different? Well, I've moved the code which downloads the version information from update.dll to the cmpro main program and now it uses the same routines which e.g. the www profiler uses to download www datfiles.

The update process (the actual download of the package + unpack and restart) hasn't changed yet and is still handled by update.dll....however this test can give me an idea already if the general version lookup still fails for you or not.

373

clrmame Discussion / Re: Continued from MAMEWorld...

« on: 18 March 2021, 06:37 »

no prob, as I said...I really like to look at it again...because normally sending a GET request under Windows in C++ isn't magic....

374

clrmame Discussion / Re: A small bug and a feature request

« on: 17 March 2021, 18:23 »

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

375

clrmame Discussion / Re: A small bug and a feature request

« on: 17 March 2021, 12:32 »

try this https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210317.7z

376

clrmame Discussion / Re: Continued from MAMEWorld...

« on: 17 March 2021, 07:07 »

Sorry but your assumption is wrong.

The Homepage and Donate buttons simply run your standard browser with an url. (something like: ShellExecute(m_hWnd, _T("open"), donateUrl, NULL, NULL, SW_SHOWNORMAL); )


The update button calls routines in update.dll which
a) download the file from the url given in version64.ini
b) compares the version against the current one and if it's newer it downloads the package etc..etc
for a) it opens an HttpConnection, sends a GET request with a imo fine filled http request header, queries the length of the target file and downloads it.
for b) it opens the downloaded version file and compares it, then it would download the full package (pretty much the same as a) but a different file) etc..

So what people reported is that a) fails for them already because the GET request is simply dropped by the server.

You can check this by monitoring the cmpro folder if a "version" file appears (it gets removed after clicking the prompts)

But as mentioned, I've tried this on various systems, various networks and even in various countries...and it always worked for me...so really hard to say where exactly the problem is.
When I find a bit more time I will look at it again.

377

clrmame Discussion / Re: Profiler starngeness upgrading to 4.0.41

« on: 06 March 2021, 13:09 »

Well, actually the combined mode is crap. Period I got a couple of ideas on paper which actually match somehow your ideas a bit....but currently no real time to implement it.....but time will tell....Thanks for the feedback!

378

clrmame Discussion / Re: Profiler starngeness upgrading to 4.0.41

« on: 05 March 2021, 16:21 »

1) I can't repeat the "An error occured while reading information from: G\Mameui64\MAMEUI64.exe" at all. This error only appears when cmpro can't access the redirected -listxml or -listsoftware output file or the file itself holds xml bugs. As I said...I cannot repeat this behaviour at all...sorry.

2) Using the same executable for 2 profiles (-listxml and -listxml + -listsoftware) is not intended and will create problems. cmpro reads the xml files and stores the data in a cache file (based on the exe checksum). So you will have one and the same file for both, or if you created one with software lists and load your profile without you get in trouble. Cmpro checks if the exe changed (hash), if yes it shows you a prompt and will reimport data, if not, it loads the cached information.
Either you need 2 not binary-identical exes or use a dat for one and exe import for the other. Or you need to clean the cache all the time before loading a profile...The better way for software lists is anyway to keep them in separate profiles (simply drag'n drop MAME's hash folder in the profiler).

3) auto assign sysdefpaths. Let me tell you how it works. First you need to add rompaths. Rompaths can't have subfolders with other files. You cannot add the root of all your software lists. You need to have them separated. You can simply drop all your folders in the settings folder of course. So settings -> rompaths should show a list of paths....and not one. Then you go to systems and hit auto assign. The auto assign works as follows: Runs through all rompaths (not subpaths!), tries to match the setname against the databasis...each match increases a counter (per bios/softwarelist) and after scanning all rompaths cmpro checks which rompath scored best for bios/softwarelists XY (highest count). So for Atari2600 your 6 rompaths score 0, 1, 1, 10, 200, 7, the rompath with the 200 is assigned ...and so on.

4) nothing of the above actually has changed in years. Regarding the fix for the autodetection, that feature broke a version before so it was just a quick fix to get it up working again.

Setting up softwarelists paths in a combined profile is really a pain...yes...that's why I advice people to not use it (I actually already though of removing it). Using separate profiles is in my opinion the better way to go through it (especially with the batcher)


Regarding 2, I can think of a way that cmpro is able to support 2 different cache files though....one with and one without software lists


(actually I'm working on modifying the hash so that a) the name of the datfile/mame exe, b) the binary content and c) combined or single mode is reflected by it...so you would be able to have differnt cache files for identical mame binaries in combined/not combined mode and/or different caching files for byte-identical files in different positions)....)

379

clrmame Discussion / Re: Mame 0.229 merget set : Missing but fixable

« on: 02 March 2021, 17:47 »

nah...it's not.... ;-)

a set = collection of roms and/or chds and/or samples

doesn't really matter if a set consist of one rom (like a console cart dump) or 10 roms, samples and chds

380

clrmame Discussion / Re: Mame 0.229 merget set : Missing but fixable

« on: 02 March 2021, 15:38 »

Let me show you where your assumptions are wrong:
- You've downloaded a set from the internet and think that it's right.
- You've downloaded a set and think that playability has something to do with auditing sets.
- You've downloaded a set and think that it matches the default cmpro settings out of the box.

So your part would be:
Learn about parent/clone relationships, how datfiles describe sets, ensure you know what type of set you've downloaded (so e.g. not checking romsets for MAME version .216 with a datfile for MAME .213), adjust the needed settings and scan.


Now to your concrete example:

After looking at your example (vs10yard sets) you could for example double check the MAME listxml output to see what's wrong:

Let's take for example the file with checksum 7d1b4d93

it's used by: 10yard85, vs10yard, vs10yardj, vs10yardu (all clones of 10yard) and in 3/4 sets it uses a different name and you don't have any merge attribute specified:

      <rom name="yf-a-3d-h-vs.3d" size="8192" crc="7d1b4d93" sha1="9389de1230b93f529c492af6fb911c00280cae8a" region="gfx1" offset="4000"/>
      <rom name="yf-a-3d-h.3d" size="8192" crc="7d1b4d93" sha1="9389de1230b93f529c492af6fb911c00280cae8a" region="gfx1" offset="4000"/>
      <rom name="vyf-a.3d" size="8192" crc="7d1b4d93" sha1="9389de1230b93f529c492af6fb911c00280cae8a" region="gfx1" offset="4000"/>
      <rom name="vyf-a.3d" size="8192" crc="7d1b4d93" sha1="9389de1230b93f529c492af6fb911c00280cae8a" region="gfx1" offset="4000"/>


Conclusion: You need it 3 times to make a correct auditing (in a merged set, in a split merged setup, you'd need it 4 times). That's the way it is, you can ask MAME devs if they update their source code so that they use merge attributes, but it won't happen since the file isn't part of the parent.

Now why does MAME work? Because MAME doesn't care about names. MAME loads files by searching your rompaths for checksum matches. It doesn't care if you got a file correctly named. And if a file is used multiple times, it doesn't care if you only have it once with a wrong name.

Welcome to the world of auditing. In the auditing world, you need the file several times because the datfile tells you so.

What you can do: Well, cmpro tells you, turning on fix missing would simply fix it for you automatically. It's one click away...