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 ... 139 140 141 142 143 [144] 145 146 147 148 149 ... 172
2861
Verification of roms and playability are two different things.
Clrmamepro compares the hashvalue (crc32/sha1/md5) of a file against the one which is stored in the loaded datfile. If it matches, the file is good for clrmame. This of course does not mean anything regarding playability.

In case of roms with headers, like nes, the datfile usually only holds the checksum for the rom part without the header, i.e. cmpro also has to only calculate the hash over the header-less part. Usually header information can vary while the actual rompart stays the same, that's why you only want to look at the real binary part of the rom, not the header.

So, clrmame is checking correctly, since you scan it with a dat for header-less files and you only compare the header-less part.

I guess your emulators most likely need information stored in the header to work correctly...which is missing or is different in your file. So you have to check the meta data in there....but that's not a task for cmpro (unless you have another dat which holds checksums for the full file....)

2862
64 bit windows 7 here too, no issues

- check if your cmpro folder holds version64.ini

- In which folder did you install cmpro? Hopefully not an UAC protected folder.....

2863
clrmame Discussion / clrmamepro 3.138
« on: 22 March 2011, 21:09 »
added: batcher rebuild options for always compress / never recompress and packer type
misc:  updated winrar dll
fixed: cleaning parsed data always uses yes to nodump replacement
fixed: crash bug when removing full archives from sample paths

2864
clrmame Discussion / Re: bug: "no to all" can mean "yes"
« on: 14 March 2011, 20:56 »
yep, it will always use 'yes' no matter what you're selecting....will be fixed for next version

2865
clrmame Discussion / Re: bug: "no to all" can mean "yes"
« on: 13 March 2011, 21:53 »
hmmm...interesting finding....will check that more deeply

2866
clrmame Discussion / Re: Problem with CHDs with 141u3
« on: 12 March 2011, 18:55 »
there is no chd issue. the mentioned one is a chd shared among clones only not with the parent, so you have to double it.
more than 1 chd in a folder works also fine.

2867
options. Remember, I only want to check my existing zip files (about 1978 of them) and not check what I have against every game available for mame (10,000+).

I've answered that many times now. If you only want to scan your existing zip files, you have to go to set-information and hit the avail.sets button, then do a new scan.
Keep in mind that I also gave you a link where possible sideeffects of this method are described.

2868
Quote
states that I am missing the rom files when clearly I have them and they are showing up and playable in Mame.
If cmpro says you don't have it then you don't have it. Recheck your rompaths settings if they match the ones you're using in MAME. Sounds like you're scanning a wrong folder. "rodlandj.zip" should be in your rompath somewhere (when using split merged sets). But maybe you're using full merged sets and didn't set the correct merge mode in cmpro. You should check that. MAME loads it, well, of course since MAME doesn't really care where it gets its files from, it simply looks in each rompath and in all parent/clone sets.
Auto scrolling of the tree view can be disabled in the scanner popup menu by the way

I told you already to limit your sets in set-information. For example by pressing the "avail sets" button and do a new scan afterwards. I've also told you that limiting sets is usually not the way to go....Instead I'd do: be sure your rompaths and merge modes are correctly set, let the scanner fix all it can fix, then use the delete->all incomplete sets option and rescan with fix-missing disabled.


2869
Quote
window popped up and everything that came up seemed to have a red 'X' next to it. Is that what's supposed to happen??
everything listed is an issue....open the tree
  • branches to see the details. A red cross means that you got the set but it got issues. A red cross in front of a folder means you completely miss the sets.
Quote
It also raised the number of zip files in my roms folder from 1969 to 2914. That seems very odd. It also seems to have created a number of very small files (1KB - 4KB) too.
Nothing odd.....I already told you that fix-missing creates all missing files it finds somewhere (e.g. in other sets in your rompath). Besides of that over time sets get updated so that split of sets is also possible. Nothing odd....

