ComicRack has a new home! Redirecting…

You should be automatically redirected. If not, visit and update your bookmarks.

Friday, October 27, 2006

ComicRack v.0.9.15 released

A rather quick new release, but i had time to clean some stuff up and optimize.
Main reason is to add the new unrar.dll to the package, as this seems to solve some issues in some rare environments.

Build 0.9.15:
  • CHANGE: Optimizations when displaying folders with eComics which are not in the Library
  • CHANGE: Update to unrar.dll 3.70 - seems this fixes some problems
  • CHANGE: ComicInfo.xml in cbr/cbz files is now only read when the eComic is opened for reading or added to the database
  • CHANGE: Folder/File list in file browser is now built on first selection and not on application start
  • CHANGE: Embedded information in eComics only updated when the information really changes
  • CHANGE: Less foreground updates during scanning
  • BUG: Image sizes where not displayed correctly for files not in the database
  • BUG: Library entry could be removed in the Library Browser
As a side note: ComicRack performs best if you add your comics to the library. This allows ComicRack to make heavy use of data and information caching. The whole explorer part of it is just there for additional convenience (if you ever wondered why there's not more explorer stuff like copy files, delete etc. - thats the reason).

And second side note: i come more and more to the conclusion that cbz/cbr is a very insufficient format to store comics in.
So what are the problems ComicRack has to cope with:
  • Very slow
    Getting the count of images or trying to read ComicInfo.xml from inside costs a lot of time. Because each time ComicRack has to open the archive and decompress part of it.
  • Not Updateable
    You can not write information back to the file. With rar it is not possible at all (because of licensing) and with zip it would be just crazy (decompress archive, change/add file and compress again). That's the reason ComicRack has to resort to open up secondary filestreams to store the information in the files. But this again can lead to synchronization problems as there are three possible places for meta information - ComicInfo.xml, NTFS secondary stream, database... - a sack full of cats...
What should be the right way to do it? I don't know, but if i had to design it from scratch, i would go for a xml based file format with embedded CData elements for the images. Info would be at the end so you could update the file without rewriting it.

Maybe i should get in contact with some of the linux guys to come with something up...