Unwanted sort by date

[DVdm]

Hi there...
When I open Calibre, there's a problem with the sort order.
My standard sort order is as follows:
==> Title, Series, Author, Read
The latter field is a customized date field to indicate if/when I have read the book. This way I have all the read books on top, followed by the non-read ones, sorted by Author, then by Series, then by Title.

Now, when I open Calibre, the books are ordered as follows:
==> Date, Series, Author, Read
This way, the non-read books are sorted by Author, then by Series, then by Date -- not by Title.

I somehow think this behaviour must have crept in with one of the recent versions, but I'm not sure.
Any tips on how to fix this? TIA.

[BetterRed]

Have a look at the Sort by tool, you'll probably need to add it to a toolbar or menu - I have it in the search bar.

It allows you to explicitly set and just as importantly see multiple column sort order settings.

BR

[DVdm]

Originally Posted by BetterRed

Have a look at the Sort by tool, you'll probably need to add it to a toolbar or menu - I have it in the search bar.

It allows you to explicitly set and just as importantly see multiple column sort order settings.

BR

Yes, I already use that.
But I have just now solved it by explicitly tweaking the sort at startup setting from
sort_columns_at_startup = None
to
sort_columns_at_startup = [['#read', 1], ['authors', 0], ['series', 0], ['title', 0]]
This used to be not necessary. Now it seems to be...

[theducks]

Originally Posted by DVdm

Yes, I already use that.
But I have just now solved it by explicitly tweaking the sort at startup setting from
sort_columns_at_startup = None
to
sort_columns_at_startup = [['#read', 1], ['authors', 0], ['series', 0], ['title', 0]]
This used to be not necessary. Now it seems to be...

none is equivalent to the naturalsort order of the DB (I believe {id})
Anything done that affects the overall Library (like a repair-rebuild) can result in a new ID. Date remains as the dater the entry was made initially (unless tampered with)

Read as a sort make little sense with the preceding sort. (#read can be a FILTER)
As a matter, your whole sort is odd. SORT is about arranging mutually Exclusive values, with levels, breaking ties.

Series has series_index to refine the order (title)
You can't sort by Title And Index. They usually are exclusive (Unless it was the Alphabet Murders. A was 1, Y was 25)

And using Authors as an Overall, also fails if your Library has shared universe type series.

[DVdm]

Originally Posted by theducks

...Read as a sort make little sense with the preceding sort. (#read can be a FILTER)
As a matter, your whole sort is odd...

Well, what I really want, is all the books that I have read, sorted by read date, most recent on top. All the other books, that I haven't read yet, I want below the read ones, sorted by author, then by series, and finally (the ones that a not part of a series), by title.
Makes perfect sense for me

[theducks]

Originally Posted by DVdm

Well, what I really want, is all the books that I have read, sorted by read date, most recent on top. All the other books, that I haven't read yet, I want below the read ones, sorted by autor, then by series, and finally (the ones that a not part of a series), by title.
Makes perfect sense for me

Any of those are valid BY THEMSELVES
I have 2 VL (have Read and To Read) (they are filtered views)

I use tri-state fields: If {#read} is false, It is in the To Read VL (and the flip)
I can sort Have Read by date in {#read} (or any other way)
sorts have bias from previous sorts
You do things to establish the Bias before the final sort.
So, if I sort on have read, then by Author, those should list the AUTHORS books in finished order. Any other sort between those will risk disturbing the bias.

[BetterRed]

Originally Posted by DVdm

Yes, I already use that.
But I have just now solved it by explicitly tweaking the sort at startup setting from
sort_columns_at_startup = None
to
sort_columns_at_startup = [['#read', 1], ['authors', 0], ['series', 0], ['title', 0]]
This used to be not necessary. Now it seems to be...

I 'dodge the bullet' by using the optional View Manager (VM) plugin.

A few years ago, following some changes to VM, the built-in Date/timestamp(date) column injected itself into it's sort process - uninvited. The PI developer who made the changes offered an unconvincing explanation why it was so. As a consequence I didn't upgrade VM for a while.

I did tests every few months in calibre portable and after a couple of years it was fixed, I don't know if that was due to further changes to VM or changes in the calibre core.

BR

[DVdm]

Originally Posted by BetterRed

...A few years ago, following some changes to VM, the built-in Date/timestamp(date) column injected itself into it's sort process - uninvited.BR

I suspect it reinjected itself a few versions ago