qBittorrent
qBittorrent copied to clipboard
Version mismatch after latest update
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)
I am not sure. Maybe related to winget?
Most probably.
Go to our site and download the official installer.
Im having this same issue, in my case it installed but then reverted to 4.4.5 after closing and reopening the program.
@simkoG @Sliverin Is this still an issue with qBittorrent 4.5.2?
Just had this happen when updating through Winget while qBittorrent was still running (and after restarting qBittorrent):
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)
@Yentis
- Did you issue
install
orupgrade
command? - Did you run
winget
underPowerShell
orCommand Prompt
? -
Run as Administrator
being used or not? - Are you using
Windows 10
orWindows 11
& which build version?
-
winget update --id qBittorrent.qBittorrent --exact --accept-source-agreements --disable-interactivity --accept-source-agreements --force
via WingetUI (alias forupgrade
) - Used WingetUI which uses
PowerShell
- Not running as Administrator, permissions were requested upon starting the update
- Windows 10 21H2 19044.3324
@Yentis Use winget upgrade qBittorrent.qBittorrent
via PowerShell
or Command Prompt
That gives the same result as before.
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.
I will leave this issue open for a day or so....
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.
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.
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)
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.
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.
@sledgehammer999 Can you look in to this?
soft reminder for @sledgehammer999
https://github.com/qbittorrent/qBittorrent/issues/18582
Same problem with virtualbox https://www.virtualbox.org//ticket/21951
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.