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 ... 147
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 :)

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.

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).

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

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.....

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 :)

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!

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.

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....

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.

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!

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)....)

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 ;)

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...

If cmpro says you're missing a file, then you're missing a file. If cmpro says that it is fixable, then you already got the file somewhere and it can be fixed. ;)
Sounds a bit like you didn't enable Profiler -> Options -> Parse ROM 'merge' tags, which would mean that you need some dupes. So double check if you've enabled the option and rescan.

If that option is enabled and you still get problems, you should give a detailed example.

well, it is basically fix missing. depending on the advanced option it looks a) in your addpaths, in the backup folder and your rompaths for the missing file. If the advanced option is not ticked, it only looks in sets named after the set where the missing file is and in sets named after parent and clones of that set. if the advanced option is enabled it looks in any file which is of course overkill.

now if a big group of newly added sets miss a lot of files (or using not separarted bios sets), fix missing looks pretty long (and over and over again) for the files.. although the scenario is pretty rare it does happen. progetto snaps dats are a typical example where fix missing should be turned off. it use some placeholder files for pngs and so you may have hundreds instances of the same missing file and each would be looked up individually with fix missing (while the rebuilder would create them all at once). now if you additionally use solid packed 7z archives you can go for summer holiday while fix missing is working....

so....usually you should a) keep the advanced option disabled, b) do a rebuild first to add all new stuff and the finally scan with fix options on to get rid of the rest of te problems....

clrmame Discussion / clrmamepro 4.041 released
« on: 28 February 2021, 18:30 »

added: Select Sets variables %R %G to filter by for Region / Language
added: Batcher, rebuilder setting to avoid message prompts
misc: support dat date attribute format YYYY-MM-DD without specifying timestamp
misc: rar/7z/uncompressed files timestamps are handled as UTC based, zip as non UTC based
fixed: some unpack/pack zip operation fail on very long file/path names
fixed: interative folder creation for UNC paths is broken
fixed: systems auto assign fails for software lists
fixed: fail to load dats from www when www profiler definition file doesn't use http/https in the links

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

Page created in 0.161 seconds with 20 queries.