Stop after :: DEEZER :: Successfully Verified

[DustyTurtleDip]

Everything was working fine and I downloaded a total of 18294 tracks.

Now, when I start the container, it freeze after :: DEEZER :: Successfully Verified

here's the configuration I have :

sudo docker create \ --name=lidarr-extended \ -v /PATH/TO/Docker_Lidarr_Extended:/config \ -v /PATH/TO/Downloads:/downloads-lidarr-extended \ -v /PATH/TO/Music/Album:/music \ -v /PATH/TO/Music/Videos:/music-videos \ -p 8686:8686 \ -e TZ=America/New_York \ -e PUID=1000 \ -e PGID=1000 \ -e autoStart=true \ -e enableAudioScript=true \ -e enableVideoScript=false \ -e scriptInterval=15m \ -e configureLidarrWithOptimalSettings=true \ -e searchSort=album \ -e audioFormat=aac \ -e audioBitrate=192 \ -e requireQuality=false \ -e enableReplaygainTags=true \ -e audioLyricType=both \ -e dlClientSource=deezer \ -e arlToken=MYDEEZERARLTOKEN \ -e tidalCountryCode=US \ -e addDeezerTopArtists=false \ -e addDeezerTopAlbumArtists=false \ -e addDeezerTopTrackArtists=false \ -e topLimit=10 \ -e addRelatedArtists=false \ -e numberOfRelatedArtistsToAddPerArtist=2 \ -e addFeaturedVideoArtists=false \ -e plexUrl=http://IP-OF-PLEX-SERVER:32400 \ -e plexToken=*** \ -e youtubeSubtitleLanguage=en \ -e enableQueueCleaner=true \ -e matchDistance=5 \ --restart unless-stopped \ randomninjaatk/lidarr-extended:latest

[RandomNinjaAtk]

What is the script version? (Should be reported at the start of script run) How long did you wait?

Also something worth trying would be to update your ARL token, if you haven't done that recently.

[DustyTurtleDip]

What is the script version? (Should be reported at the start of script run) How long did you wait?

Also something worth trying would be to update your ARL token, if you haven't done that recently.

Here's the script version : Presents: lidarr-extended (1.0.258) I did wait more than 2 days

I tried updating the ARL just after I posted the issue, but it didn't work.

[RandomNinjaAtk]

Don't think it should matter, but latest version is: 1.0.261

So update, and re-check/verify its a problem on the latest script version.

[DustyTurtleDip]

Don't think it should matter, but latest version is: 1.0.261

So update, and re-check/verify its a problem on the latest script version.

So after updating, it downloaded a few tracks and froze again. Here's the logs of the container about 10 minutes after it froze.

I restarted it to see what would happen, It look like it downloaded the same tracks again then frozed. Here's another screenshot :

[RandomNinjaAtk]

You would need to check the processes to see if the client is running, if the client is running, which I expect that is what is happening, then there isn't really anything that can be done... might be a bug in the client or some other odd issue, but it wouldn't be script related.

The only thing that could be done at that point, is maybe forcing a timeout on the client as a work around to give it a kick.... But that isn't really a fix....

[DustyTurtleDip]

You would need to check the processes to see if the client is running, if the client is running, which I expect that is what is happening, then there isn't really anything that can be done... might be a bug in the client or some other odd issue, but it wouldn't be script related.

The only thing that could be done at that point, is maybe forcing a timeout on the client as a work around to give it a kick.... But that isn't really a fix....

So I should see deemix running in the container ?

Here's the processes actually running in the container :

[RandomNinjaAtk]

You can see from the script, the next immediate process it to run the client https://github.com/RandomNinjaAtk/docker-lidarr-extended/blob/ad609543b0a0990ae2272924896bb78ed1c46a16/root/scripts/audio.sh#L554-L563

[DustyTurtleDip]

You can see from the script, the next immediate process it to run the client

https://github.com/RandomNinjaAtk/docker-lidarr-extended/blob/ad609543b0a0990ae2272924896bb78ed1c46a16/root/scripts/audio.sh#L554-L563

I was able to start the client with the command.

SO I cleared the container data folder and restarted it to see if something was corrtupted.. It's currently scanning all my tracks. I will see it help.

Thank you very much for your time and this NICE script!

[DustyTurtleDip]

You can see from the script, the next immediate process it to run the client https://github.com/RandomNinjaAtk/docker-lidarr-extended/blob/ad609543b0a0990ae2272924896bb78ed1c46a16/root/scripts/audio.sh#L554-L563

I was able to start the client with the command.

SO I cleared the container data folder and restarted it to see if something was corrtupted.. It's currently scanning all my tracks. I will see it help.

Thank you very much for your time and this NICE script!

So the deletion of the container's data folder worked.

Thank you,

[RandomNinjaAtk]

Glad to hear its working, not really sure why you would have needed to do that though...

[DustyTurtleDip]

Glad to hear its working, not really sure why you would have needed to do that though...

In fact, I was wrong.. It did not fix the issue. After all the tracks were imported, I saw that it started downloading, tagging and importing, but I had 0 downloaded files instead of More or less 18k.

So I deleted all the newer files and copied all the old files back in the data folder.

Then I changed :

-e searchSort=album \ with -e searchSort=date \

And now, unless I'm still missing something, I think it's working.

[RandomNinjaAtk]

The settings you changed would not make a difference at all for the issue you were having.

[RandomUser345]

I think I had a similar issue: I was thinking the problem was not with the script, but rather deemix trying to download a specific album. I just removed the album from the missing/wanted list and never saw the problem again. What you're doing is moving the problematic album to another point in the queue either with sorting differently or with deleting the cache and re-search all albums.

[DustyTurtleDip]

The settings you changed would not make a difference at all for the issue you were having.

Well its working now.

I will try and change the setting back to see if the problem come back.

[RandomNinjaAtk]

I think I had a similar issue: I was thinking the problem was not with the script, but rather deemix trying to download a specific album. I just removed the album from the missing/wanted list and never saw the problem again. What you're doing is moving the problematic album to another point in the queue either with sorting differently or with deleting the cache and re-search all albums.

If this is the root cause of the issue, the only way I see to solve it would be a workaround to basically kill the client after a period of time to force it to move on.

[DustyTurtleDip]

I think I had a similar issue: I was thinking the problem was not with the script, but rather deemix trying to download a specific album. I just removed the album from the missing/wanted list and never saw the problem again. What you're doing is moving the problematic album to another point in the queue either with sorting differently or with deleting the cache and re-search all albums.

I tried that but the issue was just repeated on the next album. I also tried removing the artist then the issue was on the next artist.

[DustyTurtleDip]

The settings you changed would not make a difference at all for the issue you were having.

Well its working now.

I will try and change the setting back to see if the problem come back.

I am unable to replicate the issue anymore..