Quote
As far as the part about "Scanner Popupmenu View->Hide Fully missing sets and/or Delete->All incomplete sets" I didn't see that option anywhere. Am I missing something?
Right click in the scan results tree view to see the popupmenu. If you use "delete->all incomplete sets", be sure to disable fix missing before doing another scan. The reason is simple, otherwise you would directly re-add the just removed sets from cmpro's backup folder.

2870
Quote
I downloaded Mamediff, but when I run it a DOS window pops uf for a split second then disappears so I guess that's not an option right now.
It's a commandline based tool. You need to run it from a command line interpreter. But as I said, it will create you a difference datfile out of two given dats...most likely not what you want.

Quote
When you say 'add the missing stuff' what exactly do you mean? All of the roms that I have added between v135 and now (over the past year or so) are in the same folder as the roms that I originally had--I don't have a seperate directory for the new roms; they are all in the same folder.
Fine...if you got all files in one folder, the scanner will clear up the mess for your. Usually when updating you have two categories of issues: Sets which need fixing (renames for example) and all the missing files due to newly added sets. The scanner fixes the renames etc but of course you need to add the newly added sets somehow...there the rebuilder can be used.

Quote
STEP 2 - Use 'Settings' and click 'Add' and enter the location of my roms (c:\Mame\Roms). Then Click 'Save as Def."?
No, don't click on "save as def.".

Quote
STEP 3 - Use the 'Scanner', Enable all of the 'Fix' options, leave all the other options the same and click the 'Scan' button.
The default scanner options are 'everything to check enabled' and split-merged mode. That's pretty fine for your. In other words, yes, keep all options untouched and check the fix options. If you like you can leave them disabled and hit new scan to see what is all wrong with your collection. Nothing will be touched then, just checked....and you can watch the tree output get filled...

Quote
This is where I think I get lost. If I follow the 3 steps above will this accomplish my goal of updating ONLY the roms (zip files) that I have (if needed) so they will work in v141 (in the event that they have changed between v135 and v141)????
If you only want to update the sets you have you can go to set-information and hit 'avail. sets'. Afterwards do a new-scan.
However, read this: http://www.emulab.it/forum/index.php?topic=22.msg439#msg439
Limiting sets is not a good thing to do...I personally prefer scanning/fixing all and afterwards removing/hiding the stuff I don't want (Scanner Popupmenu View->Hide Fully missing sets and/or Delete->All incomplete sets)....

2871
If you only care about sets which changed between two versions use mamediff to create a diff-dat and use that.

But I think you don't want that. Correct me if I'm wrong but you got a .135 collection and now want to use them with .141.
As mentioned before you don't need to rebuild them especially not with recompression enabled.

First step is to load a .141 database (Profiler->Create->use your .141 mame binary)
2nd step is setting up rompaths (if not yet done)
3rd step is the scanner, enable all check and fix options and let it go. It will fix what can be fixed
4th step is "add the missing stuff"...if you collected roms between .135 and .141 you can e.g. drag'n drop them into the scan tree window...internally this runs the rebuilder - an Adder -. Afterwards, rescan.


Scanning a full MAME set on a Core2Duo machine takes maybe 15 seconds to a minute (depending on the used diskcache) and no fixing. If lots of things need to get fixed it takes longer of course.

Regarding the single files, as mentioned before, rebuilder is file based and creates all instances of files. Same for fix-missing in the scanner. If you don't want that, you need to limit the sets to the sets you have/want. Go to Scanner->Set Information for this and disable sets manually, via regular expressions, variables, file lists or available button.

2872
Ok....where to start....

Some general things...

Merging modes - They define how you can store sets which share a parent/clone relationship. For example there are 50 pacman sets where they usually only differ in 1 or 2 files while the others are identical throughout the sets. Now you have different methods of storing such sets.
"not merged" or "Unmerged" - all sets hold all the files...so a parent holds all the files and each clone holds the shared files as well....in other words....waste of diskspace. Your set count is identical to the set count in MAME.
"split merged" - very common method to store sets.  Again, set count matches the total count in MAME. The difference is that each set only holds the file it really needs, i.e. the parent sets hold the parent files and each clone only holds the file which is not share with the parent.
"full merged" or "merged" sets - compact form...you only have archives for the parent sets and they include all clones as well. Archives for clones don't exist.

