Beta testers for calibre 9 needed

[un_pogaz]

Originally Posted by DNSB

Odd. A custom column with it's lookup/search name starting with # (i.e. Pages/#pages) does not seem to cause any issues with the Pages/pages used by calibre.

Can you point to an example of where you are seeing an issue?

The main issue was that user cannot create column with a header alreday used. Something I understand, which is why I suggested removing this limitation, a suggestion that was accepted in the master (but still not in the Beta binary)

Originally Posted by JimmXinu

A warning for Calibre Sync users: Calibre Sync is incompatible with Calibre 9's library changes.

Their is absolutly zero incompatible Calibre 8 and 9s library. The new column is added, even on library that have a column with a hedear "Pages" and no data is lost or overwrite.

Originally Posted by BetterRed

I see an issue when the user is presented with list of Column header values which are not unique, from which they must make selection. Here's a couple:

gridview field under cover
Attachment 220258

view manager
Attachment 220259

I have no idea which "Pages" is which.

And, when version 9 is released if I was daft enough to add a custom column with a Column header value of "Publisher" I wouldn't know which "Publisher" was which either.

BR

Inded, that why I make a other a PR on calibre to use a extended format "Heading (name)" here too.
If there are other places like this in Calibre, thanks to report them so that will can changed too. But there will undoubtedly be somes places where an extended format will not be accepted.

Else, for View Manager, that a issue to report to kiwidude, because it is plugin.

I agre that is the kind of confusion that can happen when using a already used heading, and only show them for for column selection,
BUT, saddly, it's not issues serious enough to warrant renaming the Calibre Pages in something else.
It annoying and confusion, but that all. This may require some effort from the user part, but not that much. Like @DNSB suggest, rename the confusing column, even temporay, if you want manipulate confusing colmun based on their header.

Calibre developement cannot be retstricted of the use of a header on the principe that a user could already use it. Even in the case of a "often common" custom column name like "Pages".

[theducks]

I think you keep missing the point that for custom columns Pages is a LABEL and can be changed at any time. It is the #xyz part that is the real name.
(Some of mine have been relabeled 3+ times as their usage evolved. The data remained intact)

As long as there is Custom columns, there WILL be Title clashes at some time. The brilliance of how custom columns was structured proves how robust and flexible it is. My first post on retitling took me all of 20 seconds. The only fallout is all the books metadata were marked with a new Last_Modified date. Nothing got broken.

[PeterT]

Originally Posted by JimmXinu

A warning for Calibre Sync users: Calibre Sync is incompatible with Calibre 9's library changes.



My phone shows Calibre Sync last updated 2025-Apr-1.

Just curious; which mode of connection to calibre was this tested with? This morning I tried using Calibre Sync to connect to calibre via Calibre Content Server with no issue.

I sense that this error will only occur with any of the Calibre Sync file sharing based library setups directly accessing the calibre database

Sent from my TB350FU using Tapatalk

[JimmXinu]

Originally Posted by PeterT

Just curious; which mode of connection to calibre was this tested with? This morning I tried using Calibre Sync to connect to calibre via Calibre Content Server with no issue.

I sense that this error will only occur with any of the Calibre Sync file sharing based library setups directly accessing the calibre database

I agree. That's what I use and I didn't think about Content Server.

The original report from dunhill shows the failure on a direct SQL query.

And Kovid's reply flat out states that the isbn column is removed in Calibre 9. Presumably it's been in Identifiers instead for ages.

[un_pogaz]

Yes, thanks @theducks

[JSWolf]

Originally Posted by DNSB

Odd. A custom column with it's lookup/search name starting with # (i.e. Pages/#pages) does not seem to cause any issues with the Pages/pages used by calibre.

Can you point to an example of where you are seeing an issue?

If you look at post #279, you'll see that the issue has been fixed since I posted about it.

[JSWolf]

Originally Posted by JimmXinu

A warning for Calibre Sync users: Calibre Sync is incompatible with Calibre 9's library changes.

My phone shows Calibre Sync last updated 2025-Apr-1.

Originally Posted by kovidgoyal

It will be because the isbn, lccn and flags columns have been deleted from the calibre books table in calibre 9 (they were never used for anything and just tkae up unneccessary disk space). The developer of Calibre Sync should update his SQL query to exclude those columns.

An easier thing to do is to put in Calibre's Sync's directions to create the columns needed and what names to use.

[JSWolf]

Originally Posted by Terisa de morgan

Thank you, so I'll stay on calibre 8 in the meantime.

Why not create the columns needed?

[Terisa de morgan]

Originally Posted by PeterT

Just curious; which mode of connection to calibre was this tested with? This morning I tried using Calibre Sync to connect to calibre via Calibre Content Server with no issue.

I sense that this error will only occur with any of the Calibre Sync file sharing based library setups directly accessing the calibre database

Sent from my TB350FU using Tapatalk

Yes, that's the method I use (OneDrive sync), and it's faster (and practical) for me than Content Server.

[Terisa de morgan]

Originally Posted by JSWolf

Why not create the columns needed?

Why am I going to creat some colums that are not useful? It doesn't make sense to me.

[un_pogaz]

@JSWolf I think that @Terisa talk of a other kind of issue: Calibre Sync is incompatible with Calibre 9's library, but is not a issue with Calibre itself, but a third-party sofware.

I suppose that Calibre Sync don't work on because of the add of the Calibre Pages and also some others change on the DB. Wich inded, it better to wait that Calibre Sync update to support the new DB format before update Calibre itself.

[DNSB]

Originally Posted by JSWolf

If you look at post #279, you'll see that the issue has been fixed since I posted about it.

Umm... Jon, I had Pages/#pages from using the Count Pages plugin. When I updated to the calibre beta and the Pages/pages builtin column was added, I did not see any conflict between the two Pages column since they had different lookup names. The only issue was with the mark 1 eyeball which only saws the column heading.

What Kovid did in the change was to allow you to create/rename custom columns with duplicated column headings but the lookup name is still required to be unique.

[ownedbycats]

I installled beta. Prexisting column named Pages (#pagecount). I tried to set the width in look & feel but didnt know which is which. Adding lookup name would help.

[ownedbycats]

There's only Calibre Pages on the Sort By menu, so I have to switch to table-view to sort by that.

Additionally, with my custom #pages column, for some reason every book over 1000 pages is exact same width, and notably thinner than a 997-page book.

option to set priority on initial page-count indexing would be nice

[BetterRed]

Originally Posted by DNSB

Simple answer would be to rename the column with lookup name #pages to some other name. CP_Pages? Page Count? After all, the name does not really matter, it's the lookup name that is the real identifier.

So, its better that thousands of users change the "Column Header" value on their "#pages" custom columns, rather than one developer change the "Column Header" value on the "pages" built-in column

Originally Posted by DNSB

Would you disregard the warning that you are about create a column with the same heading/name as an existing column?

I might if I was daft enough to have previously unchecked "Show this confirmation again".

Why would anyone want introduce a custom column with the same Column header value as a built in column's Column Header value — other than "Because you can".

Rather than allowing that, IMO it would have been better to allow users to change Column header value for built-in columns - e.g

Date Added for timestamp,
MD Updated for modified_date
Shelf Space for pages

BR