edit book app "hangs" during edit session
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
calibre |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Symptom:
During an edit session with a lot of edit actions, a lot of open page TAB's (>10) and not that many regularly save actions, the edit-book app sometimes becomes at a given moment non-responsive (also indicated as such by Win7) and seems in general to "hang". However, most of the time, after a long waiting period (up to 10 minutes is possible) the edit-book app becomes active again. It is then necessary to immediately perform a save otherwise a new "hang" period is very possible. It also helps to close as many open file TAB's as possible to regain a responsive app again.
System:
I'm using calibre 1.34, a regular up-to-date Windows 7 machine quad-core, 4GiB RAM, ample data disk space (separate, real disk drive) and no other application active than a browser (FF). Virus checker ignores calibre.
Used sources:
I've seen this in the recent past a couple of times with some relatively large EPUBS (~2MiB), containing many images or almost none, with or without stylesheets and the files could be either well-formed or totally trash (needing cleanup). Current issue was caused by ugly looking (in view mode) epub, comprising just 2 text files (1 cover file, 1 large text file ~2MiB), a few images and no stylesheet. Calibre check book function just reported 1 non-referenced image, no other issues then text file too large.
Activity involved:
Epub is present in calibre database. Select involved epub and open via edit book function. Select and open large text file. Text visible in preview screen. Replaced with regex specific <p></p> tags into <h1></h1> tags for chapter generation (source file did not had any chapters nor table of contents entries. Generated first rough table of contents and saved epub without leaving edit. Added a very simple stylesheet with h1 setting. Used Find function to repeatedly search for <h1> tags. Used then preview window to split text file on every chapter boundary. During split a short "busy" icon is visible, a new text file is visible in file browser pane and new file TAB is created for the remainder of the text file. After about 10 splits (sometimes more) without saving, the "busy" icon remains active and the edit book app becomes non-responsive for long time (up to 10 minutes is possible). However, up to now, the edit book app always is able to recover in the end and to continue. It is however wise to save now immediately and remove all but the last file TAB to safely continue without a new "hang" situation. Forgetting this and a new non-responsive waiting time starts.
The "hang" situation has sometimes also occurred during other edit intensive situations as adding/ replacing/ renaming tags and such without regularly saving.