Transferring ebook annotations to new Kindle

[jesscat]

I use Calibre primarily with my Kindle 2; I have 8-900 books (very few of them from Amazon) on it. Just got a Kindle 3, and I'm trying to figure out the optimal way to transfer my library to the new device.

The problem is that I don't want to transfer 800+ books over from Calibre and end up with it looking like I have 800 brand new unread books on my new Kindle. I want them to stay in the same "recently opened" order in which they're listed on my K2 - and I when I open an ebook, I want it to open to the location I last exited from. I also don't want to lose notes, annotations, bookmarks (though I have relatively few of those). This means somehow preserving my mpb files.

Is there any way to do this using Calibre? A way to somehow keep the mbp files associated with the ebook files? I suspect the answer is no, in which case does anyone have suggestions as to how best to accomplish this? The two methods I can think of are 1) Just copy over my K2 drive directly to the K3 (how would Calibre deal with this?), but that eliminates this opportunity to clean up the file structure, which now is a jumble of fn ln and ln, fn folders (because Calibre changed its folder naming sometime along the way, right?); or 2) Send books to K3 from Calibre, then manually transfer mbp files to K3 drive, making sure names are correct (very laborious!).

[kovidgoyal]

just copy the drive over (including the metadata.calibre file) and calibre should pick up the files just fine.

[jesscat]

Ok, yeah, thanks, I figured that would be the way to do it, and since folder names in the Calibre library don't matter, whether on the Kindle or on a hd, I'll just try to ignore the "messiness"...

BTW, am I right that at some point Calibre's folder naming protocol changed? On both my kindle and my computer hd(s), I have multiple folders for the same author, newer ones named using "ln, fn" and older ones named using "fn ln"... I try to keep up with these things but sometimes lose track.

[kovidgoyal]

no the folder naming didn't change, but the way calibre computed author sort values did. Since the folder names use author sort, that would cause this effect.

[chaley]

Originally Posted by jesscat

BTW, am I right that at some point Calibre's folder naming protocol changed? On both my kindle and my computer hd(s), I have multiple folders for the same author, newer ones named using "ln, fn" and older ones named using "fn ln"... I try to keep up with these things but sometimes lose track.

I am sort-of on topic here.

I have run into a relative of this problem several times.

Changing author or title metadata, or changing the folder path in device customization, can cause a book to be put in a different 'place' next time it is sent to the device. However, the original book is not deleted, so I now have two copies of the book on my reader. The result can be confusion over which copy I am actually reading. The work I am doing with using custom field metadata in folder paths exacerbates the problem, because there are more opportunities for metadata to change.

To help deal with this issue, I changed calibre's 'On Device' indicator to show the number of books it found on the device that match a given book in the library. One now can easily see the confusing cases (e.g., search for 'ondevice:book'), and can use the 'remove matching books from device' to get rid of any extra copies. During testing, I found a case where I had 4 copies of one book on my reader.

This change will appear be in 0.7.18

[theducks]

Originally Posted by chaley

I am sort-of on topic here.

I have run into a relative of this problem several times.

Changing author or title metadata, or changing the folder path in device customization, can cause a book to be put in a different 'place' next time it is sent to the device. However, the original book is not deleted, so I now have two copies of the book on my reader. The result can be confusion over which copy I am actually reading. The work I am doing with using custom field metadata in folder paths exacerbates the problem, because there are more opportunities for metadata to change.

To help deal with this issue, I changed calibre's 'On Device' indicator to show the number of books it found on the device that match a given book in the library. One now can easily see the confusing cases (e.g., search for 'ondevice:book'), and can use the 'remove matching books from device' to get rid of any extra copies. During testing, I found a case where I had 4 copies of one book on my reader.

This change will appear be in 0.7.18

Now you fix that

I just cleaned up many dozens of entries on my PEz (I have been tweaking the books with Sigil and sending updates to my device), some times scratching my south end trying to figur why my *fix* did not work....old version still in place.



Is the "on device" tweak, going to show us a "count" of how many places i a title was found?

[chaley]

Originally Posted by theducks

Is the "on device" tweak, going to show us a "count" of how many places i a title was found?

It shows the count of how many books on a device 'matched' a given book in the library.

"Oh", you say, "What does *that* mean?"

A book on the device and a book in the library match if any of the following are true:
1) title AND (author or author_sort) match (white space independent compare)
2) the books' UUID match. See below for some explanation.
3) the books' title and database id match.

Note for #2 and #3: When calibre creates a book in a library, it assigns it two identifiers. The first, the UUID, is intended to be unique across all books and calibre installations. The second, the database ID, is unique for a given library. Thus the UUID can be considered an exact match regardless of metadata. The database id is an imprecise match, because a totally different book in a different library could have the same application id.

The UUID will match if the *same book* that originated in a specific library was sent to the device. Note that 'same book' is not the same as 'same metadata' or 'same format'. The metadata can change completely. The only thing that matters is that the UUID hasn't changed.

The database id will match if the book in the current library with that database id has the same title as the book on the device. I thought that the probability of getting that far with books that do not match was sufficiently low to permit ignoring the authors.

Automatic metadata management plays a role here. It sets the UUID for matched books, so that changes downstream will still match.

In your case, you are tweaking and resending the same book, so the UUID should match no matter what you have done to the title and authors or other metadata. You will see a reasonably accurate count of books.

The count will not be trustworthy if you send the same book(s) from different libraries unless all copies of the book in question originated in the same library. My hope is that not many people do that. If you do, then my recommendation is that you follow the advice of Harry Nillson: 'Put the lime in the coconut, and call me in the morning.