|
The metadata.db in Dropbox seems to be identical to the one in my Android phone and my Android tablet (Samsung). It fails in my tablet for the same Calibre library too.
Y maintain two other Calibre libraries (all with the same procedures) and it fails only with one of them (in both devices, phone and tablet).
I have one conjecture:
- CC maintains one local copy of metadata.db in the device (say, in the phone)
- CC compares the local copy with the one in Dropbox to decide whether it should update its local copy. For that purpose it first reads the local metadata.db, then downloads the one in the Dropbox server.
- imagine the Dropbox metadata.db is corrupted when downloaded by CC. Because, for instance, it is being just then updated by Dropbox from the Calibre metadata.db in my laptop.
- the next time CC tries to compare its local copy with the one in the Dropbox server, it finds its local copy corrupted. And this is what CC notifies. ¿Could the CC local metadata.db (in the phone) be the guilty? ¿Even if the metadata.db in the server is correct (correctly reconstructed by Calibre in my computer and correctly copied by Dropbox into his server)?
Knowing the decision procedure CC uses to decide whether is should download the metadata.db from the Dropbox server and what exactly the notification "missing or corrupted" means (to which metadata.db it refers to) should clarify is this conjecture is sensible or not.
Could'nt it be a CC bug if the metadata.db instances in my computer and in the Dropbox server are identical? It probably is, I would think.
|