Ok...next thing....Profiler, Settings, Scanner, Rebuilder...

Profler - for MAME, use the create option to quickly create a database from the mame binary
Settings - for now, used to setup rom and sample paths

Scanner is used to update your sets, fix issues, get a list of what is wrong with your sets.

Rebuilder is an Adder. It's file based and takes anything it finds in its defined source and copies/moves it to a given destination. It's usually used to rebuild sets from one emulator for a different one but is also commonly used for a quick way to add missing files to your collection. The rebuilder doesn't care about names, it can find out what the real name is and rebuilds all instances of the files it matched.

General way to update MAME is to

1) load the new data in the profiler
2) (if not done yet, setup rompaths, maybe sample paths if you need them)
3) go to the scanner and hit scan (default options are fine)
4) you can enable all fix options there and do another scan to fix all issues
5) after that you should only have missing files (which can't be magically created from nothing)
6) add missing files with the rebuilder (e.g. drag'n drop into the scan results window)
7) scan again and repeat 6/7 till nothing is listed in the scan tree window anymore


Speed:
Well, of course the amount of sets and your PC specs play a role. Rebuilding is fast if you don't use re-compression. Scanning is fast if you don't decompress files to check hashes. Virusscanners should be disabled for the romfolders.


You only have some sets, not all....
Generally you should check all sets and don't care so much about endless lists of fully-missing sets. There is an option to hide them. You can only scan subsets of the full MAME set as well...in Set-Information you got several options to only enable some sets.
You mention the rebuilder creates single files for sets you don't have....well...yes it does...it's its main purpose to do so. That's the cool thing about it. Also Scanner's fix-missing option can do that. If a rom file is missing (e.g. for a set you don't have), cmpro looks at various places if it finds it somewhere and adds it. This doesn't necessarily mean you get complete sets by that method...

As mentioned, the scanner popupmenu holds several options to either hide missing sets afterwards or remove incomplete sets.

Puuuh....should be enough for a start....

2873
I can give you  a detailed answer in about 24 hours when Im back on a real PC... please be patient.

2874
clrmame Discussion / Re: no clones
« on: 05 March 2011, 10:11 »
dont use " in select sets edit box....

2875
clrmame Discussion / Re: no clones
« on: 05 March 2011, 07:49 »
Hmm..works fine here.

after entering %c=?* in select sets, checking the logical not checkbox and hitting apply button the count changes to e.g. 5304/10383 (141u3) and doing a rebuild afterwards it does only create the parent files.....

The correct selection is also visible in set selection..only the parent sets are checked in the tree view on the left.... after hitting apply.

2876
actually it's not really 7z itself, it's more the lack of free time...I will see what I can do...

2877
clrmame Discussion / clrmamepro 3.137d
« on: 01 March 2011, 20:45 »
fixed: removed trimming of xml attribute values for now since it disallows whitespace separators for export lists

2878
clrmame Discussion / Re: clrmamepro 3.137c released
« on: 01 March 2011, 19:40 »
hmm..interesting sideeffect...will check this....

...ah found it :O) The trimming of xml attributes kills the linebreak.....
will do an update soon

2879
Hehehe...well, actually I'd like to get rid of the external packer for 7z completely and would like to use the current dll for reading and writing 7zs (and so LZMA2 would come for free)...but my current amount of time plus the lack of well documented dll function calls keeps this pending. If you got the time to find a good documentation and examples for the dll calls, feel free to send them to me...

2880
clrmame Discussion / clrmamepro 3.137c released
« on: 28 February 2011, 21:04 »
3.137c

fixed: 7z add/remove fails for files starting with @
fixed: scanner popup menu functions to delete/move incomplete/notfixed sets got rare issues when deleting files
fixed: removed very old chd extension workaround which causes issues now with chds with "."
fixed: xml parser misses attribute name/value trimming

Pages: 1 ... 139 140 141 142 143 [144] 145 146 147 148 149 ... 172

Page created in 0.09 seconds with 20 queries.