RandomNinjaAtk
[BUG] - Lidarr - Scripts endlessly looping
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....
Lidarr works fine but they loop. Is there an incompatibility between the plugin branch and the scripts? I noticed an error about uv on container start
On Tue, May 13, 2025, 8:44 PM RandomNinjaAtk @.***> wrote:
RandomNinjaAtk left a comment (RandomNinjaAtk/arr-scripts#369) https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2875979310
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....
— Reply to this email directly, view it on GitHub https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2875979310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP7FG4P4U3RGGAO6J23DD326HEJPAVCNFSM6AAAAAB47F5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNZVHE3TSMZRGA . You are receiving this because you authored the thread.Message ID: @.***>
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: https://github.com/RandomNinjaAtk/arr-scripts/blob/1f11a2bad8b4e82d6efb0dca3936c00be6fbdbec/universal/functions.bash#L28
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...
Yes, because I've had Lidarr and the scripts working with the main branch for months. It was only when I changed to the plugin branch. I literally only changed one line in what was a fully working configuration, and that was the image: in my docker compose. I'll try again with a completely from scratch docker later and see what happens.
On Fri, May 16, 2025, 10:51 AM RandomNinjaAtk @.***> wrote:
RandomNinjaAtk left a comment (RandomNinjaAtk/arr-scripts#369) https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2885363467
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...
— Reply to this email directly, view it on GitHub https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2885363467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP7FGYREUMF3ZEL2NK25CL26UZBPAVCNFSM6AAAAAB47F5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBVGM3DGNBWG4 . You are receiving this because you authored the thread.Message ID: @.***>
The init script used to run every time I spun the container up before using the plugin branch.
On Fri, May 16, 2025, 10:54 AM Josh Oram @.***> wrote:
Yes, because I've had Lidarr and the scripts working with the main branch for months. It was only when I changed to the plugin branch. I literally only changed one line in what was a fully working configuration, and that was the image: in my docker compose. I'll try again with a completely from scratch docker later and see what happens.
On Fri, May 16, 2025, 10:51 AM RandomNinjaAtk @.***> wrote:
RandomNinjaAtk left a comment (RandomNinjaAtk/arr-scripts#369) https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2885363467
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...
— Reply to this email directly, view it on GitHub https://github.com/RandomNinjaAtk/arr-scripts/issues/369#issuecomment-2885363467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP7FGYREUMF3ZEL2NK25CL26UZBPAVCNFSM6AAAAAB47F5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBVGM3DGNBWG4 . You are receiving this because you authored the thread.Message ID: @.***>
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....
Hi,
I've been having this same issue and for me have found that if i remove the image, backup the old config and re-pull and reinstall arr-scripts, then it works first time round. However if the container stops/restarts then the install process seems to happen all over again and it breaks something.
If i then remove that image and re-pull and reinstall the arr-scripts, it works again until it stops/restarts.
