Thread: JBPatch
View Single Post
Old 07-28-2013, 03:36 AM   #1477
ixtab
(offline)
ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.
 
ixtab's Avatar
 
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
Quote:
Originally Posted by ams View Post
I'm using a KT with FW 5.1.2. Bought it recently just because of JBPatch. Thank you so much for this great patch (and Kubrick and Collections Manager).

I have one suggestion:
Would it be possible to have an alternative version of coverview.jar without the thumbnail fix (could be just the coverview.jar file I guess, to be sync-ed after installation of the main distribution)?

As Calibre now sideloads the thumbnails, there is no real problem anymore with Amazon's thumbnail bug.

The thumbnail fix in JBPatch's coverview for KT 5.1.2 treats old mobi and KF8 azw3 differently (azw3 files seem to behave the same with and without the fix). But the main problem is that for mobi books the thumbnail filename does not contain the ASIN but rather a number that changes everytime the mobi-file changes (like when editing the book or the metadata). As a consequence the system/thumbnails directory after a while is full of duplicate thumbnail files.
I'm not entirely sure if I understand the problem correctly... but it seems like this is essentially calibre's fault.

The cover view patch itself does not generate the thumbnails, but merely patches the firmware to also treat .mobi (KF7) files which contain a UUID (rather than an ASIN) as "files which can contain a valid thumbnail image". If I disabled that part of the functionality, those files would most probably show up without a thumbnail, even if they contained one.

The "calibre" bit from your post is particularly puzzling. So from what I understand, calibre creates a new UUID every time the file is modified. This is the root cause of all the trouble. What I don't get is what happens next.

A) Does calibre create the according thumbnail file by itself and put it into the thumbnails directory? In this case it would be calibre which is responsible for cluttering the file system.

B) Does calibre create some other file with a stable name (what?), and put it somewhere on the file system (where?) ? In this case disabling that part of the cover view patch would still result in the book not showing a cover in cover view.

Sorry if this post sounded a bit confused, it's because I am confused

Anyway, I'm attaching a version of the cover view patch which does not contain the parts with the ASIN/UUID fix. So give this one a try and let me know if it does what you hoped for, but don't be surprised if you don't see covers at all for the affected books. If it helps, good. If it doesn't - honestly, I wouldn't worry about those few duplicate files in the thumbnails folder

(@everyone else: the attached file is experimental. Only install it if you're adventurous and if you know why you'd want to install it.)

PS: It makes sense to delete the entire thumbnails directory before checking the results of the replacement
Attached Files
File Type: jar com.mobileread.ixtab.patch.coverview.jar (5.6 KB, 241 views)

Last edited by ixtab; 07-28-2013 at 03:38 AM.
ixtab is offline   Reply With Quote