FBReader thinks no books are downloaded after 3.1.1 update

[AlanRoberts]

Background: Calibre running on a home network, serving eBooks to family members' tablets. Prior version was 2.85.1, always running on a Win7 virtual machine that is hosted on a QNAP NAS. Clients are Android tablets running FBReader, with the content server added as an OPDS catalog. The content server is set to use a Virtual Library (Preferences | Sharing over the net | Virtual library to apply) for convenience to filter out foreign-language titles that were included in some large eBook collections I've purchased and eBook conversions that were badly mangled, where I want to attempt to clean up before serving the book.

The use pattern from the clients is to navigate within FBReader to Calibre's OPDS catalog, select "By Newest", then download anything of interest from the titles not-yet-downloaded (FBReader has a simple graphic indication of downloaded versus not).

I ran the 3.1.1 upgrade, restarted Calibre, and everything looked successful until I switched to a tablet, brought up FBRreader, and checked Calibre's catalog. The tablet is now indicating that all the books in the catalog need to be downloaded. Somehow it has lost synchronization with what has already been pulled down to the tablet's storage.

This would have been "epic failure" for the non-computer-literate family members who use my library, so I uttered a quick prayer to the upgrade rollback gods, uninstalled 3.1.1, and reinstalled 2.85.1. Everything came back, preferences, my fumbling attempt to build a custom news source, and best of all, the tablets regained synchronization with what they had already downloaded from the catalog! I've seen plenty of software over the years where rolling back ranged from painful to impossible, so many thanks for not breaking anything with this one!

I'll admit to being clueless about the internals of OPDS ... It has always just worked for me since I started using Calibre. I suppose I assumed that the catalog must present *something* robust for each title (i.e., a content hash, or GUID that the server would change on any server-side modification), so a client could detect new/different content from anything locally stored??? Regardless of how it actually works, things went wrong for me with the upgrade.

Can anyone who does understand this stuff tell me how I can correct things so I can reapply the update?

Thanks,
Alan

[kovidgoyal]

The OPDS feed from calibre includes a UUID (universaly unique ID) for all books. My guess is that FBReader does not actually use it to identify books, but instead uses the URL (which changed because the server now supports multiple libraries ina single instance).

Nothing calibre can do about that. You will need to contact FBReader to confirm my theory.

[AlanRoberts]

Originally Posted by kovidgoyal

The OPDS feed from calibre includes a UUID (universaly unique ID) for all books. My guess is that FBReader does not actually use it ... You will need to contact FBReader to confirm my theory.

Thanks. I'll see if I can find a place to log an inquiry with FBReader, and hold at Calibre 2.85.1

For my store in knowledge, if I use Calibre to make an edit to a title (metatdata change, content cleanup, etc), is the UUID replaced with a new value? That is, does it provide a consistent means for a client to detect change?

Cheers,
Alan

[kovidgoyal]

uuids are never changed. Even when you copy a book to a different library (assuming you use delete after copy) the uuid remains unchanged.

[AlanRoberts]

Originally Posted by kovidgoyal

uuids are never changed. Even when you copy a book to a different library (assuming you use delete after copy) the uuid remains unchanged.

Okay. If the FBReader developers are interested in addressing this issue, they would need to capture UUID and something else (the <updated> tag?) when an eBook is downloaded, so they could reliably determine if a new title needed to be downloaded or an existing local title replaced with an updated download?

Thanks,
Alan

[kovidgoyal]

Every book entry has a last modified timestamp in <updated> that tells when the metadata for that entry was last changed. And every download link for a book file has both size and mtime information to tell when to re-download a aprticular file.

[chaley]

Originally Posted by AlanRoberts

Okay. If the FBReader developers are interested in addressing this issue, they would need to capture UUID and something else (the <updated> tag?) when an eBook is downloaded, so they could reliably determine if a new title needed to be downloaded or an existing local title replaced with an updated download?

Thanks,
Alan

FWIW: The Calibre Companion wireless device driver handles these cases: book-on-device, changing metadata and changing books. Books are marked as on-device in calibre when CC connects. In the changing metadata case CC downloads the new metadata when it connects to calibre. In the updated book case one must set a CC option that causes CC+calibre to compare the modification time of the books in CC's library to calibre's library. Book "formats" (epub etc) newer in calibre are automatically downloaded to CC.

CC also uses the UUID to check for on-device in all three of its connections: wireless device, content server, and cloud.

One downside: CC replaces FBReader as the library manager. CC can use FBReader as the reading app.

If you have questions about CC, post them on the CC forum.

[Fiat_Lux]

Originally Posted by AlanRoberts

Thanks. I'll see if I can find a place to log an inquiry with FBReader, and hold at Calibre 2.85.1

Does FBReader ever respond to user submitted questions, or bug reports?

I posted one around three months ago on the only place on their site that I could find, for submitting issues, and haven't received any response.

Amber