Calibre 7.3/7.4 hangs during starting up

[chaley]

Originally Posted by kovidgoyal

Qt in general is not thread safe, but QImage is supposed to be, see https://doc.qt.io/qt-6/threads-modules.html

I read that as guaranteeing they are reentrant, not threadsafe. Also, loadFromData() seems to be the supposed problem, which might be different from "painting" into threads.

Coming to your patch, its hard to know if it actually fixes the issue or just changes timing. If we have identified QImage not being thread safe as the culprit, then I would rather remove QImage completely from the render thread if that can be done performantly. I will look at it when I have some time, feel free to experiment further yourself if you want to, I will post here when I start working on it.

I agree that it could merely be hiding the problem. But if so, it is doing a good job at it.

I suspect the safest solution is the one you referred to, using the thread to fetch the data from the disk cache but do no Qt ops on it. The cached data would be passed back to re_render() in the GUI via the update_item signal already there. Re_render() would convert & size the image, store it in the CoverCache, then trigger the item repaint(). This should take approximately the same number of CPU cycles as doing it in the render thread, and the queue system already there would prevent the UI from being blocked for noticable periods. As a side benefit, I think CoverCache would no longer need locking because it would run only on the GUI thread. I will look at this approach if/when I get the energy.

[chaley]

@kovid: I made progress today. I should have a trial implementation tomorrow.

[kovidgoyal]

Originally Posted by chaley

@kovid: I made progress today. I should have a trial implementation tomorrow.

Glad to hear it.

[chaley]

Originally Posted by kovidgoyal

Glad to hear it.

I did a PR for the proposed fix. I say "proposed" because it is possible (probable?) that I missed a case or did something in a way you won't want to maintain. I commented the code where I made assumptions about its behavior or to justify implementation choices.

I tested it with a 24,000 book library with covers. This library would hang 2 out of 3 times with the old code. No hangs with the new code. Of course this isn't proof, but that, code path analysis, and lock chain analysis combine well enough for be to say "fixed".

[chaley]

The fix is now in calibre source.

[MCBastos]

I have done some more testing. Things that *did not* solve the problem:
- Uninstalling the antivirus
- Disabling just about every third-party program from startup
- Updating the video driver (coincidentally, AMD has just offered a new version)
- Starting Calibre with the --ignore-plugins (well, it worked *once*, and then never again)

However, I noticed one peculiar thing that might give a hint to someone with a better understanding of the program innards: although Calibre itself becomes non-responsive when the issue hits, the window can still be moved or minimized... and when I do that, I find that the Calibre splash (the one that says "Starting up, please wait... Initializing user interface...") is still showing up, only moved to the background.

I also found that running
calibre --start-in-tray
works fine, no matter what layout has been used.

As I mentioned, I have no idea of how the innards of Calibre work... but it seems to me that the UI code hangs trying to draw the cover grid *if a specific part of the rest of the program has not yet been loaded.* Maybe it relies on a service that it's not yet available, or maybe it causes a racing condition, I don't know, I'm not much of a programmer.

Why does it work in Windows safe mode, then? Beats me. Maybe it just loads fast enough when there's less stuff using machine resources.

This is by no means a competent technical analysis; this is what in Portuguese is called a "palpite", which could be roughly translated to English as "uninformed guess."