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 ... 149
clrmame Discussion / Re: Diff Scans
« on: 21 September 2021, 06:53 »
hmm...works for me...

What I did:

added GOG.com Games, DLC & Extras (5364 + 7) (20210831) datfile in profiler (created a new default profile....) went to settings, added a rompath, went to scanner, hit scan...scan done...ok...all sets are listed (since I've scanned a dummy empty rompath)

added GOG.com Games, DLC & Extras (5416 + 7) (20210909) datfile in profiler, when loading, cmpro says it's an update for the other dat:

Found an updated DatFile
'Currently available GOG games and extras'
seems to be an update to:
'GOG.com Games, DLC & Extras (5364 + 7) (20210831)'
Do you want to update?

Selecting "Yes", loads the dat, Scanner shows Diff Scan and using it will only show the changed stuff

So...everything's fine here..

What you can try is:

- profiler context menu -> Garbage Collection
- profiler -> Clear cache
...and if nothing works, you may want to test if creating a new default profile helps

clrmame Discussion / Re: Diff Scans
« on: 20 September 2021, 19:45 »
The dat is ok.
Diff scans are only available if you have an old datfile and a new datfile which share the same name in their headers, so cmpro sees them as an updated version.
So to test something I actually need 2 dats...an older and a newer one.

If cmpro detects a dat as being an update, it will diff them and the diff scan will only work on the changed entries.

Maybe the functionality got broken (it's rarely used)....If I find a little time this week I'll check it with some custom dats...

If you got another dat (older or newer), just send them in...

clrmame Discussion / clrmamepro 4.042 released
« on: 14 September 2021, 07:40 »

misc: support romof handling in device sets
misc: systems auto assign can detect empty software list folders in case they are named accordingly
misc: software list import's default setting is off
misc: changed behaviour of context menu "move all incomplete sets" to "move all sets with problems" (similar for delete).
      This also covers wrong named etc ones, not only missing files.
misc: contextMenu options Delete/Move/Copy Current/all [not fixed]/all sets with problems use the parent set in full merged mode
misc: cleaning cache also cleans hashes folder
misc: batcher's scanner merge mode overwrite does not overwrite the information from a datfile's forcemerging option
misc: batcher's rebuilder pack overwrite does not overwrite the information from a datfile's forcepacking option
misc: don't stop multiple downloads on first failure
misc: wrote a wrapper class to handle all filefind calls which weren't 32k path length ready.
      This should fix all remaining long path (32k) issues.

fixed: invalid wrong-case messages on chds with very long filenames
fixed: wrongly list valid chds as unneeded when a no dump chd of the same name exists and 'mark no dump as unneeded' option is enabled

clrmame Discussion / Re: support for empty folders
« on: 11 September 2021, 14:56 »
Well, it's on "the list" for ages...but don't count on it anytime soon since there is currently nearly no development of new features (just some fixing here and there and in case MAME introduces something new (hint hint))

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

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

Page created in 0.08 seconds with 20 queries.