Database trouble

[spacemaster]

Hi guys,
I would like to ask you for help. I have installed new calibre version recently (1.29) and since then every time I shut down my pc calibre won't open my library after rebooting.
When I start the calibre it opens but instead of loading my library with 1300+ books it just loads empty library. Plus it says it's the same library but doesn't load the books in it. It helped to load the database manually via Calibre->Library maintenance->Restore database but it takes hours.
Does anyone know any solutions or what to do? I am desperate.
Thanks

[theducks]

No books showing in the list, means that Metadata.db is missing from the current Library location.

Just where do you keep the Library?
What OS?

[spacemaster]

My library is located in D:/Books/Calibre and I'm using Windows 7. Already tried to install lower version of calibre but without any improvement. Now it seems it can't load the database at all.

[theducks]

Originally Posted by spacemaster

My library is located in D:/Books/Calibre and I'm using Windows 7. Already tried to install lower version of calibre but without any improvement. Now it seems it can't load the database at all.

Open the Library folder in (the folder) Explorer.
Do you see Author name folders?
Do you see metadata.db? (how big is it in MB?)

If those are there, your Calibre installation or configuration is probably corrupt (installing new/old versions does not change the configuration) or you have a Malware or rogue A/V problem.

Rename(prior to a possible delete) the Calibre configuration folder (this will also remove all settings)

This folder is in the users AppData (hidden by default)\Roaming

C:\users\<logon name>\AppData\Roaming\calibre <-rename

This will be recreated with Defaults the next time you start Calibre. You will be asked for the Location of the Library (if it is not already the default name and location) . In your case: Simply use the Create/Switch:Use Existing option to point to the location of your Library

[spacemaster]

Thanks for your help but I found that the problem was somewhere else. I used MegaSync to backup my ebook library to Mega servers but thanks to my stupidity it replaced the database file every time I reboot. This happened only if the database file was different then the last stored file and renamed the existing file. That caused calibre not to be able o load the database file because it's name was different then the calibre expected.
I'm sorry for wasting your time but thank you a lot for your help.

[theducks]

Thanks for getting back.

Yes! Leaving the Cloud replicate active on a Library while using Calibre has caused all sorts of problems.

What I don't quite understand, is why.
Calibre Library (metadata.db) is the NEWER file. The cloud copy is the Stale version and it should have not overwritten a newer version. That is not optimum behavior.

[spacemaster]

Well, I actually don't understand it either. I believe that syncing was set to be both ways but not sure why. In settings I made sure that it will only copy the changes to server but not from the server to my hard drive. Probably a bug in syncing client itself. Or maybe I set it up badly but that's unlikely as it was pretty straight forward set up.
Anyway, now I know what's the cause of my troubles so the only thing left is to come up with solution so I can keep backup of my library in cloud server.

[PeterT]

I wonder if a change in DST / est might have had an adverse effect and caused the unwanted copy?

[theducks]

Originally Posted by PeterT

I wonder if a change in DST / est might have had an adverse effect and caused the unwanted copy?

Good thinking
IMHO another reason for filesystems to use UTC and just display with the current offset (the DST just modifies the offset)

[BetterRed]

Originally Posted by theducks

IMHO another reason for filesystems to use UTC and just display with the current offset (the DST just modifies the offset)

Surely filesystems store dates as ticks since some starting date, from memory

NTFS - 64 bit integer, tick 100ns, start point 1601.
FATNN - 32bit integer, tick 2s, start point 1980.

I don't know what the other file systems use, google should be able to find

Its the OS that converts the ticks to clock time.

BR

[PeterT]

Originally Posted by BetterRed

Surely file systems store dates as ticks since some starting date, from memory

NTFS - 64 bit integer, tick 100ns, start point 1601.
FATNN - 32bit integer, tick 2s, start point 1980.

I don't know what the other file systems use, google should be able to find

Its the OS that converts the ticks to clock time.

BR

Its not so much what is stored, its how the file sync application interprets the date / time stamp.

[AnotherCat]

The Help file in the popular file syncing application FreeFileSync (which I use) describes in great detail how it handles all of the issues related to UTC, Local Time, and DST rollover, and the differences between NTFS and FAT as to how they handle File Time. Far too convoluted to try and describe in a post, so...

For much of that explanation the Help file refers to www.codeproject.com/KB/datetime/dstbugs.aspx (scroll a ways down to get to the UTC and DST rollover issues including how if not handled correctly confusion can occur in NTFS at rollover even though it uses UTC).

Happy reading .

EDIT: a little bit of elaboration for clarity

[BetterRed]

Originally Posted by PeterT

Its not so much what is stored, its how the file sync application interprets the date / time stamp.

I didn't think it would be necessary to quote theduck's post - corrected

I think have some code somewhere that harmonises FAT, HPFS, NTFS and NFS file system ticks to a lowest common resolution - I think its NFS ticks - it has methods to compare and convert one to the other. I wrote it about 20 years ago - for IBM!

BR