Beta testers for calibre 9 needed

[Comfy.n]

When I last checked, before reverting temporarily to 8.16.2, the value of built-in pages column wasn't present in the metadata.opf inside book folders.

[theducks]

Originally Posted by JSWolf

IMHO, the reason to store the calibre generated page number is if anyone has to restore the database, calibre won't have to recompute all the page numbers again. Anyone using a mechanical hard drive could find this process a bit slow if they have enough books.

@jon
And how many times have you needed to 'restore' a DB?

I think I have done it 2 times (my fault) in 15 years.
Considering many of us run early versions (source or beta),
I think that is a good reason to not just let it run normally.
I frequently see posters claiming they had / needed to 'start over' using add books. ??? I have no clue as to why their library got so bad. Not moving the sources off somewhere and just rerunning a add books that includes the original folders?

[Sirtel]

Originally Posted by theducks

I frequently see posters claiming they had / needed to 'start over' using add books. ??? I have no clue as to why their library got so bad.

The main reason is probably mucking around in library folders and manually moving/deleting files. Lots of people probably have no idea you shouldn't do that with calibre.

Another reason might be having your library on a cloud drive and accessing it from different computers.

And yet another reason might be failed or unsuccessful bulk operations. I've certainly run quite a lot of bulk actions on my whole library through the years. I've been lucky so far.

[theducks]

Originally Posted by Sirtel

The main reason is probably mucking around in library folders and manually moving/deleting files. Lots of people probably have no idea you shouldn't do that with calibre.

Another reason might be having your library on a cloud drive and accessing it from different computers.

And yet another reason might be failed or unsuccessful bulk operations. I've certainly run quite a lot of bulk actions on my whole library through the years. I've been lucky so far.

Those 'my fault' were bulk ops that exceeded the intended scope.
In my case, I restored from a backup that I had just done prior to a bulk op.

[ownedbycats]

Originally Posted by JSWolf

IMHO, the reason to store the calibre generated page number is if anyone has to restore the database, calibre won't have to recompute all the page numbers again. Anyone using a mechanical hard drive could find this process a bit slow if they have enough books.

Yeah, I keep my library on a spinning rust drive and calculating was a bit slow.

[theducks]

Originally Posted by ownedbycats

Yeah, I keep my library on a spinning rust drive and calculating was a bit slow.

My system is a hybrid. C: is a SSD with a 2T spinning rust Mounted in users/ (I sort of regret this decision)
Rarely do I need SPEED of random access (a plus with SSD) for most of my documents, so my Library is on rust and doing just fine.

[DNSB]

Originally Posted by kacir

It was explained to me that: the #pages column is a dynamicaly generated column and as such is not backed up in metadata.opf file (which was the main concern of mine) and that the existing books are not scanned unless you activate a bookshelf view (or somehow display the #pages column value). The newly added books are processed to determine the number of pages but that adds very little overhead. You can see for yourself: create a small library and activate the bookshelf view. You can see how quickly the books are processed as the bookshelf is displayed with proper book widths.

Minor nit is that while both column headers default to Pages, the #pages column lookup name is used by the Count Pages plugins. The column lookup name used by calibre is pages. You can use the #pages for the book width by switching to it as a custom column in the Bookshelf view preferences.

[Uncle Robin]

Originally Posted by DNSB

You can use the #pages for the book width by switching to it as a custom column in the Bookshelf view preferences.

Does this choice stick? I seem to have to select it every time I use bookshelf view, judging by the way the 'thickness' of the books changes when I do.

[JSWolf]

Originally Posted by Uncle Robin

Does this choice stick? I seem to have to select it every time I use bookshelf view, judging by the way the 'thickness' of the books changes when I do.

Yes it sticks.

[BetterRed]

Originally Posted by DNSB

Minor nit is that while both column headers default to Pages, the #pages column lookup name is used by the Count Pages plugin. The column lookup name used by calibre is pages. You can use the #pages for the book width by switching to it as a custom column in the Bookshelf view preferences.

Count Pages has no default columns. For each of the 5 metrics, the Customisation dialogue offers a drop down list of the floating point custom columns the user has defined.

The 'pages/Pages' column that the Book shelf view computes is not a custom column, it is stored in the new 'book_pages_links' database table:



IMO it should be hidden from the user like the other columns in that table. And this former DBA would have named the column 'spine_width/Spine width' and the table 'book_pages_data', and if he hadn't, Tracey from Audit would have told him to make it so

BR

[theducks]

Here is an odd one:
I had 1 really old W10 Dell PC that the graphics and viewer would not run (spin of death) above calibre 7.16
On a lark, I loaded 9.1 AND IT WORKS

[kovidgoyal]

Originally Posted by theducks

Here is an odd one:
I had 1 really old W10 Dell PC that the graphics and viewer would not run (spin of death) above calibre 7.16
On a lark, I loaded 9.1 AND IT WORKS

That's because GPU acceleration is off by default in calibre 9

[theducks]

Originally Posted by kovidgoyal

That's because GPU acceleration is off by default in calibre 9