That would be great.

selmf wrote:
Thanks for taking a look into this. I think it's definitely going to be a good thing for the program if the library refreshes to reflect any changes in the books and folders.

I'll try to fix this till the next beta but I can't promise anything. Sometimes seemingly small changes tend to cause big problems and you end up having to rewrite major parts of the code. So, until I ran some tests and know how deep the rabbit hole goes it's hard to tell how much work this is gonna be.

Btw, I'd like to thank you and the other users on the forum very much for being so thorough in reporting bugs. While we've been having a hard time hunting down some of these (and even had competitive debug sessions ) we've been able to fix some deeply rooted nasty bugs that have gone unnoticed for multiple releases.

Thanks, while I have used many different readers over the years, I'm new to YACReader, but when I see you guys working on this stuff and so active on the forums I really have very high hopes for this program. I'm already using it pretty regularly and have recommended it to other people.

As I feared the hash problem is only one part of the puzzle. The whole update process is actually quite complex and will require more work.

Looks like a real YACReadian Knot.

selmf wrote:
>_<

Sorry, man...

It happens. I had a similiar experience with the double page mode. In such cases it often is the best solution to start from scratch again, i.e instead of adding more complexity to try to rewrite the function in a simpler and cleaner way. However, we're deep in the beta so this is a risk I'm not sure Luis is willing to take

The current hash calculation can cause some collisions, it uses the first 0.5MB but it also adds the files size to the end of the hash. So most of files changes are detected.

Obviously, this mechanism is very easy to break. But we aren't talking about security here, just performance.

I am not sure that the hash has something to do with folders not being updated properly. Real folders are compared with the folders in the data base, no hash implied.

Yes, the hash could be a point of failure but the actual failure happens before we're getting to the part of the code where hashes are calculated and/or checked. The update code relies on filenames and directory names only.
The problem I see with the library code is that it deals with a lot of cases of match/mismatch between the directories and the cached database, but it does not take the modification times of files and directories into account. Also, because every corner case of match/mismatch has to be taken into account the function is quite complicated. Now, there are two ways to go on from this point and both are equally "dangerous":

1. "Fix" the function: will add more complexity to it and invite a whole lot of more bugs. It might even not be possible to do this at all. However, if it succeeds, you still have the old proven codebase.
2. Rewrite the function: has all the problems new code usually has - you get untested, possibly buggy code but if it's done well you also get the advantages new code


Personally, I'd go for the rewrite just to make this function more manageable. Don't get me wrong, the update function is a nice work of coding and makes good use of recursion with some interesting coding concepts. However, my gut feeling tells me it is doing things the "hard way" and we should think about how to achieve the same result the "easy" way.
I even have a rough idea on how this could be done. Qt has some nice features related to QLists and Filesystems which the code does not fully take advantage of, so there's some room for improvement. Fixing the whole issue might need some adjustments to the database to add the timestamps needed for actuality checks though.


The question remaining for me right now is how grave Luis considers these refreshing bugs. If it's a blocker it might be worth the risk of a rewrite, if it's not a blocker I'll postpone working on it for the release after 8.0.0

I don't see it as a blocker. At this point, there are more risks than benefits for trying to rewrite the update code for 8.0.

At the end of the function for updating there is a TODO task (in spanish sorry, and some old code commented). So this issue has been always identified from the first version of YACReaderLibrary. Even if we check dates, the code can be tricked easily changing the system clock (this could cause a big mess, and force a full update of the library). But it probably is the only way to go.

I have said a lot of times that I don't like the idea of modifying comic files, so I have never prioritized this. Although I understand that it should be fixed.

I dropped a feature for forcing a full refresh of the selected files from the next release, lack of time. Maybe in 8.1....

There are other bug in this topic, the issue with the folders. I fixed a similar issue years ago in the old update code (when sqlite wan't used), maybe I introduced a regression...