eBook viewer slow to open when recent disk resource unavailable

Bug #1669497 reported by Jeff Rife
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Fix Released
Undecided
Unassigned

Bug Description

In Calibre 2.80 on Windows x64:

1. Configure Calibre eBook Viewer is set to remember recently opened files.
2. Browse to a UNC network path or a removable device that contains an eBook that Calibre can open.
3. Open the file in the Calibre eBook viewer.
4. Close the file.
5. In some way, disable the UNC network path so that it is not available, or remove the removable device.
6. Attempt to open an eBook on a local drive using the Calibre eBook Viewer, and notice the file opens very slowly.
7. Close the eBook viewer.
8. Repeat step 6 to show that caching the book doesn't help.
9. Close the eBook viewer.
10. Open the eBook Viewer with no file using the Start Menu shortcut, and it is still slow, showing it's not an issue with the eBook being opened.
10. Restore access to the UNC network path or insert the removable device, and repeat step 6, and now access time is normal.

This can be worked around by either clearing the list of recently opened files, or configuring the viewer not to remember recent files.

Revision history for this message
Kovid Goyal (kovid) wrote : Re: calibre bug 1669497

I cannot replicate this, steps I tried:

1) Create folder
2) Put an epub file into it
3) Open the EPUB file in the viewer
4) Close viewer
5) Delete folder
6) Open some other EPUB file -- it opens as fast as always

The only thing that calibre does when building the list of recent files
is check if they still exist, so that it can exclude entries that dont
exist anymore. Presumably, whatever network fs technology you are
using makes checking for file existence very slow when the network goes
away. That is one of (the very many) problems with networked
filesystems.

I could have the viewer not do the check, but that simply penalizes all
users of calibre to workaround problems in a fundamentally broken
technology (networked filesystems) used by a small fraction of the
userbase, not a worthwhile tradeoff, in my opinion.

 status wontfix

Changed in calibre:
status: New → Won't Fix
Revision history for this message
Kovid Goyal (kovid) wrote :

On second thoughts, a nice compromise is to only build that menu when
the user actually tries to open it. That way startup times are not
affected.

Revision history for this message
Kovid Goyal (kovid) wrote : Fixed in master

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased

Changed in calibre:
status: Won't Fix → Fix Released
Revision history for this message
Jeff Rife (g-uduntu-5) wrote :

Thanks for the smart fix.

The problem is absolutely a Windows issue. It's not as bad with a removable device that's gone, but the unchangeable timeouts on Windows networking are just stupid. In particular, when a machine sharing resources isn't there at all (the DNS name might not even resolve), there should be a much quicker timeout than the nearly 30 seconds that is the default.

My problem came from storing backups on a VM that doesn't always run, and I recently opened a file from it to compare to the live Calibre version.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.