[GUI Plugin] calibre Auto-Updater

[dunhill]

Originally Posted by kovidgoyal

@dunhill: Note that on Windows shutdown running calibre is not sufficient it can leave viewer and edit windows around. There is no general method for shutting them down. You would need to use something like psutil to search for the processes and kill them and running shutdown running calibre.

@kovidgoyal,
Thank you very much for the technical tip regarding Windows child processes. Following your advice, I've updated the plugin to version 1.2.1.
Now, before launching the installer, the plugin uses taskkill to clean up any remaining instances of ebook-viewer.exe, ebook-edit.exe, and calibre-parallel.exe. This ensures the .msi installer doesn't run into "files in use" errors. I've also kept the --shutdown-running-calibre command to ensure the database closes gracefully first.
Thanks for keeping an eye on this!
I'm learning a lot from the comments.

[dunhill]

Originally Posted by JSWolf

One thing. If after doing the shutdown, are you are then waiting a specific time before starting the install? If so, what what about the varying time it can take to do the config backup with the backup plug-in?

@JSWolf,
That’s a very sharp observation. You are absolutely right—background tasks like the "Backup Default Settings" plugin or library metadata flushing need time to finish before the installer starts.
To address this, I've implemented a Smart Wait Loop in version 1.2.1. Instead of a fixed delay, the plugin now actively monitors the system process list and waits until calibre.exe has completely disappeared before proceeding. This way, any pending I/O or backup operations can finish safely.
Thanks for helping me make the plugin more robust!

[dunhill]

Originally Posted by Terisa de morgan

Thank you, it has worked for me now. I haven't checked the download folder change because I've updated before, but I'll do the next time. And thank you for the plugin, it simplifies the update.

@Terisa de Morgan,
You're very welcome! Actually, the option to change the download folder was a suggestion from @JSWolf.
After carefully analyzing the situation, I realized it was a great point and a very useful feature for those who like to keep their files organized. I always try to listen to suggestions to make the plugin as useful as possible for everyone, within the technical possibilities.
Glad it’s working well for you now!

[dunhill]

v1.2.1:

Improved Process Management (Windows): Based on feedback from @kovidgoyal, the plugin now proactively terminates child processes (ebook-viewer.exe, ebook-edit.exe, etc.) before launching the installer to prevent "file in use" errors.
Smart Wait Loop (Windows): Following @JSWolf's observation, I've implemented a monitoring loop that waits for calibre to fully release all database locks and background tasks (like metadata flushing or settings backups) before starting the update.
Enhanced Linux Experience: Better terminal handling for the restart process. The plugin now uses disown to ensure calibre restarts seamlessly after the update is finished.
Internationalization: Added full translations for French and Brazilian Portuguese.
Special thanks to the community members for their technical insights and testing!

[BetterRed]

Originally Posted by dunhill

Exactly. The plugin checks the OS but relies on the user having a standard installation. I've added a clear warning in the confirmation dialog stating that Portable, Flatpak, and AppImage versions are not supported and must be updated manually.

Since those versions don't follow the standard Windows Registry paths for the .msi installer, trying to automate them would lead to the 'Retry/Ignore' errors you mentioned. Keeping it restricted to official standard installs is the safest way to avoid corrupting a user's setup.

Please read what I actually wrote; it's about what is running when the msi installer is started, nothing to do with installing portable itself.

I've attached some screenshots - the executables that the portable launchers start are identical to the installed calibre executables, the difference is that they're loaded from a different location and some variables are set to precondition the execution environment.

I have no idea if that is relevant to your plugin. Knowing you don't use Windows, I wanted to make sure that you were aware that the msi installer will not run to completion if any of the calibre executables are running from a portable install.

Added: Perhaps you're not aware that 'installed calibre' and multiple copies of 'calibre portable' can coexist on the same Windows system.

BR

[JSWolf]

Originally Posted by dunhill

@JSWolf,
That’s a very sharp observation. You are absolutely right—background tasks like the "Backup Default Settings" plugin or library metadata flushing need time to finish before the installer starts.
To address this, I've implemented a Smart Wait Loop in version 1.2.1. Instead of a fixed delay, the plugin now actively monitors the system process list and waits until calibre.exe has completely disappeared before proceeding. This way, any pending I/O or backup operations can finish safely.
Thanks for helping me make the plugin more robust!

Happy to help.

[dunhill]

Originally Posted by BetterRed

Please read what I actually wrote; it's about what is running when the msi installer is started, nothing to do with installing portable itself.

I've attached some screenshots - the executables that the portable launchers start are identical to the installed calibre executables, the difference is that they're loaded from a different location and some variables are set to precondition the execution environment.

I have no idea if that is relevant to your plugin. Knowing you don't use Windows, I wanted to make sure that you were aware that the msi installer will not run to completion if any of the calibre executables are running from a portable install.

Added: Perhaps you're not aware that 'installed calibre' and multiple copies of 'calibre portable' can coexist on the same Windows system.

BR

@BetterRed,

Thank you for the detailed explanation and the screenshots! I now see exactly what you mean: since the executables share the same names regardless of their location, the MSI installer will trigger a conflict if any of them are active.
Even though I'm on Linux, the plugin's logic for Windows actually accounts for this. It uses image name filtering (e.g., taskkill /IM calibre-parallel.exe) rather than specific file paths.
This means that even if a user is running a Portable version from a different drive, the plugin will detect those processes by name, attempt to close them, and wait for them to disappear before launching the MSI.
So, thanks to your observation, I can confirm that version 1.2.1 is safer than ever!