YACReader
YACReaderLibrary: Wrong total page count after modifying previously scanned comic file
looks like total pages number creating only 1 time at first indexing. for update ongoings i use Manga Reader.
Uh … if I understand you correctly you modified those files after indexing?
We have a mechanism for detecting changes in comics when running a library update, but it isn't always reliable.
yes, as i know it just adds new files in existing archive.
maybe possible to make additional, more deep library update mode?
No, we need better checking for modifications in this case. Our current method takes a few bytes from the start of the comic and compares this to the last check, which works very good when covers are modified. But in your case pages are added at the end so this method is completely failing.
I have some ideas on how we could improve this, but they will require updates to the comic database format to work. I'm not too familiar with this part of the program, so we'll have to wait for @luisangelsm opinion on this.
I guess it depends on the file format used and where it stored the information in the file. Usually deep changes like you did affect the hash.
Probably the best approach is to change the hash calculation depending on the file format being scanned and what can information we can extract from the file to calculate a reliable hash value.
Maybe we should take into account the last modified date of a file while updating. I don't know how reliable is this across different systems and file systems.
BUT, the problem here probably is that the files you have changed keep the exact same name, so YACReaderLibrary won't recalculate the hash of those files when updating. It is like this for performance reasons, recalculating hashes in a regular update will take a lot of time.
I don't know how many files you have changed that way, but if they are in a folder, just move or rename the folder, update, and then rename it again. That should do the trick for now.
I haven't tested this, but appending files to a zip file shouldn't change our hash since we only process the first few bytes and .zip stores the file indexes as a central directory at the end of the file. This is probably an example of "worst case".
File modification time could be pretty reliable if we use it as an indicator for a more thorough check. So if the file modification times matches the last check, do nothing, but if it mismatches flag the file for hash processing. We also could check if the file sizes match. If we do this right this might even be faster than the current method.