[GUI Plugin] Count Pages

[kiwidude]

Your comments are far too brief to be able to help you - three times now you have posted 10 words or less to describe your problem. We are not mind readers and cannot see your screen. I have given you screenshots above of examples of what you need to setup. If your screen does not look like the above then post a screenshot of what it does look like. If you mean that the count words dropdown only has one thing in it, then yes that is by design but the section at the top is for counting pages.

[bigbird1227]

my screenshot looks exactly like the one you have shown. in the box marked Algorithm i have the same wording that you "Total word count" I am looking for the option that says "Total page count" does your plugin have it. Mine doesn't

[kiwidude]

Right, thanks, now I understand. If you look at the screen, you will see that is within the box "Word count options", hence why there is nothing to do with page count in it.

Above it is the box for "Page count options". Any of the algorithms in the page count options box will give you the equivalent of a total page count, they just have differing ways of doing it. I suggest leaving it at the default of "Paragraphs (APNX Accurate)". Contrary to your apparent confusion, this algorithm does give you a page count, but it does so by trying to identifying paragraphs within the book as part of a way of estimating how many pages there are. That is why it says "Paragraphs". The other option in there of "Calibre Viewer" gives you the same count that opening the book in Calibre's ebook viewer, which is based on dividing the number of characters in the book into 1024 per page, supposedly some Adobe standard.

[bigbird1227]

finally got it to work

thanks

[capnm]

Re: Calibre memory leak & slowdown when updating metadata

I finally had chance to try this on another machine running Win7 x64 (4Gb)
(first machine was Win7 32bit SP1, 2.5Gb)
DEP for essential windows programs & services only
Antivirus disabled

Ran it against 800 books.

Same behavior - time to update metadata was roughly the same as the count phase (> 10 min)

Calibre memory usage climbed to almost 400Mb.

Ran ExtractISBN.
Extract phase about the same (>10 min), metadata update phase about 45 sec.

So there's something different about the metadata update procedure this plugin is using.

Of course after a few more tests I won't have any reason to count big batches again, so with a little patience and remembering to restart Calibre to clear the memory leak I'm good to go

[chaley]

It appears that in some cases, the tag browser eats memory. I was never able to reproduce it, but Kovid got close. The latest release (0.8.7) radically changes how the tag browser works initializes, eliminating (as far as we can tell) the problem.

If you run with the tag browser open, then try the new release. It might help.

[theducks]

Just a heads up.

I just had Count Pages crash Calibre upon updating a previous count.
8.7 on XP SP3

Repeated 3 times.

counted pages on a title, clicked OK to update . Crash.
Started Calibre Noted it did change the first time.
Tried again: Crash

I tried another title and it worked,

Tried title 1 and it crashed

Opened title1 Metadata editor and saved.

counted again: Joy

Gremlins?

[capnm]

Originally Posted by chaley

It appears that in some cases, the tag browser eats memory. I was never able to reproduce it, but Kovid got close. The latest release (0.8.7) radically changes how the tag browser works initializes, eliminating (as far as we can tell) the problem.

If you run with the tag browser open, then try the new release. It might help.

Well that surprised me, because 0.8.7 partly (but only partly) solved it.

The memory leak was reduced about 75%.
The metadata update went about 30-40% faster (but still at least 15x slower than Extract ISBN's).

It never occurred to me to run without the tag browser. I'll try that next. (Though I don't see why that should affect this and not Extract ISBN).

After that, I'll have counted most all my libraries, so unless you should happen to want me to test something, I'll probably forget about the issue

Many thanks!

[capnm]

Originally Posted by chaley

If you run with the tag browser open

CLOSE IT!!!!
Just say "No!" to the tag browser.



rel 0.8.7

Update metadata for 1500 books.

Tag browser closed.
<2 minutes, no memory leak.

Tag browser open.
> 1 hr, >200Mb memory leak
(And it was much worse before 0.8.7)

Who'd a thunk it?

[kiwidude]

Originally Posted by capnm

(Though I don't see why that should affect this and not Extract ISBN).

Perhaps this may give a hint to chaley/Kovid where the problem lies. Extract ISBN is affecting identifiers, whereas this plugin is affecting custom columns. Incidentially neither of these plugins has any interaction with the tag browser directly, not even a call to refresh. Extract ISBN probably should have a refresh call added to it (since there is a count of identifiers which may be affected) but the pages/word count columns are not visible so there is no need for this plugin.

So quite why the tag browser is having memory issues when the plugin is doing nothing with it is a mystery best left for chaley - perhaps it is listening to some events or something. As was mentioned previously both these plugins are deferring all database updates to the Calibre code that exists in edit_metadata.py which is called when the user finishes downloading metadata.

[chaley]

The only way I can account for this is if apply_metadata_changes (I assume that is what you call) is being called in a loop instead of once with a list of all the books. After it processes the given list, it calls finalize_apply which refreshes the tag browser. A series of 1-long lists will cause a series of refreshes to the tag browser as well as other things.

[kiwidude]

Nope, definitely only called once. And yes it is apply_metadata_changes I am calling.

[chaley]

Finally bit the bullet, intrumented calibre, and ran the plugin. The problem was with database notifications. set_metadata was not telling set_custom not to emit the notification, so the TB updated on each change.

Fixed.

[kiwidude]

Changes in this release:

• Preparation for deprecation for db.format_abspath() function in future Calibre for network backends

Internal change requried for future Calibre compatibility as discussed in this thread

[mbovenka]

Originally Posted by kiwidude

Changes in this release:

• Preparation for deprecation for db.format_abspath() function in future Calibre for network backends

Internal change requried for future Calibre compatibility as discussed in this thread

Small idea for the next version: recognize that PRC files are Mobis (in the ebook world anyway).