About meta data... again

As there seems to be a lot of confusion about where and when ComicRack stores it's meta data, lets get it from the mouth of the horse :)

ComicRack always stores data as Xml snippets (either as part of the big library file) or as single small files into eComics (see below).

When adding or opening eComics and there is a secondary stream present for the file (only on NTFS), the xml data from this stream is loaded. If no stream is present and the eComic is an archive, it is opened and a ComicInfo.xml is searched.

If you change meta data, the data is stored to the Library and to the secondary NTFS stream (if file is on NTFS and the write meta data to file option is turned on). The ComicInfo.xml file is NEVER changed. It always stays the same in this process.

ComicInfo.xml IS added to eComics when they are saved to an archive or file list format (Save as...) or converted (Convert to CBZ). Also only images not tagged as deleted are written.

Now you may wonder why this is done so complicated...

ComicRack supports various file formats (PDF, CBZ (ZIP), CBR(RAR) and will add further in the future like TAR.GZ). Let's take a closer look at these different file formats:

• PDF: No archive at all, no place for ComicInfo.xml or any custom meta data.
• CBR: Rar format can not be written (proprietary)
• CBZ: Can be written, but changing the ComicInfo.xml would require to unpack the cbz, change the single file and pack up the whole thing again. This is very costly. That's the reason why ComicInfo.xml is not updated.
• Future Formats: If they support fast replacement of the data file without unpacking the whole thing, comicrack will do it.
  

One of the implications for the whole process is also, that even if you only use ComicRacks file browser, you should still add all the files to the library. Because the library is the fastest way to get the data.

If there's popular demand, i may add a function like "Commit meta data to eComic" for file formats which support it (CBZ).

I hope everything is clear now.

This whole "use an archive format" for eComics may have been valid for the past, but it is very unsatisfactory for applications like ComicRack. If mp3 files would have been done the same way, changing id3 data would require the editor to expand the whole thing to a wave file, change the data, and recompress it again to mp3...

Using secondary streams on NTFS was the only plausible solution to store the info also to the eComic files and not only to the Library.

So how would IMHO a GOOD comic book file format look like (just a quick idea):

[signature]
[xml info offset]
[count of images]

this block repeats n times
[size of image stream]
[image stream]

[xml info]

This way you could do a very easy and fast update of the info, without doing much with the (possible huge amount) of image data. As pages are already compressed, compressing them again is unnecessary (always use store for zip files :)). But the problem is, this would be a proprietary format and thats where the only strength of archive based formats shines: You can open and extract the content with hundreds of free and open tools on every OS out there (That's also one of the reason why PDF is not a good choice).

Of course, a tool to parse the above file format would be 50 lines of code...

ComicRack v 0.9.52 released

52 seems to be everywhere now :)

Finally I came around to adjust the Favorites Folder Browser already present in the original RComix versions to its current importance.
The first versions of ComicRack (RComix) where file browsing only, so that's the reason for the prominent Favorites Folder Browser. ComicRack has come a long way and there is not really a good reason anymore to have a folder shortcut manager of the same size as the whole Library Browser.
So now you find the favorites where they belong to, as a small part of the Folders Browser.

And for all you Manga guys out there, you can now batch set the "Manga Style" setting for eComics.

Build 0.9.52:

• NEW: Added "Manga Style" setting to Multiple Comics Dialog
  

• CHANGE: Speedup of cache initialization and hit/update logic
• CHANGE: Redesign of Multiple Comics Dialog
• CHANGE: Library consolidation is only done every 50th startup
• CHANGE: Moved Favorites functionality into the Folder browser
• CHANGE: Separate background queues for slow thumbnails (have to be created) and fast thumbnails (already in disk cache). This means, that new thumbnail creation does no longer block loading of already cached thumbnails.

hf

Slower inital cache startup

As I rewrote the whole diskcache in 0.9.51 to get rid of the ever growing cache bug, startup times may now be slower depending on your cache size and number of cached items.

Also if you have accumulated a huge cache because of the above bug, this will be cleaned on the first run after the install.

So give it some time :)
As long as you hear your disk spinning, ComicRack is hard at work :)

Following startups should be faster.

Maybe I come up with a different solution in one of the next builds.

ComicRack v 0.9.51 released

Again, more or less, a consolidation release.

This should fix the "Track moved files" feature.
If you move files to a new location, just make shure that the new location is covered in the Library Paths. Then hit "Scan Library Folders". ComicRack will correctly identify the moved files and just replace the path of the items already in your Library. As the old hash algorithm was broken, ComicRack will rehash all the files the first time you hit "Scan Library Folders" after the install. This can take some time depending on your Library size.

Build 0.9.51:

• NEW: Key assignable exit command for the reader (default is Q)
• NEW: "Mark as deleted" command in the pages browser
  

• CHANGE: Save Workspace now supports selecting an existing Workspace to update
• CHANGE: Pressing [x] in Quicksearch sets the input focus to the Quicksearch textbox
• CHANGE: "Include Subfolder" settings are stored
• CHANGE: Current selected Browser is stored (Library, Folders, Favs, Pages)
• CHANGE: Separate on/off switches for current page and visible page part overlays
• CHANGE: Next open restores all open tabs (and not only last file)
• CHANGE: Cache is always trimmed and not only on shutdown
• CHANGE: All lists (and not only the library) get refreshed when the library changes
• CHANGE: Writing meta info to comic files does no longer change the modified time
• CHANGE: Scanning also hashes all files not previously hashed
  

• BUG: Fixed failed restore of docking state
• BUG: No favorites item was initially selected (empty view)
• BUG: Newly added items where initially added with an "Added" value of "Never" to the list
• BUG: When directly starting a second instance, the restored old one tried to open a null file
• BUG: "Track moved files" for scanning was broken
• BUG: Hash algorithm for files was broken (switched over to SHA1 now)
• BUG: Crashing bug when dropping a library folder in itself
• BUG: Drawing bug when a drag over item also was selected
• BUG: Correct handling of deleting/removing eComics from the library when they are still in use
• BUG: Paging Arrows where shown even when no eComic was open
• BUG: Ghostscript resolution was not clamped on the upside

hf