Two-Way Calibre Sync: Discussion

[petrjahoda]

Hello to all justRead.app users who also use Calibre Sync.

Right now, I consider Calibre Sync to be at version 1.0: it only syncs books from Calibre to justRead.app. However, it's technically possible to make it two-way, meaning data could also sync from justRead.app back into Calibre. So I would like to make a Calibre Sync 2.0

Calibre has 15 standard columns, and users can also create custom columns (see screenshot). I'd like to know your opinions on two things:
1. Which columns should sync back to Calibre?
- from the standard columns, which ones make sense to update from justRead.app? (Rating seems like an obvious one to me)
- also, what custom columns are you currently using? These would need to be mapped manually, for example, #read_date in the screenshot.

2. How should the sync behavior work?
When should changes be pushed back to Calibre?
- Automatically, whenever you make a change (rate a book, close it, mark it as finished, etc.), and checking the Calibre server is online?
- Periodically, with a check every X minutes?
- Manually, triggered by the user?
- Or some combination of the above?

Any other ideas around this are also welcome.

I'm planning this feature for version 2.3, so I'd like to keep this discussion open for about a week. The goal is to build it the way users actually want it, not just based on how I think it should work.

[Zebedi]

I wouldn’t want to sync back to calibre, for me it’s a one way street so if 2 way sync is introduced I would like it to be an option to manually turn it on.

Custom columns I use are collections, last action and count pages. Standard columns Series and Tags are my most important after Author. Don’t really need to know about dates, rating or when I finished it.

[JSWolf]

If there is a two-way sync, I would like it to be a different program so no excess bloat for a feature that's a really bad idea.

[petrjahoda]

Two way sync does not make sense in a different program, as you need mapping of columns to something existing in a program in which you are reading the book.
So for justread.app, I think an opposite, that it is a great idea.

[lbrockmueller]

I also would prefer a manual sync back to Calibre. Less chance of accidentally messing up the Calibre library. There are no Calibre columns I'd need to sync back, but I do see a use case for tags and ratings. I very much would like to sync back custom columns of Read (#yesno), and Date Read (#date).

[Docuro]

Originally Posted by lbrockmueller

I also would prefer a manual sync back to Calibre. Less chance of accidentally messing up the Calibre library.

I fully agree!
Columns I prefer are the read/unread and the reading position and it would be great if the collections in calibre could sync to the collections in Justread (But I don’t know if this is a very complex feature).

[petrjahoda]

Hello and thank you for the response.
About those Collections... as I never used this feature in Calibre... what is it? Where can I find it in Calibre?
Because I even did not find any 'collections' in my Calibre installation, 9.6 version.

[JSWolf]

Originally Posted by petrjahoda

Hello and thank you for the response.
About those Collections... as I never used this feature in Calibre... what is it? Where can I find it in Calibre?
Because I even did not find any 'collections' in my Calibre installation, 9.6 version.

Collection are whatever column(s) you want them to be. You just have to configure the Reader's driver to use the column(s). But not all Readers can have calibre manage collections.

[petrjahoda]

AHA, thank you for clarifying.
That means this goes into that 'custom columns'
And by that it can be of course done by mapping existing collections from justread.app to a column named (for example) #collections in Calibre.

[pdurrant]

This thread (from 2018!) ,ight be of interest on custom columns, for an idea of what people (used) them for:

https://www.mobileread.com/forums/sh...d.php?t=294713

[pdurrant]

standard columns, as of calibre 9 are:

1. id
2. title
3. authors
4. timestamp
5. size
6. tags
7. last_modified
8. pubdate
9. series
10. publisher
11. formats
12. path
13. rating
14. languages
15. pages

IMO, only rating should be synced back to calibre if it's changed in justRead

Custom Columns:
I have the following custom columns:

