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 ... 148
Auto assign is a pretty easy best-count-wins and it works as follows:
For assigning standard/mechanical/decives/bios and software lists folders it runs through all active rompaths (not subpaths).
Then it counts +1 for per found file/folder for the belonging type. The type which gets the highest value gets this rompath assigned, otherwise the 1st rompath is used.
So you see, you need correctly named files in the paths to actually be able to assign a path, otherwise you all end up with the first rompath.
E.g. you have a rompath e:\roms\a2600 and got 99 valid atari 2600 sets in there and 50 sets of let's say C64, then that rompath gets a count of 99 for Atari 2600 (and most likely much less than the Atari 2600 count for other rompaths) and so the Atari 2600 software list gets assigned to that rompath.

The auto assign might be improved by also checking the rompath name, so e.g. an empty nes folder can be assigned to the nes software lists. That might get in in the near future....but generally the combined mode is pretty dead.

So....the combined mode is a pain to setup since auto assign would only work if you already have sets in all of your paths. And all paths have to be 1) rompaths and b) distinct (besides the 'normal' MAME ones BIOS/STANDARD/MECHANICAL/DEVICES)). Works pretty well if your collection is near perfect, but otherwise you most likely need to assign some or more paths manually.
You can't have "M:/Mame/software" as a rompath. Software lists need to be in distinct paths (which I assume are the subpaths of M:/Mame/software), so you need to add those as rompaths and not their parent paths. You can simply use drag'n drop in the settings folder to add them.

Overall, it's way more easy to use one-profile-per-software lists and run through the data separately. Why?
a) you got the batcher to scan only changed software lists
b) the batcher also allows you to auto-create and assign rompaths for you (no need to setup some hundred paths)
c) the scan results output is way more readable
d) some software lists are not exported by mame via -listsoftware while the hash files have them
e) no problems with identical sets (there are identical sets in MAME which repeat themselves in some software lists)
f) faster lookups

(batcher = select more than one profile in the profiler and hit load, then the batcher with all its options appear)

clrmame Discussion / Re: Cmpro dont like chd !
« on: 31 July 2021, 18:59 »
First quick check after coming back from holiday shows that it is related to the nodump.....guess it's easy to fix....as soon as I find a bit time ...probably within the next 2 days.

If I‘m not mistaken the used zip archive library also auto kills the dot even if a filename in the zipstructure can have a dot at the end. As soon as you try to work with unpacked data you will run into issues since the filename wont match anymore and in cmpro the loaded dat defines the name and it doesnt differ between packed or unpacked files.
There are simply a number of illegal chars which cant be used and will always create issues (:/\|<> etc).
Since it is fixed in the mame source I doubt something will be changed in cmpro and mame loads files by hash and not by name anyway.

You cant have a file in windows which ends with a dot if I remember correctly. Keep in mind you can have your sets unpacked. I will look at it though.

clrmame Discussion / Re: Cmpro dont like chd !
« on: 26 July 2021, 16:33 »
Please be patient till next weekend or so. I wont be able to look at it till then.

It's not that bad actually...I only have to use some other function call. I've fixed that one in question, so get the latest nightly version.

However, there are some other places where the function is used, so I have to double check/exchange them, too....but not today ;)

Thanks....I found the problematic Windows library call.....and I need some time to get a workaround in place since that Windows function is simply not working with long paths which are longer than the common MAX_PATH ones....it doesn't have native 32k path support as the others.....*sigh*
I will look into it

I doubt it's a case problem since the "wrong" part is not even filled. Sounds more like a different issue which accidently runs into the case check.

Can you please send me:

a) the used datfile
b) your cmpro.ini
c) the *.cmp file belonging to your datfile (in cmpro's settings folder)

and if possible one of the files in question and let me know how it is stored on your PC.

Thanks for testing and digging. Interesting thing though....Looks like Windows System libs are crashing here...might be worth to check it a bit more deeply when I find some time and report it to MS :)

Creating a profile takes a second if you got a datfile. If you directly import data from e.g. a MAME binary it takes maybe half a minute since MAME's output generation (a redirected -listxml call) writes pretty much data on your disk first. 22 Minutes sounds very wrong. Don't know what you did or what your video tolds you but the correct way would be:

