[BUG] - Lidarr - Scripts endlessly looping
Opened this issue · 17 comments
Application
Lidarr with Plugin support ghcr.io/linuxserver-labs/prarr:lidarr-plugins
Host platform
Docker on Debian
Script
Lidarr Extended
Script Version
QueueCleaner :: 2.0
Audio :: 2.48
AutoConfig :: 3.2
Describe the bug
2025-05-13 10:01:14 :: QueueCleaner :: 2.0 :: is not ready, sleeping until valid response...
2025-05-13 10:01:15 :: Audio :: 2.48 :: is not ready, sleeping until valid response...
2025-05-13 00:01:15 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
Looping in logs
To Reproduce
- Start docker container
- Check logs
Expected behavior
Scripts don't loop endlessly
Logs/Screenshots
2025-05-13 10:01:14 :: QueueCleaner :: 2.0 :: is not ready, sleeping until valid response...
2025-05-13 10:01:15 :: Audio :: 2.48 :: is not ready, sleeping until valid response...
2025-05-13 00:01:15 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
Additional context
Have arr-extended scripts running in Radarr and Sonarr without the same problem.
NOTE
Your request will not be addressed without proper detail and logs. Always make sure you have updated to the latest script versions before opening an issue or your issue will not be reviewed.
They are designed to loop until lidarr responds.... So if your lidarr isn't starting you have some other issue....
If your lidarr web interface is operational and it's still looping, then maybe there is a problem but not currently reproducible most likely....
The plugin branch is untested... So I don't know if it'll work with it or not... If the container is still linuxserver.io's container. Then it might work, if its not linuxserver.io's container, then that is likely the problem...
i have the same bug but with linuxserver.io. initially i thought it might be my setup in the extended.conf, but this was not the case.
@nascimentokembo Are you using the plugin branch also?
FYI, no issues in looping with this version from my testing:
Version 2.12.0.4633
Package Version 2.12.0.4633-ls212 by [linuxserver.io](https://www.linuxserver.io/)
How do I check if its the plugin branch? I updated Lidarr when i got the notification from unraid. currently i have this version: 2.11.2.4629-ls42 by linuxserver.io
How do I check if its the plugin branch? I updated Lidarr when i got the notification from unraid. currently i have this version: 2.11.2.4629-ls42 by linuxserver.io
Is your lidarr web interface working... ? The only reason the script loops is because it cannot connect to Lidarr, which is typically a sign that the web interface is not working/loaded...
Application Lidarr with Plugin support ghcr.io/linuxserver-labs/prarr:lidarr-plugins
Host platform Docker on Debian
Script Lidarr Extended
Script Version QueueCleaner :: 2.0 Audio :: 2.48 AutoConfig :: 3.2
Describe the bug 2025-05-13 10:01:14 :: QueueCleaner :: 2.0 :: is not ready, sleeping until valid response... 2025-05-13 10:01:15 :: Audio :: 2.48 :: is not ready, sleeping until valid response... 2025-05-13 00:01:15 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
Looping in logs
To Reproduce
- Start docker container
- Check logs
Expected behavior Scripts don't loop endlessly
Logs/Screenshots 2025-05-13 10:01:14 :: QueueCleaner :: 2.0 :: is not ready, sleeping until valid response... 2025-05-13 10:01:15 :: Audio :: 2.48 :: is not ready, sleeping until valid response... 2025-05-13 00:01:15 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
Additional context Have arr-extended scripts running in Radarr and Sonarr without the same problem.
NOTE Your request will not be addressed without proper detail and logs. Always make sure you have updated to the latest script versions before opening an issue or your issue will not be reviewed.
Just reviewing your logging message again, the issue is that the script is not able to pull the information correctly from the lidarr config file, your posted logs are missing the App name, which indicates it cannot read /config/config.xml file of the Arr app:
Correct output:
2025-05-15 17:54:34 :: AutoConfig :: 2.48 :: Lidarr is not ready, sleeping until valid response...
2025-05-15 13:54:34 :: QueueCleaner :: 2.0 :: Lidarr is not ready, sleeping until valid response...
Where it gets it:
arr-scripts/universal/functions.bash
Line 28 in 1f11a2b
EDIT:
Thinking about this more, you most likely didn't follow the instructions correctly for setup... Because what I suspect is that the setup script did not run and install packages that are required for it to work. So it is silently failing with no error message. This is just a suspicion though... Double/Triple check that you followed the setup instructions correctly...
https://github.com/RandomNinjaAtk/arr-scripts/tree/main/lidarr#installationsetup
If you don't see the packages installing in the container logs on startup... then that confirms your problem.
The /config/config.xml file is there with <InstanceName>Lidarr</InstanceName>, and I did have a working Lidarr with the scripts working. All I did was change to the Linuxserver plugin branch in my compose file. Teh startup scripts are definitely there. Whether or not the Linuxserver plugin branch doesn't run them like the main branch or not, i'm not sure.
I want to use a Slskd plugin so for now i'm just using my old scripts and separate beets docker container to do my tagging until I work out what's wrong.
Did you validate you followed the setup instructions correctly?
Maybe post your docker compose and screenshots of the files to show you have everything in the right place....
Specifically the Init script needs to be in the correct location... Also post logs of the container starting to show if the init script runs properly...
I was experiencing this yesterday (first time I looked at Lidarr logs in awhile, so IDK how long it had been happening). I was able to fix it by basically reinstalling the extended scripts. These are the steps I followed:
- Stop container
- Move extended.conf out of the mounted config volume
- Delete extended/ from the config volume
- Remove the custom-services.d and custom-cont-init.d volume mappings
- Start container and let it boot fully
- Stop container
- Re-map custom-services.d and custom-cont-init.d volumes
- Replace scripts_init.bash with the latest
- Move extended.conf back to the config directory
- mkdir extended/ and extended/import in the config directory
- Start container and all is well
I was experiencing this yesterday (first time I looked at Lidarr logs in awhile, so IDK how long it had been happening). I was able to fix it by basically reinstalling the extended scripts. These are the steps I followed:
- Stop container
- Move extended.conf out of the mounted config volume
- Delete extended/ from the config volume
- Remove the custom-services.d and custom-cont-init.d volume mappings
- Start container and let it boot fully
- Stop container
- Re-map custom-services.d and custom-cont-init.d volumes
- Replace scripts_init.bash with the latest
- Move extended.conf back to the config directory
- mkdir extended/ and extended/import in the config directory
- Start container and all is well
Glad to hear that worked, as I sad the looping is not reproducible on my end, so the cause is something else and I'm glad my recommendation of reinstalling/following the setup resolved the issue for you.
I managed to get it to work too by force updating in unraid. Funnily enough it didn't update because I already had the latest version but it reset my docker image.
I managed to get it to work too by force updating in unraid. Funnily enough it didn't update because I already had the latest version but it reset my docker image.
Forcing an image update in unraid, should clean the image and let the scripts reinstall the requirements... Likely what is happening is that the dependencies are not there and it's silently failing because of it... At least that is my suspicion... With the recent changes though, it should not be reinstalling every reboot of the container, thus speeding up the process going forward...
I'm going to leave this open for now, but will likely close it in the near future since no actions need to be taken on this end and the issue is not reproducible on this end either....
The suggestion is to re-do the installation, just back up your Extended conf file to not loose your settings....