mirror of
https://github.com/RandomNinjaAtk/arr-scripts.git
synced 2026-03-02 22:57:35 -05:00
[BUG] - Lidarr - Scripts endlessly looping #203
Labels
No labels
Needs Triage
Not Reproducible
Upstream Issue
User Error
bug
documentation
enhancement
good first issue
help wanted
invalid
lidarr
lidarr
question
radarr
readarr
sabnzbd
sonarr
synology (host)
unraid (host)
waiting for logs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/arr-scripts#203
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @joshoram80 on GitHub (May 12, 2025).
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
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.
@RandomNinjaAtk commented on GitHub (May 13, 2025):
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....
@joshoram80 commented on GitHub (May 13, 2025):
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 commented on GitHub (May 13, 2025):
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...
@nascimentokembo commented on GitHub (May 15, 2025):
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.
@RandomNinjaAtk commented on GitHub (May 15, 2025):
@nascimentokembo Are you using the plugin branch also?
FYI, no issues in looping with this version from my testing:
@nascimentokembo commented on GitHub (May 15, 2025):
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
@RandomNinjaAtk commented on GitHub (May 15, 2025):
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...
@RandomNinjaAtk commented on GitHub (May 15, 2025):
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:
Where it gets it:
github.com/RandomNinjaAtk/arr-scripts@1f11a2bad8/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.
@joshoram80 commented on GitHub (May 15, 2025):
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.
@RandomNinjaAtk commented on GitHub (May 15, 2025):
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...
@joshoram80 commented on GitHub (May 15, 2025):
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:
@joshoram80 commented on GitHub (May 15, 2025):
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:
@Ejmathewp commented on GitHub (May 21, 2025):
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:
@RandomNinjaAtk commented on GitHub (May 21, 2025):
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.
@nascimentokembo commented on GitHub (May 21, 2025):
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.
@RandomNinjaAtk commented on GitHub (May 21, 2025):
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...
@RandomNinjaAtk commented on GitHub (May 21, 2025):
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....
@danutzzzzz commented on GitHub (Nov 19, 2025):
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.
@Makario1337 commented on GitHub (Dec 2, 2025):
Had the same issue. I did a chmod +x on the custom-cont-init.d/scripts_init.bash file i mounted in docker. After that it worked like normal again...
@danutzzzzz commented on GitHub (Dec 2, 2025):
lucky you, mines already set correctly to execute and i can see it does in the logs..
@rairulyle commented on GitHub (Dec 29, 2025):
Found a fix for this. Basically, the hotio image does not run the script but then I found out that linuxserver (which is tested) have an experimental branch that supports plugin as well. https://wiki.servarr.com/en/lidarr/plugins
@samhaswon commented on GitHub (Jan 28, 2026):
I think I've run into this same problem for some reason. Before trying to set up everything again, I tried just recreating the container, which was done recently due to an update. When I did, I saw these log lines:
So I added execute permissions with:
And now it works. I think that "8. Replace scripts_init.bash with the latest" just so happens to be fixing the permissions issue. Perhaps adding execute permissions should be added to the README.
@Makario1337 commented on GitHub (Jan 28, 2026):
I think we’re aligned on the fix here. As mentioned earlier, adding a note in the README to run chmod +x scripts_init should prevent the permission issue for new users.
@RandomNinjaAtk — seems like a small, safe improvement to avoid this issue in the future...
@Gnomie4Homie commented on GitHub (Feb 3, 2026):
Wanted to chime in on this as I was having similar issues and no amount of re-installing or rebuilding would fix it. I did manage to find my ultimate root cause though and haven't had time to troubleshoot anymore thoroughly but diagnosed the issue with the API validation in the functions code.
With the hint from Ninja about the script not being able to connect to Lidarr, I was able to validate Lidarr was accessible via v1 of the VerifyAPIAccess code but could not hit the API on v3 (I have no idea if Lidarr is able to respond?). It looks like if v3 fails it should attempt v1 but maybe it's not?
Instead just to validate, I removed the variables in the v3 code and put my exact v1 API URL in and it started working immediately. I am not a programmer by any means and am not sure what specific part is broken but do know the issue is with API validation.
Hope this helps others and sheds some light on what's going on maybe.
TL;DR - So I replaced the v3 code of arrApiTest below with "http://127.0.0.1:8686/api/v1/system/status?apikey=******************"
verifyApiAccess () {
until false
do
arrApiTest=""
arrApiVersion=""
if [ -z "$arrApiTest" ]; then
arrApiVersion="v3"
arrApiTest="$(curl -s "arrUrl/api/$arrApiVersion/system/status?apikey=$arrApiKey" | jq -r .instanceName)"
fi
if [ -z "$arrApiTest" ]; then
arrApiVersion="v1"
arrApiTest="$(curl -s "$arrUrl/api/$arrApiVersion/system/status?apikey=$arrApiKey" | jq -r .instanceName)"
fi
if [ ! -z "$arrApiTest" ]; then
break
else
log "$arrName is not ready, sleeping until valid response..."
sleep 1
fi
done
}
@Darkcloud1987 commented on GitHub (Feb 3, 2026):
that worked to be specific: I replaced "arrUrl/api/$arrApiVersion/system/status?apikey=$arrApiKey" after ArrApiVersion="v3" with the
"http://127.0.0.1:8686/api/v1/system/status?apikey=******************"
@mkaltner commented on GitHub (Feb 5, 2026):
I just started having this problem too.
2026-02-05 10:49:20 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
2026-02-05 02:49:20 :: QueueCleaner :: 2.1 :: is not ready, sleeping until valid response...
2026-02-05 02:49:20 :: Video :: 4.0 :: is not ready, sleeping until valid response...
2026-02-05 02:49:20 :: Audio :: 2.48 :: is not ready, sleeping until valid response...
2026-02-05 10:49:21 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
Note that there is no $arrName in the log.
If it matters, I'm on the LSIO version of Lidarr, not upstream.
I consulted with the robots:
Everything is working now!
@mkaltner commented on GitHub (Feb 12, 2026):
Pushed a fix for this based on my comment above. Along with the PR I pushed for #402, my system is back to downloading music again!