- drop a datfile into the profiler (or use the add datfile button), after reading it (probably a second) it will appear in the profiler tree, double click it to load it.
- if you want to take the data from a mame binary, select "create", choose your mame binary, set a name. After leaving the dialog it will appear in the profiler. Double click to load it...then it will import the data from the MAME binary.

The link to the english tutorial is dead since the easyemu page was redesigned and the clrmamepro pages weren't put up back yet. I try to reach the author.

Amiga Emulation, I personally use WinUAE and it runs fine on a Win10 64 bit system.

Regarding tosec dats, sure they will work. The problem there is only if you want to clone their datfile folder structure. In the past it was pretty easy with cmpro's batcher to regenerate the strucuture but I think they changed their naming/structure, so it might be a bit more hand work to create the same dat structures. If you only want to load a datfile from there pack, no problem.

As I've mentioned in the PM, it works fine here. Cloned your environment and the example file pops up for fixing and clicking yes works flawlessly.

You've mentioned that you took the hd from an older system so I though it might be related to user access rights somehow. You've said something about "it was utf8 then ntfs". Can you go a bit into details here please? Because utf8 isn't a filesystem format like ntfs. Any information about the hd (which format), possible user access rights etc could be helpful.
Also you may want to turn off virusscanners and other 3rd party tools for a quick test only. Maybe copying some of the 'crashing files' on a different harddisk gives some positive or negative feedback...
I've played a bit with access rights on files (e.g. not allowing write operations etc) but even then it doesn't crash and simply shows messages like Can't remove files from: E:\Emulation\Roms\Mame\48in1.zip etc...

So...everything's fine here :( ...and noone else reported such a thing yet (and removing files it one of the most common things)...so I somehow have your taken-over-hd in mind...but currently no idea what's causing a crash.

If you google the error message you will find things like:

so..that's an example where Microsoft UE-V (User Experience Virtualization) causes crashes even in its own explorer...so that's why I'm asking for possible 3rd party tools interfearing..
So...any synching tool running on your PC?

thanks, I will have a look

Well, you should look at the definitions for such sets (taken from offical MAME) and you will see that:

pongd, rebound and  breakout - no roms at all, only device_ref
wotwc - a "fake" clone, which fully consists of parent roms
chaoshea, carnking and the rest - only chd(s), only bios rom references, maybe a no dump and the rest are the roms from the parent

So to sum it up: You don't miss such sets and clrmamepro correctly reports the sets as not missing. They are all sets which either not physically exist, are 100% identical to their parent or actually only have a chd.

Don't mix playability and audit results. Such things are 2 different things.
MAME for example looks up all kind of places for files, not even by name but by hash. If it finds it somewhere, the game loads. The fact that a game "works" has nothing to do with audit results.

If you run a clone which misses files but the parent set got the files included for whatever reason, the scan will report them as missing (or as misplaced) while the emulator will simply load all files.
Similar for taking merge tags into account or not. There are sets which e.g. use 2 binary identical files (even within the same set, and pretty often in parent/clone relationships) with different filenames. MAME's database handles such things with "merge" attributes in its dataoutput and in your audit tool you can define if you want to use this information or not. In other words: in one setting you'd need both files, in the other only one. Again for playing you'd need only one because the emu loader doesn't care. It looks up the files by hash.

Another thing (since you mentioned hyperspin), beware that your emulator and your auditing data has to match. Don't scan a MAME .208 collection with a ARCADE (or whatever) .208 database and so on.

To sum it up: If cmpro tells you that you're missing files, you're missing files in terms of a clean audit
You gave too little information which files were listed as missing and which files you actually have in your rompaths.

OS and versions all sound good.

Removing files definetly doesn't crash here (and noone else reported it and believe me...such a problem would have popped up very very early :)).
If you are able to reproduce the error (and it seems you are), please send me the zip file in question somehow.

Besides of looking at the archive, you may want to toggle making backups (Settings -> Make backups to folder). Maybe it tries to add the file it wants to delete to a corrupt archive in backup....

A crash when fixing files was not reported yet.

