Quote:
Originally Posted by DavidTC
The problem *there* is, as I said back where I started with all this, my original suggestion #1: This requires keeping two copies of everything on the device, which is why I asked for the ability to 'download' a book by just pointing the record at the existing file, instead of making a copy. This method also, from what I understand now, won't correctly get calculated fields.
|
Bottom line: I am not going to change CC to use book files in a local cloud library. It is complicated, could easily break several internal assumptions, and isn't much in demand.
Quote:
So let me summarize what I am thinking *now* about adding books from the cloud:
1) Currently, CC ends up having to use a mix of metadata.db and internal book metadata, and can *still* get it wrong when getting it from a cloud connection. (Right? If I understand correctly, calculated fields are only in the book metadata, so won't be there usually.)
|
No. CC does not use internal book metadata unless you use "scan on connect" with the wireless device. The cloud connection never uses internal metadata.
Quote:
|
2) The internal book metadata *is* correct (For books that Calibre supports) after Send to Device books.
|
And only for book formats that support arbitrary metadata, such as epub. Mobi does not.
Quote:
|
3) Also CC does needs metadata.db to exist (Even if it is incomplete in some fields), so it can download that to show a listing of books from the cloud.
|
And get the metadata for the books.
Quote:
4) But there is also a metadata 'database' that follows 'Send to Device' folders around, called metadata.calibre. This appears to be...not actually a database, but instead a text file with all that information. In fact, looking at it, it has information that even metadata.db doesn't have, including calculated fields! (Which also nicely solves the problem of non-supported metadata files!)
So let me pause here and make a suggestion:
Perhaps the problem with cloud libraries is that CC is only supporting *the wrong type of cloud*. CC supports putting the entire library up there *as is*, with wrong metadata and everything.
However, it is almost as easy for people to put books in the cloud using 'Send to Device' folder in the cloud concept.
This would require CC to read metadata.calibre to show books, in addition to metadata.db.
[...]
|
Bearing in mind that I am not going to change how CC stores books ...
I am not sure what problem your new sync type solves. As far as I can tell it adds complexity without adding significant benefit. The only thing it has over the standard cloud connection is that is has values for composite columns (computed columns). But to get these values the user must manually export their library (making a copy of all books), sync that exported copy with the device, then import that copy into CC. If you don't use composite columns then the existing cloud connection does all of that with no data loss and without the fuss. The wireless device connection does it all, albeit on a device-by-device basis.
In addition, you appear to be solving a problem that almost no one has.
- Most people don't keep their entire library on their device, or if they do then they have small libraries. I am now getting numbers. At the moment:
- 1-20 books: 23%
- 21-50: 28%
- 51-100: 7%
- 101-250: 2%
- 251-500: 11%
- 501-1000: 11%
- 1001-2500: 16%
- 2501-: 2%
We see that 60% have library sizes of 250 books or less.
- Most people don't use the cloud connection. At the moment:
- Wireless device: 52%
Content server: 24%
Cloud connection: 24% (Dropbox: 12%, Google Drive: 8%, Microsoft Onedrive: 4%)
- Most users have only one device. According to the stats, each user has 1.15 devices.
- Anecdotal but I think true: most people don't use composite columns (computed columns), so even for people who do use the cloud connection the lack of their value in the cloud database doesn't affect them.
On the other hand, several people have asked that we support importing books sent over a cabled connection, which is a use case similar to what you are describing. I have had this on my "look at" list for some time. Perhaps the right time is approaching.