Thread: Touch .kepub.epub
View Single Post
Old 01-29-2013, 08:25 PM   #39
davidfor
Wizard
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 4,947
Karma: 4798550
Join Date: Jul 2011
Location: Australia
Device: Kobo Touch, Kobo Glo
Quote:
Originally Posted by jgoguen View Post
I believe there is a bug submitted that, once I fix it, will address this. There may need to be some changes to how the Kobo tags get added.

Because of the issues with the database code (which, BTW, isn't really useful for anything until I sort out how to make the Kobo devices not do their initial processing) the no-database branch is default when you visit the repository. There is an issue tracker there for any problems you may find.
What do you want to stop? If you are trying to stop all the scanning, that isn't a good idea. What about all the other book types, or if books are added outside calibre.

If you are just trying to prevent the new .kepub.epub from being scanned and reprocessed, then it should be in the timestamps and file sizes. The last change I made to the driver was to update the files size when resending a book. This prevented the replaced book from being removed when the processing was done.

It might be different for kepubs. I can see an entry in the Event table for all downloaded kepubs that isn't there for sideloaded books. Look for EventType=4.

But, when I have tested the database code, it didn't create all the rows. All the ContentType=6 and 9 seem to be there, but not the 899. The last test was with code I downloaded yesterday, so it should be the latest.

If you continue with the database updates, you should also consider epub3. The TOC is no longer in a separate file but inside the OPF. Kobo support for epub3 is reasonably good and getting better. An extra thing to try is adding the epub3 statement to the OPF for series info. That might get read even on an epub2.
Quote:
@davidfor: Would you like me to work on merging the kepub code I have with the main KoboTouch driver and submit a patch? I'd want to finish the known issues first, and I could make two options; one for "use .kepub.epub" that automatically updates the file name but doesn't touch the files themselves, and one for "enable all the extra stuff" that tweaks the book files and implies forcing .kepub.epub.
I still haven't completely made up my mind about adding this. If I do, I'll do the merge. I need to be happy it all works. And the options are a problem I need to look at. There are already a lot, and there is another I am thinking about. Plus, separating the file naming from the file massaging is pointless. One thing, I won't be doing the database changes.
davidfor is offline   Reply With Quote