1. #parts - Comma separate text, giving the individual names for omnibus editions
2. #sub - like series, but indicates a sub-series within a series.
3. #read - Yes if I've read it, No if I intend to read it.
4. #dateread - the date I finished reading it
5. #price - floating point, what I paid for it
6. #orig - the original format downloaded (like tags)
7. #shops - where I got the book (like tags)

IMO, only #read and #dateread should be synced back to calibre.

In short, only those values that shoudl be changed in justRead just by reading the book and rating it should be synced back to calibre. Other metadata should be unchanged.


I see that I'm missing one bit of metadat that other might find vital - current reading position and furthest reading position. I suspect that it might be worth supporting one or both of those in a custom calibre column.

I would rather have the syncing be a manual process too, I think. This is because the calibre server may not always be available, and trying to detect this in a way that does not cause delays sounds like a version 3 feature.

[pdurrant]

Originally Posted by pdurrant

Custom Columns:
I have the following custom columns:

1. #parts - Comma separate text, giving the individual names for omnibus editions
2. #sub - like series, but indicates a sub-series within a series.
3. #read - Yes if I've read it, No if I intend to read it.
4. #dateread - the date I finished reading it
5. #price - floating point, what I paid for it
6. #orig - the original format downloaded (like tags)
7. #shops - where I got the book (like tags)

I forgot to say that I actually use the tri-state of a calibre Boolean column. That is, it can be yes, no or not set.

I use yes for "I have finished reading this"
I use no for "I want to read this in the future"
I use not set for "I don't want to read this, but I want to keep it around for reference"

That way, I can pick a random book from the read==no section, and not get books I don't want to read as books (e.g. cookbooks).

So it would be really nice if justRead handled the "not set" state of my #read column too. But that may require a bit more reworking than it deserves. In which case, I'l like the sync back to calibre for the read state to only ever change the state to read==yes, and never set a state to read==no (As it doesn't really make sense for that to happen in a reading app.) That way, my calibre tri-state won't get overwritten with lots of read==no states.

[JSWolf]

Originally Posted by pdurrant

I see that I'm missing one bit of metadat that other might find vital - current reading position and furthest reading position. I suspect that it might be worth supporting one or both of those in a custom calibre column.

I would rather have the syncing be a manual process too, I think. This is because the calibre server may not always be available, and trying to detect this in a way that does not cause delays sounds like a version 3 feature.

If you have a Kobo and you use Kobo Utilities to download your reading position, you have three custom columns setup.

1. Percent Read (#percent)
2. Last Read Timestamp (#last)
3. Current Reading Location (#current)

Now if you also have Reading Goal installed in calibre, you have to have #last updated before #percent in order for Reading Goal to have pages read under the correct date. Will justRead be able to correctly fill in #current so all of these values can be sent back to a Kobo Reader if needed?

[pdurrant]

Originally Posted by JSWolf

If you have a Kobo and you use Kobo Utilities to download your reading position, you have three custom columns setup.

1. Percent Read (#percent)
2. Last Read Timestamp (#last)
3. Current Reading Location (#current)

Now if you also have Reading Goal installed in calibre, you have to have #last updated before #percent in order for Reading Goal to have pages read under the correct date. Will justRead be able to correctly fill in #current so all of these values can be sent back to a Kobo Reader if needed?

If those custom columns are already a 'standard' for people using Kobo ereaders, it would be very nice to support them in justRead. I'd be willing to add them, and I don't have a Kobo!

So count this as a +1 to supporting those columns.

[JSWolf]

Originally Posted by pdurrant

If those custom columns are already a 'standard' for people using Kobo ereaders, it would be very nice to support them in justRead. I'd be willing to add them, and I don't have a Kobo!

So count this as a +1 to supporting those columns.

You don't have to have those columns named that way. But in the configuration of Kobo Utilities is the name of what the columns are so I went with that and I think they are very appropriate names. But the information of those columns is the same for everyone using KU and a Kobo to track reading position. The hardest part (IMHO) is going to be figuring out the current reading location so it's correct.