Hard to say what is happening. The most likely scenario is a corrupt archive file so that a 3rd party lib (zip / 7z / rar) has a problem when modifying the corrupt archive.
So the best thing to do is to enable "Ask before fixing" option and don't use the "yes to all" / "no to all" prompts but single click through the messages. By doing that you might be able to find out which set is creating the problem.
Or try to limit the amout of data which you want to scan. For example try less rompaths with less files....so a bit trial and error to find out where exactly the problem is.

Also of interest is your setup: 32/64 bit version of cmpro, latest version?, windows version?. Special settings set in cmpro? (e.g. you can send me your used *.cmp file from cmpro's settings folder and cmpro.ini).

More unlikely is bad RAM (or wrong RAM timing) which can cause all kind of weird effects....but as I said...pretty unlikely.

If you got sets in your softwarelist folders, the autodetection will work fine. Most likely you didn't add the folders as rompath.

"I have a ROMs, a CHDs, a Software List ROMs and a Software List CHDs folder inside my MAME folder."
Well...no, that's not the way it supposed to be and I guess or hope such folders have subfolders which split the lists.
Each software list needs its own folder which has to be added as a rompath.
So your rompaths should look something like e:\mame\SL\3do_m2; e:\mame\SL\32x.xml; e:\mame\SL\a800...and so on. You can simply drag'n drop all folders in the settings window to add them.
For software lists they have to be unique per list. For the rest (MAME, Devices, BIOS, Mechanical) they can be identical.

Splitting CHDs in their own folder is also not recommended (though possible)

You should know about the general way of storing files for MAME (and actually any datfile you're loading in cmpro):

rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.7z/.rar) for compressed sets

A set is a collection of roms and/or samples and/or chds. Since chds are compressed already (CHD is nothing but a container) they are usually kept decompressed, so you got a subfolder for the set in question with the chd placed in there. The roms/samples are usually kept compressed.

What you clicked is an english tutorial which was created and hosted by a different author, unfortunately it's not availabe at the moment, I'm gonna ask the author if he can send me a copy. The other tutorials should work though and there's a link to the 3.x version of the docs....pretty old but to get a basic understanding it'll be ok I guess.

Now to auditing....If you want to audit software lists you have the choice between two modes:

- the combined mode (you're asked after a MAME import) which is a beast to setup and a bit hard to handle
- the split mode. Simply keep 1 profile per software list (e.g. drag'n drop the files from MAME's hash folder into the profiler). The batcher allows scanning multiple dats and a bit of automatic rompath setup.

Now you've chosen the tough way... :) .....well..for this, you need to specify unique system default paths for each software list. The BIOS/Standard/Devices/Mechanical ones can be identical, the SL ones NOT.

Autoassign works only if you actually already have sets in the single rompath folders. It checks and counts the found files and tries to match the best count per folder to a software list. If no match is found it will always take the 1st rompath. So for example you have an empty Atari2600 folder, a C64 one, an empty Amiga one, and got 3 Amiga sets in the C64 folder, it will fail. It will count 3 for the Amiga Software lists and so the C64 folder will be assigned, the rest don't have any counts, cmpro will assign them to the 1st rompath...
You see, auto assign only really works if your collection is a bit presorted.

To sum it up, usually it's easier to keep 1 profiler per software list. If you select more than one profile in the profiler, you can load them in a batch run (with additional options)

clrmame Discussion / Re: CLRMAME Pro Question
« on: 04 June 2021, 08:21 »
Well....I need a bit more information about your used settings.
First of all it would be intersting to know what databasis you're using.
For MAME it would be best to directly import the data from the (latest) MAME binary. (Profiler->Create...). Maybe you used a datfile with no chds listed (just a though).
Secondly, for chds you need to enable Scanner -> "You want to scan" "CHDs" (plus the rest of course).
So if your databasis got chds included and you go that option enabled, you definitely get information about missing chds (there's one additional filter possibility for chds though, Scanner->Hash & CHD -> Available regions, but they should all be enabled by default anyway)

Since years, there is no MESS anymore. MAME integrated all MESS sets/core, so yes, they can be audit by running a simple current MAME scan.

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

Page created in 0.536 seconds with 21 queries.