Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[donnyj]

I have a updated dat file with a few 17 7z sets totalling 667 MB. The scan was taking forever (all fix options enabled with advanced, etc. enabled). I just wanted a fast scan so I disabled ALL fix options (hit the + sign twice). Clrmame still displayed that it was doing checksum analysis (with a long delay). I would have thought that disabling all fix options would override any advanced options?

[Roman]

Time depends a little bit on check-options not only fix options. E.g. if you scan for sha1 hashes (Scanner->Hash & CHD), it will decompress the archived file to memory and calculates the sha1 checksum...

For checksum analysis it will do similar if you have the "Run Analysis" option enabled. Is that disabled in your scan?

[donnyj]

crap, yeah I forgot the "Checksums" box... but I still don't understand why any additional scanning would be triggered if the fix options are disabled? There are no checksums in the dat file besides the CRC32. We are talking the difference between HOURS and seconds.

[Roman]

crap, yeah I forgot the "Checksums" box... but I still don't understand why any additional scanning would be triggered if the fix options are disabled? There are no checksums in the dat file besides the CRC32. We are talking the difference between HOURS and seconds.

There is no additional scanning. The "run analysis" is the part which can take long. In case of a wrong checksum for example it decompresses the file and does the analysis (like applying byte order changes to see if this solves the checksum issue etc.). The 'fix file (if possible)' writes back the file if the analysis shows that it's fixable.

[donnyj]

I am sorry, I am not communicating well.


Here is what I don't understand:

1. I have a dat file that countains 10 sets.
2. I do not want to fix or change ANYTHING about the sets.
3. I only want to scan to find out what needs the work.
3a. I need to know which file sets are "ok" and I want to just MOVE the other sets that do need some changes (renames, deleted, added, checksum checking, etc.) group put somewhere else.

To accomplish this, I disable all "Fix" options (Missing, Case, Unneeded, Name, Size, Date) I am trying to say that if you have no fix options enabled. (In other words, you want a SCAN only without any reason to do the run analysus.) Then I scan. If it asks to add a missing file or remove an unneeded file, I want NO. The only change that I wans is if the original set changes one of it's base names, then I do want that fixed)

But apparently I also need to go into the "Advanced Scanner Options" and then over to the "Fix Missing Options and I need to make changes here.  (reminded that why should I need to make changed for Advanced Scanner Options for fixing misses)

SO, why are we bothering with the VERY SLOW Avanced Scanner Options if we have aldready disabled the associated fix checkbox.

I am extremely tired so I may not be coming across well.

See you tomorrow.

[Roman]

I Then I scan. If it asks to add a missing file or remove an unneeded file, I want NO.

If no fix options are enabled, it won't ask and won't fix.

But apparently I also need to go into the "Advanced Scanner Options" and then over to the "Fix Missing Options and I need to make changes here.  (reminded that why should I need to make changed for Advanced Scanner Options for fixing misses)

No you don't have to do this.

SO, why are we bothering with the VERY SLOW Avanced Scanner Options if we have aldready disabled the associated fix checkbox.

Again, you don't have to do this. I only told you that if you got the checksum analysis in CHD&Hashes enabled, it will do the analysis which can take long in some case. This has nothing to do with the standard fix/check options.

[donnyj]

thank you for your patience

[Roman]

so the options are clear now?

[donnyj]

I understand the options I just didn't understand the reasoning. I figured that if you weren't planning on fixing anything there would be no reason to perform checksum analysis, etc. I rebuilt the affected files so I cannot check the behavior. Did it show in the status window which files/sets were fixable? If that's the case, I understand... Because even if I didn't want to fix the problems, it would come in handy to know which were fixable if I did choose to fix them.

[Roman]

I understand the options I just didn't understand the reasoning. I figured that if you weren't planning on fixing anything there would be no reason to perform checksum analysis, etc. I rebuilt the affected files so I cannot check the behavior. Did it show in the status window which files/sets were fixable? If that's the case, I understand... Because even if I didn't want to fix the problems, it would come in handy to know which were fixable if I did choose to fix them.

First, please differ between checksum analysis and the standard checkum checks.
A checksum check can be e.g. crc32 which can be rather quick for archived files since the checksum check will simply compare the stored information with the database. A checksum check can be more time-consuming when it has to decompress the file to check the sha1 for example.

This is all 'checking'. 'Checking' also includes (if enabled, default is disabled) the checksum analysis. This checks are run when a wrong checksum was found. Then it checks if byte order changes or fills with patterns can create a valid checksum.

Fixing can be enabled by the belonging standard fix options or -for checksum analysis- with the 'fix file (if possible)' option which corresponds to the standard fix operations.


So, by default all fix options are disabled. So actually you don't have to change anything to do what you wanted to do.

[donnyj]

strange, I typed a reply an hour ago, but I can't see it now... I must have not sent it....

understood.... My biggest problem appears to be using solid 7z archives. In order to do the checksum analysis, etc. the entire 7z needed to be decompressed. With smaller sets, no big problem but with huge archives it was completely bogging down the system. I have had issues with renaming and deleting roms from within 7z archives (I am sure it is a problem with 7z, NOT with cmpro) so I am abandoning 7z for larger sets. The trade-off of saving space in exchange for a headache just isn't worth it.

[Roman]

well...7z support is not priority as you might know. Solid archives are always a problem since there are a lot operations in cmpro which are file based (i.e. adding one file to an existing archive). For 7z this would mean that it has to recompress the full file over and over again each time a new file is added. It's a pain. Besides of that, as soon as you got one of the 'deeper' checksum checks (like full archive test, sha1, checksum analysis) enabled, it will decompress files into memory...and again....file by file...for solid archives this would mean it skips 99% of the time