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

Check if you somehow excluded sets:

set information -> select all
systems -> all
Hash & CHD -> Available Regions -> all enabled

Well...you need to give some more information... like
- do you use the combined software list mode or a standalone pc98_cd datfile (prefered)
- how is the file stored on your hd (full path)
- how does your rompath / system default folders look like

You can of course use chdman to check if your file is really correct by comparing the hashes (that would be the first thing to check).

The easiest would be to ask the authors if they can produce a better output :) Something in XML which either is directly something compatible to common datfiles or XML which can be easily transformed via xslt into something useful.

Well...of course it's possible to write a converter for such files....but of course you need some additional information like a set name and optionally crc32, size information. Cmpro does not convert such files and won't do this in the future.

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.

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

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"?

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

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

Page created in 0.1 seconds with 21 queries.