[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) <#369 (comment)> 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 <#369 (comment)>, 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

@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

arrName="$(cat /config/config.xml | xq | jq -r .Config.InstanceName)"

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) <#369 (comment)> 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 <#369 (comment)>, 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) > <#369 (comment)> > > 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 > <#369 (comment)>, > 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

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...

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...

lucky you, mines already set correctly to execute and i can see it does in the logs..

The init script used to run every time I spun the container up before using
the plugin branch.
…

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

image: ghcr.io/linuxserver-labs/prarr:lidarr-plugins

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:

**** Adding xq to OS package install list ****
[pkg-install-init] **** Installing all mod packages ****
(1/1) Installing xq (1.3.0-r11)
Executing busybox-1.37.0-r30.trigger
OK: 140.9 MiB in 120 packages
[custom-init] Files found, executing
[custom-init] scripts_init.bash: is not an executable file

So I added execute permissions with:

chmod +x scripts_init.bash

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.

@RandomNinjaAtk

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...

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
}

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 }

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=******************"

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:

Necessary fixes:

Parse config.xml without xq (it was exiting non-zero in the container, leaving arrPort/arrApiKey empty and generating a bad base URL). Switched getArrAppInfo() to sed extraction of Port, ApiKey, UrlBase, InstanceName.

may be optional:

Fix verifyApiAccess() to be Lidarr-safe:
- try v1 first (Lidarr working endpoint)
- use curl -fsS so HTTP errors don’t feed junk to jq
- parse the full response body and accept .instanceName or .appName
- stop once v1 succeeds; ignore v3 being 404

getArrAppInfo () {
  # Get Arr App information
  if [ -z "$arrUrl" ] || [ -z "$arrApiKey" ]; then
    arrUrlBase="$(sed -n 's:.*<UrlBase>\(.*\)</UrlBase>.*:\1:p' /config/config.xml | head -n1)"
    if [ -z "$arrUrlBase" ]; then
      arrUrlBase=""
    else
      arrUrlBase="/$(echo "$arrUrlBase" | sed 's:^/*::; s:/*$::')"
    fi
    arrName="$(sed -n 's:.*<InstanceName>\(.*\)</InstanceName>.*:\1:p' /config/config.xml | head -n1)"
    arrApiKey="$(sed -n 's:.*<ApiKey>\(.*\)</ApiKey>.*:\1:p' /config/config.xml | head -n1)"
    arrPort="$(sed -n 's:.*<Port>\(.*\)</Port>.*:\1:p' /config/config.xml | head -n1)"
    arrUrl="http://127.0.0.1:${arrPort}${arrUrlBase}"
  fi
}

verifyApiAccess () {
  until false
  do
    arrApiTest=""
    arrApiVersion=""

    arrApiVersion="v1"
    arrApiTest="$(curl -fsS "$arrUrl/api/$arrApiVersion/system/status?apikey=$arrApiKey" 2>/dev/null | jq -er '.instanceName // .appName // empty' 2>/dev/null || true)"

    if [ -z "$arrApiTest" ]; then
      arrApiVersion="v3"
      arrApiTest="$(curl -fsS "$arrUrl/api/$arrApiVersion/system/status?apikey=$arrApiKey" 2>/dev/null | jq -er '.instanceName // .appName // empty' 2>/dev/null || true)"
    fi

    if [ ! -z "$arrApiTest" ]; then
      break
    else
      log "$arrName is not ready, sleeping until valid response..."
      sleep 1
    fi
  done
}

Everything is working now!

