I actually had the feeling that ComicRack did not have major stability problems. Wow, was I wrong... After some new reports on the Forum (hint: if you have problems, post them there), I really tried to crash ComicRack. Let's say I did not have to try very hard :/
ComicRack is a rather sophisticated application with about 25 threads running concurrently. These background threads do stuff like loading and creating thumbnails, precaching pages, updating information to the files, saving the changed library back to disk, converting a batch of comics to a new format and so on. One of the goals was to write ComicRack in a non blocking way, meaning in only very rare cases there should be progress bars.
One of the things I learned is that unrar.dll from
rarlabs (which ComicRack uses to open cbr files) is not very stable in multithreading conditions. And if it breaks, all sort of 2nd tier bugs surfaced.
So two days of stress tests and really pushing the limit, testing in single and multi processor conditions, i would say that the stability problems should be solved.
Build 0.9.48:
- CHANGE: Added "ScriptPath" global variable for Python scripts
- CHANGE: Reduced Page arrow sizes to 60%
- CHANGE: Whenever a new eComic opened, the reader gets the focus (enabling up, down etc.)
- CHANGE: Showing the Browser does not set the input focus to it anymore
- CHANGE: Moved loading pages/thumbnails indicator into the statusbar
- BUG: Fixed closing open Stack when exiting ComicRack
- BUG: Switched RAR to single threading - seems to fix memory curruption problem
- BUG: Fixed invalid index in reader if image provider failed (0 pages situation)
- BUG: Fixed index out of range in tab management
- BUG: Fixed "Image in use" of the tab bar
- BUG: Removed animating "Gear wheel" to remove other 2nd "Image in use" bug
- BUG: Fixed skewed thumbnails in the Remove Question Dialog
- BUG: Comics where not removed from the displayed Smart List when deleted
hf