Upgrade Button Spins with No Progress or Changes #3721

New issue

Open

opened 2026-02-20 02:20:25 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-20 02:20:25 -05:00

Owner

Originally created by @Normanras on GitHub (May 21, 2024).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

I cannot update Lidarr from the UI despite it giving me the alert that I have a new version available for update.

Expected Behavior

When I click the update button within System > Updates, it successfully updates. This used to work until recently. I am still trying to track down the specific cause for this error.

Steps To Reproduce

Ensure Lidarr is running
Navigate to domain and/or IP & port for Lidarr
Click System > Updates
Click "Install Update"

Environment

- OS: Debian
- Lidarr: Version 2.1.7.4030
- Docker Install: No
- Using Reverse Proxy: No
- Browser: Chrome Version 125.0.6422.60
- Database: Sqlite 3.34.1

What branch are you running?

Master

Trace Logs?

Under systemctl status lidarr, this has been showing up, which I think is the main culprit.

May 21 16:23:12 media Lidarr[125]: SQLite error (1): near "SHOW": syntax error in "SHOW server_version"

However, looking through the log files, this one is a bit odd. Permissions haven't changed and (to my knowledge) I haven't tried installing Lidarr multiple times:

2024-05-21 15:59:22.3|Fatal|ConsoleApp|Failed to bind to address http://[::]:8686: address already in use. This can happen if another instance of Lidarr is already running another application is using the same port (default: 8686) or the user has insufficient permissions

I know that I'm running 2.1.7.4030, the latest update is 2.3.3.4204 and I'm skipping over 2.2.5.4141, but I could have sworn that I had skipped over versions in the past.

There are no logs in the file with trace.

Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided.

I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

Originally created by @Normanras on GitHub (May 21, 2024). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior I cannot update Lidarr from the UI despite it giving me the alert that I have a new version available for update. ### Expected Behavior When I click the update button within System > Updates, it successfully updates. This used to work until recently. I am still trying to track down the specific cause for this error. ### Steps To Reproduce 1. Ensure Lidarr is running 2. Navigate to domain and/or IP & port for Lidarr 3. Click System > Updates 4. Click "Install Update" ### Environment ```markdown - OS: Debian - Lidarr: Version 2.1.7.4030 - Docker Install: No - Using Reverse Proxy: No - Browser: Chrome Version 125.0.6422.60 - Database: Sqlite 3.34.1 ``` ### What branch are you running? Master ### Trace Logs? Under `systemctl status lidarr`, this has been showing up, which I think is the main culprit. ``` May 21 16:23:12 media Lidarr[125]: SQLite error (1): near "SHOW": syntax error in "SHOW server_version" ``` However, looking through the log files, this one is a bit odd. Permissions haven't changed and (to my knowledge) I haven't tried installing Lidarr multiple times: ``` 2024-05-21 15:59:22.3|Fatal|ConsoleApp|Failed to bind to address http://[::]:8686: address already in use. This can happen if another instance of Lidarr is already running another application is using the same port (default: 8686) or the user has insufficient permissions ``` I know that I'm running `2.1.7.4030`, the latest update is `2.3.3.4204` and I'm skipping over `2.2.5.4141`, but I could have sworn that I had skipped over versions in the past. There are no logs in the file with `trace`. ### Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided. - [X] I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain `trace` - that are relevant and show this issue.