Kindle Scribe cover fix in 7.11 slows down startup

[RKrueger]

With Calibre 7.09 and 7.10, Calibre immediately connects to the Kindle Scribe and starts 3 jobs:

Get device information
Set library information
Get list of books on device

I have a lot of side-loaded books on my Scribe, so it can take up to an hour to complete the 3rd job (Get list of books on device) but it does provide progress feedback in the Jobs window.

However, with versions 7.11 and 7.12, Calibre doesn't start any jobs when the Scribe is connected. It apparently knows the device is attached and is doing something, but there is no feedback in the Jobs window. If I leave the program to sit for a few hours, it eventually works (and the cover fix works!) but this is less than ideal.

I wish a future version will work more like 7.10 and give feedback to the user about what is happening with the connection.

[kovidgoyal]

The cover fix requires scanning files on the device to restore thumbnails because amazon actively destroys thumbnails to make side loading less attractive. And because the Scribe is MTP based file scanning is extremely slow.

There is no way around this. Though a few hours seems extremely excessive. Presumably you either have a lot of book on your scribe or a lot of junk files in the systems/ folder.

[RKrueger]

Thanks for the quick response!

How would one eliminate junk files in the system folder?

[kovidgoyal]

Open it in windows explorer and look inside the system folder.

[OuyangZhu]

Originally Posted by kovidgoyal

Open it in windows explorer and look inside the system folder.

Hi, I am windows 11 and using calibre 7.12 to transfer sideloaded azw3 books into kindle scribe. However the cover bug did not fixed. I had see someone using macOS and calibre 7.12 to fix the cover bug in scribe. So I don't know if it is still a cover bug just in window 11.

[kovidgoyal]

The OS doesnt matter. Transferring covers works the same regardless. And remember as with any kindle you have to actually work around amazon destroying the covers deliberately. See the calibre faq for details: https://manual.calibre-ebook.com/faq...-generic-cover

[OuyangZhu]

Originally Posted by kovidgoyal

The OS doesnt matter. Transferring covers works the same regardless. And remember as with any kindle you have to actually work around amazon destroying the covers deliberately. See the calibre faq for details: https://manual.calibre-ebook.com/faq...-generic-cover

I had tried the way as you said. However it does not work either. Thank you any way.

[tomsem]

FWIW I do not think it is necessary any more to restore covers (on Kindles with the sync-system-time update).

I have tried everything I can think of to let it happen, and it just doesn't. I think update that delivered the system time synchronization feature was responsible for this change, and lack of time sync is/was responsible for flagging thumbnails as 'remove and try to update' as part of sync (consistent with use case of side loading AZW3 downloaded from Amazon, where it will sync any annotations, download X-ray info, cover thumbnail, etc).

So if there were some option to disable the extra work calibre does to restore thumbnails on Kindles, I would use it (older Kindles probably still need it, I'm guessing).

I also tried to reproduce @RKrueger's issue and could not, at least with as many as 350 books on the Scribe (I let it sit around to finish indexing content before testing). It never took longer than about a minute for calibre to finish its sync (including whatever the polling period is for checking for connected devices). And with my usual 20 or so on device, less than 30 seconds.

I don't consider this particularly slow compared to USB MS, which can take awhile just to mount on the file system (it takes less than 5 seconds for Scribe and Android devices to go into connected mode).

File transfers are also not slower and often faster when I have tested Scribe and compared it to Paperwhite w/USB-C.

Which is not to say I think the change to MTP was particularly merited or welcome.

[kovidgoyal]

There's no easy way to detect if its necessary or not, so I prefer to err on the side of caution. I also don't think the OP's numbers are normal. There is something else going on there. As such unless it is determined that the check + sync is actually slow for many people I would rather leave it in. I dont actually trust amazon not to bork it again even if it is currently not needed.

[tomsem]

Originally Posted by kovidgoyal

There's no easy way to detect if its necessary or not, so I prefer to err on the side of caution. I also don't think the OP's numbers are normal. There is something else going on there. As such unless it is determined that the check + sync is actually slow for many people I would rather leave it in. I dont actually trust amazon not to bork it again even if it is currently not needed.

Yes, agree there is 'something else going on' with slow sync. I thought I could repro it, but if it takes putting more than a few hundred books on device, then it is a tail I am not prepared to chase.

As for restoring thumbnails, no solid reason to take it out, just chalk it up to my OCD. I'm just frustrated I cannot get it to happen, even on my vintage Kindle Touch.

[tomsem]

Originally Posted by kovidgoyal

There's no easy way to detect if its necessary or not, so I prefer to err on the side of caution.

Updates leave 'breadcrumbs' unless they are explicitly deleted. So it is possible to tune behavior by looking for them. Maybe useful for some situations.

[DNSB]

Originally Posted by tomsem

Updates leave 'breadcrumbs' unless they are explicitly deleted. So it is possible to tune behavior by looking for them. Maybe useful for some situations.

Those look like MacOS resource fork files so not likely to be created unless someone is using MacOS to access their Kindle.

[tomsem]

Originally Posted by DNSB

Those look like MacOS resource fork files so not likely to be created unless someone is using MacOS to access their Kindle.

That listing was from my Paperwhite, not Scribe.

My Scribe has the update breadcrumbs too, and it's not possible for macOS to create them, as it knows nothing about MTP.

There may be some question as to whether OTA updates leave them behind. But why wouldn't they? The update executes the same on device using Kindle OS, whether downloaded or side loaded.

[DNSB]

Why I was thinking of MacOS resource fork files is that my Paperwhite does not have them so I doubt that they are from the Kindle OS.

I just tested with 5.16.9 by copying the update file from a MacOS virtual machines. After the update, the update_kindle_all_new_paperwhite_v2_5.16.9.bin update file was not present but ._update_kindle_all_new_paperwhite_v2_5.16.9.bin was present and it was the only file of that type that was present. So I will have to say that if you are manually copying the firmware update files to your Kindle from a MacOS computer, those resource fork files will be left behind.

[tomsem]

Finally I get it. Duh.

Well, one nice thing about MTP is that macOS can no longer leave these turds on Scribe. You cannot miss seeing them with an MTP browser.