EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

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 ... 21 22 23 24 25 [26] 27 28 29 30 31 ... 172
501
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 :)

502
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!

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

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

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

508
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!

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

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

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




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

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

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

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

515
Turn off the fix missing option and try again

...and you're sure you use not separated bios sets??? That should actually be enabled....and I see you're not using a direct MAME import but an external dat....shouldn't be a problem but...it's not official :)

if you now accidently turned off "separate bios sets", you're running into a lot of fix missing operations now...since you tell each and any set to have all bios files not separated (so you keep thousands of copies of the same files now).

516
Unless you have some network issues (https://www.emulab.it/forum/index.php?topic=4902.msg18940#msg18940) it's really based on an enabled advanced scanner option to do a deeper fix missing check. Or a virusscanner goes wild.
You may want to do some monitoring with Windows Taskmanager to see which task is taking cpu power or check the network traffic.

517
Turn off Scanner->Advanced->Deeper Check For Fixable Missing Files. (Normally this is disabled by default and why? because it is a real time killer)

Just to give you a number. On on a current PC with a local SSD a full MAME scan (no fixes) takes roughly 46 seconds.

518
The currently loaded profile name is in the window title of the rebuilder (scanner, merger). Not in the progress window but in the main window though.

...if this is not enough it shouldn't be too hard to also add it to the progress window I guess....

519
erm...the name of the current set? The rebuilder progress bar shows which file is currently scanned and in case of a match it shows the name of the set and file where it was added to.

Do you mean the profile name??? In case of a non batch run you should know what you're currently working on :)

Pages: 1 ... 21 22 23 24 25 [26] 27 28 29 30 31 ... 172

Page created in 0.142 seconds with 22 queries.