Extended Audio :: Lidarr is not ready, sleeping until valid response... wget: can't connect to remote host: Connection refused

[Pabston]

Hi,

I have recently moved from AMD to Lidarr extended. I run two instances of Lidarr via portainer and am having issues with Lidarr Extended on one of them. My knowledge is fairly basic with issues like this, so apologies if its something simple.

Its all working fine on the instance using the standard Lidarr port of 8686, but on the instance using port 8688 I am getting the following:

Extended Audio :: Lidarr is not ready, sleeping until valid response... wget: can't connect to remote host (127.0.0.1): Connection refused

The Lidarr instance is running normally and fine. I have looked through the config folder to check for any port mismatches and the only once I could find is in extended/scripts/audio. The line of "lidarrUrl="http://127.0.0.1:8686${lidarrUrlBase}" still points towards the standard port, I have tried changing this to the new port but every restart of the docker reverts it back to port 8686.

Hopefully someone can point me in the right direction.

Thanks in advance.

P

[RandomNinjaAtk]

The script is built in, so URL/port shouldn't matter because internally that is what Lidarr uses, regardless of your change via docker config. Does each container have its own set of unqiue volumes? (not using the same config volume for both containers, using the same config volume location would cause an issue...)

Also did you make sure that the lidarr web interface is accessible?
Also whats the purpose of having 2 instances on the same machine? (Seems unnecessary...)

EDIT: If you changed the port in the Lidarr web interface, that would be why its not working. However, you shouldn't be changing it there, you should be changing it via your docker config or portainer config in this case... I'm not familiar with portainer...

[Pabston]

Hey,

Thanks for the reply.

Yeah each instance has its own config volume, so completely seperate from each other.

Lidarr web UI is accessible, all fully working okay.

Yeah the 2 instances is a bit tedious, but its the only way I could find to add specific quality profiles to certain albums (rather than it applying to the artist as a whole). Not ideal.

I think maybe, if i swap the ports on the two instances to make the main Lidarr instance use the base port of 8686, just to get things working. The second instance is smaller and doesnt benefit from the script as much, so it can live without it.

Appreciate the help

[Pabston]

Just a quick update.

I swapped the ports on the two instances.

The port 8686 (regardless of which instance) works fine with the script.

The instance that is not using 8686, gets the "Lidarr is not ready, sleeping until valid response" message

[RandomNinjaAtk]

After the latest update builds and becomes available, try updating and see if it resolves your issue....

Reference:
cf9a87e
b675f11

Edit: Update should be live!

[Pabston]

All working perfectly now on both instances.

Many thanks for the quick help

[RandomNinjaAtk]

Just an FYI: The reason this works is because your not actually configuring your docker container correctly... So this is a workaround, but not a bad one to have included in general because other users may also miss configure there setup in the same manor.

You should not be changing the port number from within the Lidarr web interface, your supposed to control it via docker or in your case portainer... Similar to how you've pointed the volumes to different locations...

Anyways, glad it works for you, but you should look into correctly configuring the container using portainer to avoid potential issues with other docker containers that you may use in the future that could have port overlaps....

[Pabston]

Ahh i think there may be a misunderstanding.

The Lidarr ports were setup/seletected using the container settings and config files never using the webui. But is good to know as something to avoid.

Appreciate the help and guidance