well...I guess I found a repeatable scenario and a fix for it.... Scenario is pretty easy to build afterall, create a dat with 1 set, load it in standard mode, scan the set, 100% ok. Now change the dat (e.g. size change of a rom), add it to the profiler again (overwrite old), and use the load in batchmode for it....it won't mark the profile red afterwards or shows the error (when you had KeepScannerOutput enabled)...
I got a fix here which I will try to test the next days a bit more....
Ah...ok...right...totally forgot that there are users which don't have at least 16GB RAM Actually I forgot that there are people out there which use PCs....I rarely touch it these days...
Well, I can't promise that it will be better memorywise but at least I started to have a look at the CPP SDK code....and I managed to do a quick direct extraction to disk of the problematic 7z in question.... Cleanup and adding callbacks for blockwise checksum calculation etc is next.....but again...I doubt I have time before end of this month...
some good news....I quickly looked at the CPP 7z sdk part and its way to extract/test/compress files....and hacked in a quick decompress using that...your files are decompressed correctly...
I may have some time end of this month...so most likely I switch to CPP based routines for extraction (maybe later for compression, too) of 7z (currently it uses the C part of the SDK)....blockwise decompression (less memory usage) might be a nice sideeffect....
well...generally the C part of the sdk is limited (esp. when it comes to solid archives). CPP part however uses some annoying COM interface stuff.....if I got lots of time (doubful in the near future) I may look into this again....
haynor666, sdk 9.22 is used... I debugged it a bit inside of the SzArEx_Extract function but it fails within decoding this LZMA2:17 (whatever type is this...since LZMA2 is no problem) data stream....maybe I will have a deeper look where inside the 7z code it fails...but my time is currently very limited.....
to be more concrete...it fails in 7zDec.c where the status is not LZMA_STATUS_FINISHED_WITH_MARK...."status" at that point is LZMA_STATUS_NEEDS_MORE_INPUT
if (state.decoder.dicBufSize != outSize || lookahead != 0 || (status != LZMA_STATUS_FINISHED_WITH_MARK)) res = SZ_ERROR_DATA;
Well tough luck, the sdk call SzArEx_Extract simply fails for decompressing (and so it fails for recalculating sha1/md5/crc32 and comparing them with the header).
...in other words...you have to wait till the 7z sdk gets updated....if this ever happens
Actually, the error comes from cmpro's full archive test (when you enabled this). It compares the found crc32 from the archive header with the recalculated one by decompressing the data into memory. I will check your sent files later tomorrow (if I find a little time)...
well, usually the errors come from the 7z sdk itself....which is..hmm..let's say...problematic here or there...not to talk about the current alpha beta whatever status of 7z....
you can try to send me the archives and I will have a closer look.
hmm...I can't really reproduce this... so what I did:
created a bunch of dats...loaded them (not batch), did a full scan for each...all are 100% ok...fine... now I modified one of these dats (renamed a single rom inside one set) readded it to the profiler), and ran a batch run on all dats again with "Use scan when possible (instead of new scan)" enabled....
the profile gets red in the profiler afterwards and the scanner shows the error...
hmmm... a scan (not a new scan) is possible if the underlying dat was not changed and a previous new scan has been done. if the dat changed, cmpro detects this and removes the cache and fastscan folder information and the scan button is disabled.
theoretically, a batch operation should work identically since the dat/profile loader is responsible for this and it's one and the same for batch and normal mode.
I need to do some tests for this specific scenario, now that I understand it thanks for the head up....