[Info] Microsoft.Hosting.Lifetime: Now listening on: http://[::]:8686
[ls.io-init] done.
2026-02-05 11:05:07 :: AutoConfig :: 3.2 :: verifyApiAccess: try=v1 url=http://127.0.0.1:8686/api/v1/system/status?apikey=REDACTED ok=yes
2026-02-05 03:05:07 :: Video :: 4.0 :: verifyApiAccess: try=v1 url=http://127.0.0.1:8686/api/v1/system/status?apikey=REDACTED ok=yes
2026-02-05 03:05:07 :: QueueCleaner :: 2.1 :: verifyApiAccess: try=v1 url=http://127.0.0.1:8686/api/v1/system/status?apikey=REDACTED ok=yes
2026-02-05 03:05:07 :: Audio :: 2.48 :: verifyApiAccess: try=v1 url=http://127.0.0.1:8686/api/v1/system/status?apikey=REDACTED ok=yes
2026-02-05 03:05:07 :: Video :: 4.0 :: verifyApiAccess: OK api=v1 instance=Lidarr
2026-02-05 03:05:07 :: Audio :: 2.48 :: verifyApiAccess: OK api=v1 instance=Lidarr
2026-02-05 11:05:07 :: AutoConfig :: 3.2 :: verifyApiAccess: OK api=v1 instance=Lidarr
2026-02-05 03:05:07 :: QueueCleaner :: 2.1 :: verifyApiAccess: OK api=v1 instance=Lidarr
2026-02-05 11:05:07 :: AutoConfig :: 3.2 :: Configuring Lidarr Media Management Settings
2026-02-05 03:05:07 :: Video :: 4.0 :: -----------------------------------------------------------------------------
2026-02-05 03:05:07 :: Audio :: 2.48 :: -----------------------------------------------------------------------------
2026-02-05 03:05:07 :: Video :: 4.0 :: |~~) _ ._ | _ . _ |\ |o._ o _ |~~|||
2026-02-05 03:05:07 :: Audio :: 2.48 :: |~~) _ ._ | _ . _ |\ |o._ o _ |~~|||
2026-02-05 03:05:07 :: Video :: 4.0 :: |~~(|| |(|()| | || ||| ||(_||~~| | |<
2026-02-05 03:05:07 :: Audio :: 2.48 :: |~~(|| |(|()| | || ||| ||(_||~~| | |<
2026-02-05 03:05:07 :: Audio :: 2.48 :: Presents: Audio (2.48)
2026-02-05 03:05:07 :: Video :: 4.0 :: Presents: Video (4.0)
2026-02-05 03:05:07 :: QueueCleaner :: 2.1 :: Starting...
2026-02-05 03:05:07 :: Audio :: 2.48 :: May the beats be with you!
2026-02-05 03:05:07 :: Video :: 4.0 :: May the beats be with you!
2026-02-05 03:05:07 :: Audio :: 2.48 :: -----------------------------------------------------------------------------
2026-02-05 03:05:07 :: Video :: 4.0 :: -----------------------------------------------------------------------------
2026-02-05 03:05:07 :: Audio :: 2.48 :: Donate: https://github.com/sponsors/RandomNinjaAtk
2026-02-05 03:05:07 :: Video :: 4.0 :: Donate: https://github.com/sponsors/RandomNinjaAtk
2026-02-05 03:05:07 :: Video :: 4.0 :: Project: https://github.com/RandomNinjaAtk/arr-scripts
2026-02-05 03:05:07 :: Audio :: 2.48 :: Project: https://github.com/RandomNinjaAtk/arr-scripts
2026-02-05 03:05:07 :: Video :: 4.0 :: Support: https://github.com/RandomNinjaAtk/arr-scripts/discussions
2026-02-05 03:05:07 :: Audio :: 2.48 :: Support: https://github.com/RandomNinjaAtk/arr-scripts/discussions
2026-02-05 03:05:07 :: Video :: 4.0 :: -----------------------------------------------------------------------------
2026-02-05 03:05:07 :: Audio :: 2.48 :: -----------------------------------------------------------------------------
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: Configuring Lidarr Metadata ConsumerSettings
2026-02-05 03:05:08 :: QueueCleaner :: 2.1 :: Sleeping 15m...
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: Configuring Lidarr Metadata Provider Settings
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: Configuring Lidarr Custom Scripts
[Info] Microsoft.Hosting.Lifetime: Application started. Press Ctrl+C to shut down.
[Info] Microsoft.Hosting.Lifetime: Hosting environment: Production
[Info] Microsoft.Hosting.Lifetime: Content root path: /app/lidarr/bin
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: PlexNotify.bash Already added to Lidarr custom scripts
[Info] ManagedHttpDispatcher: IPv4 is available: True, IPv6 will be disabled
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: LyricExtractor.bash Already added to Lidarr custom scripts
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: ArtworkExtractor.bash Already added to Lidarr custom scripts
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: BeetsTagger.bash Already added to Lidarr custom scripts
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: Configuring Lidarr UI Settings
2026-02-05 11:05:08 :: AutoConfig :: 3.2 :: Configuring Lidarr Standard Metadata Profile
2026-02-05 03:05:12 :: Video :: 4.0 ::
2026-02-05 03:05:12 :: Audio :: 2.48 ::
2026-02-05 03:05:12 :: Audio :: 2.48 :: Lift off in...
2026-02-05 03:05:12 :: Video :: 4.0 :: Lift off in...
2026-02-05 03:05:13 :: Video :: 4.0 :: 5
2026-02-05 03:05:13 :: Audio :: 2.48 :: 5

Add automatic API version detection for Arr apps

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!

I ran this recently, and I had to fix two things to get it to work at a baseline

One was the bug from #377 because urlBase could be an empty string (which is what mine was set to).

And also that xq requires -j flag otherwise it just prints out more xml to fail on the jq step.

main...NekoShinobi:arr-scripts:main

I did a fresh reinstall following the instructions and am getting this error again.

2026-04-10 22:40:52 :: QueueCleaner :: 2.1 :: is not ready, sleeping until valid response...
2026-04-11 01:40:53 :: AutoConfig :: 3.2 :: is not ready, sleeping until valid response...
2026-04-10 22:40:53 :: Audio :: 2.48 :: is not ready, sleeping until valid response...

Following Ejmathewp s steps had worked in the past but no longer work anymore.

Thank you NekoShinobi i went in and made the changes outlined in your link for lines 25, 30, 31, and 32, in the functions.bash file its now working again.

@samhaswon

The maintainer doesn't seem to be merging PR's any more. myself and @samhaswon both have our own branches that solve this and add other features. Check those out and see if one will work for you.

Hey everyone,

I ran into this issue and spent a few days troubleshooting it. To make things easier for others, I put together an updated script that works with:

Lidarr Version: 3.1.0.4875
Package Version: 3.1.0.4875-ls24 (linuxserver.io)

I’ve also included an updated guide alongside the script here:
https://github.com/Kickala/kickarr/blob/main/README.md

Hopefully this saves someone else the time I lost 👍

Hey everyone,

I ran into this issue and spent a few days troubleshooting it. To make things easier for others, I put together an updated script that works with:
* Lidarr Version: 3.1.0.4875

* Package Version: 3.1.0.4875-ls24 (linuxserver.io)
I’ve also included an updated guide alongside the script here: https://github.com/Kickala/kickarr/blob/main/README.md

Hopefully this saves someone else the time I lost 👍

Thank you merabi14!

Your Lidarr fix worked perfectly for me and resolved the issues I was having with the linuxserver.io container.

I used your fixed version as the base and created patched versions for Radarr and Sonarr as well:

Patched Scripts Repo: https://github.com/M-Endymion/arr-patched-scripts

The main changes I made were more robust XML parsing for getArrAppInfo, safer permission handling, and a few small reliability tweaks.

All scripts are under GPL-3.0 and give full credit to the original work. Your Lidarr patch was the inspiration for these.

Thanks again!

Navigation Menu

Repository navigation

[BUG] - Lidarr - Scripts endlessly looping #369

8 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[BUG] - Lidarr - Scripts endlessly looping #369

Description

Activity

RandomNinjaAtk commented on May 13, 2025

joshoram80 commented on May 13, 2025

RandomNinjaAtk commented on May 13, 2025

nascimentokembo commented on May 15, 2025

RandomNinjaAtk commented on May 15, 2025

nascimentokembo commented on May 15, 2025

RandomNinjaAtk commented on May 15, 2025

RandomNinjaAtk commented on May 15, 2025

joshoram80 commented on May 15, 2025

RandomNinjaAtk commented on May 16, 2025

joshoram80 commented on May 16, 2025

joshoram80 commented on May 16, 2025

Ejmathewp commented on May 21, 2025

8 remaining items

Makario1337 commented on Dec 2, 2025

danutzzzzz commented on Dec 2, 2025

rairulyle commented on Dec 29, 2025

samhaswon commented on Jan 28, 2026

Makario1337 commented on Jan 28, 2026

Gnomie4Homie commented on Feb 3, 2026

Darkcloud1987 commented on Feb 3, 2026

mkaltner commented on Feb 5, 2026

mkaltner commented on Feb 12, 2026

NekoShinobi commented on Mar 14, 2026

Triforcecwp commented on Apr 11, 2026

mkaltner commented on Apr 12, 2026

merabi14 commented on Apr 16, 2026

M-Endymion commented on May 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions