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 ... 132
well...hard to say...the external 7z compression task failed. Does the 7z file already exist? Do you rebuild it to a place where the 7z is already present? Or does the rebuilder try to add it to a new archive?
What are your 7z settings?
If there's a chance can you provide me the datfile and an example file?

Standard zip does not support solid archives...and I guess torrentzip follows that rule.

Yes if you like you can open a question in Italian.....

Actually I think you think too much ;-)
You use split sets, fine, that's the default. If you already played around with too much settings, use a new profile.

Keep all default settings and do a new full scan. The scan results tree window will show what's wrong with your sets.
Completely missing sets are lsited with a folder icon with a red cross over it.
Incomplete sets are listed with a red cross only.

Now what can happen?

- your tree output is empty. Fine, you're ok (for the currently used settings)
- your tree contains only some fully missing and some partly missing sets. If they are fixable, turn on the fix options and rescan. If they are not fixable (cmpro can't magically create files out of nothing), find the files and add them (e.g. via the rebuilder)
- your tree shows 12839128391283 entries and you feel lost, well, then it depends what you want to achieve. You want to get them all? Have fun to hunt them down and add them. You only want to concentrate on some sets, then you might want to select just these sets. This can be done via set information.

You might want to seek help here: http://www.arcademania.eu/ or here https://digilander.libero.it/venturi1975/cmpro.html or here http://greenant.altervista.org/Guide/clrmamepro.htm

Regarding your questions:

Q: "as you say if some check fails in a zip files (bad names, missing files, wrong crc or similar) it's be marked as "Bad" or "Incomplete" f check don't found a zip files it's be showed in result as red cross it's exact right now ?"
A: See above: Completely missing have a folder/red cross icon, incomplete only have a red cross

Q: Only in this mode i thinks i can really check all my zip files and found if i have some parents zip whitout the original or other similar issue... right ?
A: See above: Use the default settings, do not use setinformation, do not use hide completely msising sets.

Q: I have tryed to start a "New Scan". After reach 100% i have try to export the list of "Incomplete" Sets and nothing happens (I believe because in my set there are no roms with missing files) ?
A: Export works fine. Export incomplete sets will work if you actually have incomplete sets listed (the red cross ones). Either export to clipboard or file. Similiar applies for completely missing ones

Q: I take a look at this "Scan Result". I think the list now shows me all the parent roms that I don't have at all.... it's about 1000 titles
A: Scan Resuls show ALL issues

If you scan you can encounter 2 cases:

1) you got parts of a set (a set is a collection of roms/chds/samples, e.g. "pacman") where some files of the set are 'bad' (wrongly named, missing, bad checksum)


2) you don't have any file of the set (pacman is completely missing)

The hide completely missing set option would hide 2) but will show 1).

So in this case you would see only sets which are partly incorrect.

This has nothing to do with playability. If you keep your sets split-merged you have parent sets and clone sets where the clones don't include the needed files from the parent. So if you got a clone you do need the parent, too (sometimes plus device sets plus bios sets). So if your scan result show no problems but you got the hide-fully-missing sets options enabled, you might still miss a parent....and you won't be able to run the game.

Again, there is no real reason to enable the hide-completly-missing sets option.
If you only have 10 sets out of 10000, then yes, you will get 9990 entries saying that you miss a set.
If you want to limit your scan to the sets you have, you go to set information, enable "the four incl. clones,parents,devices,bios" options and hit "avail sets".

"Hide Fully-Missing set" hides -guess what- only fully missing sets. If you miss only one out of 10 roms of a set it's not fully missing and will be displayed.
The option is dangerous since even if you get a clean/empty result tree it means that you might miss sets....if you only have 1% of all sets you get a clean result while in reality you miss 99%. Each set, no matter if parent or clone, is listed separately. Clones will only list their clone files, not the parent ones since they are shared.

So if you got a clone set and it does not appear in the list since you got "all" its roms it only means that the clone is ok. To play the game you do need the parent...which might be completely missing.

To sum it up: There is not really a reason to turn on the "hide fully missing sets". Keep it disabled and scan. If you only collect a small set out of the big MAME collection, it's better to enable/disable sets in the set information dialog, there you can always automatically enable belonging parents/devices/bios sets, too.

sounds weird....since cmpro of course only calls windows system library calls to rename files (we're talking about plain files/folders right? not files inside archives!?), so crashing/exisitng to desktop sounds like an internal library call caused an exception/assertion...

at the moment I can only say that it's not related to exFat in general since it works fine on devices formatted that way.
Soo....hard to say what the real problem is...could be a bad USB driver (in the combination with that drive), could be a bad drive (maybe there is a firmware update in the meantime). I guess Samsung has some software coming with the drive which might give a clue.....My laptop at work once had some really weird usb problems till I got updated drivers...

what happens if you (if you can do this without too much effort) format the drive to NTFS and then again to exFat

or what's the cluster size of the exFat formatted drive....so I can try to get a configuration as near as possible to yours


coming from visual pinball....then of course everything in c:\mame\roms which is not shared becomes unneeded, since it simply does not belong to vp....
and vice versa everything unique to vp will become unneeded for mame...

so currently I only see a chance in somehow build a custom datfile......

I wonder what happens when you setup a profile coming from vp and simply adding the mame rompath and keeping unneeded check disabled...but still fixing might become a problem since cmpro can't really decide where to add/fix sets (usually it does it in-place but when it comes to new archives it takes the first rompath).

when does it happen exactly (during/at the start/end) of the screen...what does the task manager say. did you try it multiple times? how much ram do you have? does it still happen if you remove the software lists you have added?

never seen this before and by the way, that message comes from the system, it is not someting clrmamepro creates on itself.

hi, any update on this? In the meantime I've tried some other PCs and media and I still can't reproduce this.

No problems here. I've formatted an USB 3.0 stick with exFat on an up2date Windows 10 System and did some tests with it (using the current nightly build of cmpro).
Fix operations, include renames work fine. The case fix is by the way nothing but a rename to a temporary name and a 2nd rename to the right case one.

So maybe you should send me your file in question to do more tests...or try with an USB stick yourself.

Actually it's not necessarily a problem with torrent7z when a set is not fixable. When talking about 7z in general you might refer to solid packed archives which simply require additional commandline parameters to work correctly.
When cmpro tries to add/rename/delete a file in a 7z file  it uses the commandline parameters which you can see in the settings->compressor->7z dialog. They are set to a default value for non solid archives. If the archive you're working on is a solid compressed one, the operations will most likely fail. So such options need to be adjusted.

Even if solid archives give you a bit more overall compression ratio, don't  forget that operations on them take longer (simply due to the fact that the whole archive needs to be repacked over and over again).

Yes, rebuilding to uncompressed sets is most likely the easiest method.
Sure there are script kiddies out there who might code a commandline script in a second...but hey....looks good to me what you did.
And yes, I'm aware that the extra folder seems to be silly....but cmpro originally comes from MAME where one set usually contains more than one rom/iso ;-)
To avoid such a folder overdose, you can use a different datfile with only one set definition (.....or I finally add an option which does this internally)

Not fully correct. Sure, it's a zip which is read correctly by cmpro. Torrentzip was created to actually have consisten file hashes, otherwise you wouldn't be able to share them via a torrent network, i.e. the files need to be stored in one given order, one given compression ratio (if any at all), normalized file attributes and timestamps. All such things affect bytes in the zipfile and so the overall checksum.
Any fix/add/rebuild cmpro operation will change things like these. So if you use torrentzip in your setup, the program will most likely follow the rules and recreates the full archive over and over again for each change....which will end in a slow down.
....so one batch run afterwards is most likely better/faster.

On the other hand...torrentzip/7z/whatever only makes sense if you share the sets over the network...and then we talk about copyrights....

Settings -> Compressor -> 7z

You may want to add your custom commandline parameters there, however in most cases it's faster to simply let cmpro does its work and manually run a whatever batch postprocessing afterwards.

"So in my case I have a Roms Folder.  In that folder I have a folder named "Nintendo - Wii".  And in that folder I have individual .iso files for each game I have. " Sorry, but that's not what I've told you.
So the basics: A set is a collection of roms/chds/samples. Pacman for example in MAME consists of 10 roms (IC dumps of the program roms, the graphic roms, the proms etc).
When you talk about a Nintendo - Wii collection, each set most likley consist of 1 rom file..where rom is a wrong word here, it's an ISO file. So your Nintendo - Wii datfile most likely contains some hundred sets where each set contains of 1 file.

Now back to the general storing method:

rompath\setname\file 1 ... file n for decompressed sets
rompath\setname.zip (.rar/.7z) (where the archive holds files belonging to the set) for compressed sets

Assuming your got "e:\test\Nintendo - Wii" as a rootfolder for your collection, then *this* is your rompath.
Your sets are either compressed, then you can put them zipped/rared/7zed in there, e.g. "e:\test\Nintendo - Wii\exampleGame.zip" (where exampleGame is the setname and the archive holds an iso file, e.g. named test.iso)....or your sets are not compressed, then you need to store it: "e:\test\Nintendo - Wii\exampleGame\test.iso"

So, look in your datfile and check how sets are organized. If you got 1000 sets with each set containing just one iso file, then you end up with 1 rompath holding 1000 subfolders where each one holds 1 iso file...
If your datfile holds just 1 set with 1000 iso files, then you end up with 1 rompath holding 1 folder holding 1000 iso files.

clrmame Discussion / Re: about scanner moving CHD...
« on: 27 October 2019, 16:37 »
Scanner's fix unneeded scan moves unknown chds from a rompath root to its correct place. It will create the needed subfolder for it and moves it there, using the correct name.
So yeah, put it on a rompath root and let the scanner do the work

No, roms don't have to be zipped. You only need to follow the official storing method:

rompath\setname\file 1 ... file n for decompressed sets
rompath\setname.zip (.rar/.7z) (where the archive holds files belonging to the set) for compressed sets

The setname is defined in the datfile, the rompath is up to you.

So usually you need one romfolder but for each set a single subfolder named after the set...and in that folder the rom(s) for the set is stored
.....or you modify the datfile and put all sets into one....

clrmame Discussion / Re: Latest Nightly Build
« on: 24 October 2019, 17:16 »
most likely your rebuilder setting "Compress Files" is not checked...and so you create subfolders/unpacked sets while you originally kept your sets compressed.

clrmame Discussion / Re: Latest Nightly Build
« on: 22 October 2019, 07:10 »
The nightly build shows the same version number as the official one. The nightly build is: http://mamedev.emulab.it/clrmamepro/binaries/cmpro20191006.rar

(you need to manually unpack it and replace your exe/dll files).

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

Page created in 0.114 seconds with 20 queries.