Version mismatch after latest update

[simkoG]

qBittorrent & operating system versions

qBittorrent: 4.4.5 x64 Operating system: Windows 11 Pro 22H2/22621.819 x64

What is the problem?

Something happened and now qBittorent shows taht the installed version is v4.4.5 (64-bit) while in the Control Panel list I see 4.5.0 version.

Steps to reproduce

I am not sure. Maybe related to winget?

Additional context

Log(s) & preferences file(s)

qbittorrent.log

[thalieht]

I am not sure. Maybe related to winget?

Most probably.

[sledgehammer999]

Go to our site and download the official installer.

[Sliverin]

Im having this same issue, in my case it installed but then reverted to 4.4.5 after closing and reopening the program.

[xavier2k6]

@simkoG @Sliverin Is this still an issue with qBittorrent 4.5.2?

[Yentis]

Just had this happen when updating through Winget while qBittorrent was still running (and after restarting qBittorrent):

[luzpaz]

What's the winget installer missing? Can someone let the downstream winget devs know ? (https://github.com/microsoft/winget-pkgs/pulls?q=is%3Apr+qbittorrent+is%3Aclosed)

[xavier2k6]

@Yentis

1. Did you issue install or upgrade command?
2. Did you run winget under PowerShell or Command Prompt?
3. Run as Administrator being used or not?
4. Are you using Windows 10 or Windows 11 & which build version?

[Yentis]

1. winget update --id qBittorrent.qBittorrent --exact --accept-source-agreements --disable-interactivity --accept-source-agreements --force via WingetUI (alias for upgrade)
2. Used WingetUI which uses PowerShell
3. Not running as Administrator, permissions were requested upon starting the update
4. Windows 10 21H2 19044.3324

[xavier2k6]

@Yentis Use winget upgrade qBittorrent.qBittorrent via PowerShell or Command Prompt

[Yentis]

That gives the same result as before.

[xavier2k6]

in my case it installed but then reverted to 4.4.5 after closing and reopening the program.

when updating through Winget while qBittorrent was still running

There lies the problem!

If qBittorrent is running when updating via winget......it'll update the correct version info via Windows Control Panel & under winget list qBittorrent.qBittorrent command but if you navigate to C:\Program Files\qBittorrent you will notice that qBittorrent.exe file didn't actually update to newer versions.......

Going forward, you will have to shutdown qBittorrent prior to updating with winget, update via our official installers from main website -> https://www.qbittorrent.org/download &/or report issue/findings upstream.

[xavier2k6]

I will leave this issue open for a day or so....

[Yentis]

Makes sense that things go wrong if the app is still running, but maybe the silent installer should fail in the case of winget? So the user knows they have to close the app first.

[xavier2k6]

but maybe the silent installer should fail in the case of winget? So the user knows they have to close the app first.

I didn't enable logging to see where or what went wrong....may do so when I have more time.

[luzpaz]

Maybe we can let the winget devs know about this and they can factor a warning message for users to make sure qbit isn't running while they update ? (this will help avoid future tickets like this from winget users)

[xavier2k6]

Ran winget with command winget install --verbose-logs qBittorrent.qBittorrent via PowerShell while qBittorrent was running & log is below:

WinGet-2023-09-05-14-43-47.919.log

I know if we run our own installer....it gives a warning to close running instance.

[denelon]

WinGet was designed with automation in mind, and a requirement to support silent installation. If the installer could throw an error when the installer is executed in silent or silent with progress, that error could be mapped to an expected return code in the manifest informing the user that they need to close the application.

[xavier2k6]

@sledgehammer999 Can you look in to this?

[luzpaz]

soft reminder for @sledgehammer999

[soredake]

https://github.com/qbittorrent/qBittorrent/issues/18582

[soredake]

Same problem with virtualbox https://www.virtualbox.org//ticket/21951

[Chocobo1]

If the installer could throw an error when the installer is executed in silent or silent with progress, that error could be mapped to an expected return code in the manifest informing the user that they need to close the application.

I've submitted PR #20296 which will set error codes when encountered errors at installation. I reckon the rest is to map the error codes to specific actions on WinGet side so each situation will be handled accordingly.