[BUG] Downloaded albums are removed before Lidarr scans it

[AndrewSpec]

I'm using for a few days and it's not working fine.

I can see that script is downloading albums from Deezer and Tidal, setting gain and so on. After that it sends a notification to Lidarr to scan that folder for album import (method NotifyLidarrForImport).

Audio.sh is doing that 3 times and then removes that folder.

But here's the thing:

The task queue is stuck on Rescan folders and won't run any other manual task on demand before the current task ends.

[AndrewSpec]

ok, I've updated once again to the current version from hour ago and it's working fine.

[AndrewSpec]

after some time it's not working. The problem still extists when the Rescan Folders task is working. Previously I thought that was working fine because the Rescan Folders task was not automatically running.

[RandomNinjaAtk]

Its working as designed, not really a bug... An issue with your lidarr and processing things...

Edit: Your Lidarr should be processing 3 tasks at a time... Because it was not doing that, it caused the issue your seeing. Not a bug, but a problem with your lidarr in that instance.

[espentruls]

I've got this exact same issue. When I restart the docker container in UNRAID it then starts to try to import everything that was downloaded by the script on startup.

"DownloadedAlbumsCommandService: Folder/File specified for import scan [/path/to/folder] doesn't exist"

I've tried to reinstall your docker container on different installs of UNRAID and every time I get this bug. I have got autconfig set to true so everything should be correctly set up. It has been working for over a year now, up to recently, so something changed. It downloads and does everything correctly up until it sends the import notification to Lidarr. Lidarr doesn't import and it deletes the folder. and when I restart Lidarr, it then tries to import the folders. It gives the warning line mentioned above.

[Yosh82]

I've been using unraid for a while, and it's still working fine for me. I've never had any specific issues with unraid and LE, as it just uses docker to run.

Have you changed anything with your unraid or docker configs recently? It may be worth checking your mount paths are correct, you may need to add them in lidarr if your docker isn't on the same subnet as your unraid/shares network:

Just a guess, but the error seems to be it can't find the path, so check the mappings.

[espentruls]

I haven't changed anything except update the container. My unraid server failed and I had to restore from a backup, but other than that nothing changed in my config. I run lidarr-extended on the same server that is storing the files so it's on the same subnet/shares. I don't use the /music folder and rather use the config path suggested by Trash. The data/media/music pathing to allow for atomic moving, but It has worked for a year now so it has nothing to do with that either.

When I start the container the script does everything correctly until it ends the import notification to Lidarr. Lidarr does import the first couple of downloaded music and then from then on out, it stops right after the import notification, never importing and trying to download the same albums over again for a second time until marking it as not complete and deleting the folder. If I restart the docker container, Lidarr will then try to import the folders, but by then they have been deleted. and then the script works for 1-2 downloads and the same thing happens.

For me it looks like the import tasks get locked by something and are scheduled but never ran until I restart the container, releasing whatever is causing the lock and then it tries to import everything.

Everything else about Lidarr is working, normal album downloads not from the script downloads and get imported.

[Yosh82]

It might be worth creating a dir/share called "lidarr_bin", set Lidarr to to use the bin and point it to that. When it fails to import (so it can't match with musicbrainz), it will move them to the "bin" usually. Try matching them using musicbrainz / picard. It could just be a case of they can't be matched with musicbrainz so are being deleted.

Or attach the log files from lidarr - System - Log Files for a period where it's happened. It's also worth checking they aren't in your blocklist in lidarr, as that would remove them too. Or install dozzle on unraid which will make going through the logs a bit easier.

[espentruls]

It doesn't fail to import. It never tries to import. The audio scripts run the import notification command, but Lidarr never tries to import them until I restart the container and then it fails because the files were deleted. My blocklist is empty, and its nothing to do with matching because If I delete that same album from the logs to make the script try to download it again and then I restart the container it downloads and import fine the albums that were marked as failed. It works for 1-2 albums and then goes back to the same, error. the script tells Lidarr to import and Lidarr never does, until I restart the container.

I can attach the logs a bit later today when I have more time to look at the problem.

[espentruls]

Audio.txt Lidarr.txt

Thank you for the tip on Dozzle. Great tool

[RandomNinjaAtk]

The root cause is a lidarr issue of some sort and not the scripts. Basically if I made any changes, it's simply going to be a workaround... I haven't experienced this issue in my setup, lidarr should be able to process 3 tasks simultaneously, but it sounds like yours is not doing that.

[espentruls]

That is what I was thinking as well. It looks like something is stopping Lidarr from importing because it's busy doing something else til I restart the container. Are you running the new lidar-extended or are you using the old standalone script yourself? Because of how you've bundled the script I get the same version of Lidarr every time and it has the same bug.

Is there a way to force a different build of Lidarr in your docker container to test if that helps? Im on UNRAID

[RandomNinjaAtk]

I'm using the container on amd64 platform. If your on ARM, that may be your issue is that arm cannot be updated because the image fails to build.... see #242

If you are using ARM, that may explain the issue because you cannot update to the latest and maybe its a bug in that version. Also if it is ARM, I'm not going to fix it, I don't have the cycles to fix something I don't personally use, hence the open issue.

If on amd64, your lidarr should not show there are any available updates... (Current version: 1.2.2.3242 — May 28 2023)

[espentruls]

I'm on 1.2.2.3242 on amd64. Running on a dual Xenon server. The HP Proliant ml350p Gen8. All other *arr containers work. including Lidarr. The script works as well. The only problem is from the 2nd import notification onwards there is something wrong between the script and Lidarr. If I add a new artist from the Lidarr interface and add music that way it imports and everything. So the only bug is when the script tells Lidarr to import. It doesn't import it until I restart the container, then it tries to import everything it tried to from before I restarted it. So the task gets queued but never ran until the container is restarted.

[RandomNinjaAtk]

Based on your earlier audio log, it seems like your only really processing albums on the cutoff list at the moment. Which is something I honestly don't really use, so may be an issue with how Lidarr handles those in comparison to missing albums...

Just a complete and total guess though...

[espentruls]

Same problem with the missing list.

How do you address Lidarr to import the completed downloads from the script? Does the script tell Lidarr via API calls to import the folder using the standard Lidarr import decision maker? Since I can import things I download manually from the Lidarr interface, even after the error occurs, but everything the script tries to notify Lidarr to import only gets queued and doesn't trigger before I restart the container. It only works for the first import the script tells. and then it bugs out and doesn't work until I restart the container.

[RandomNinjaAtk]

Wait a half hour and update to the latest version, it should fix the issue...

[espentruls]

I've already fetched the new update. Can I try it out now or should I still wait 30 mins for something?

[RandomNinjaAtk]

The last image is still building, each commit is a new image build... So give it like 5 min and check for update again. Then you should be good

Edit, this will not fix previous downloads. You may want to wipe the data in /config/extended/cache/*

Keep in mind, that will cause it to retry lots of things...

2nd edit: Also keep in mind, if lidarr is performing any task, the script will wait until lidarr has completed processing all tasks...

[espentruls]

I deleted both cache and logs in the extended folder before running it now.

Seem to come up with a different error now when it looks for missing music. I should probably run a full library scan.

[Warn] ImportApprovedTracks: Couldn't import track /downloads-lidarr-extended/complete/Van Morrison-Moving On Skiffle (2023)-FLAC-279798621-TIDAL/10-Yonder Comes A Sucker-279798631.flac 06/03/2023 3:47:16 PM 06/03/2023 3:47:16 PM [v1.2.2.3242] NzbDrone.Common.Disk.DestinationAlreadyExistsException: Destination /data/media/music/Van Morrison/Van Morrison - Album - 2023 - Moving On Skiffle/0110 - Yonder Comes a Sucker.flac already exists. 06/03/2023 3:47:16 PM at NzbDrone.Common.Disk.DiskTransferService.ClearTargetPath(String sourcePath, String targetPath, Boolean overwrite) in ./Lidarr.Common/Disk/DiskTransferService.cs:line 406 06/03/2023 3:47:16 PM at NzbDrone.Common.Disk.DiskTransferService.TransferFile(String sourcePath, String targetPath, TransferMode mode, Boolean overwrite) in ./Lidarr.Common/Disk/DiskTransferService.cs:line 320 06/03/2023 3:47:16 PM at NzbDrone.Core.MediaFiles.TrackFileMovingService.TransferFile(TrackFile trackFile, Artist artist, List`1 tracks, String destinationFilePath, TransferMode mode) in ./Lidarr.Core/MediaFiles/TrackFileMovingService.cs:line 125 06/03/2023 3:47:16 PM at NzbDrone.Core.MediaFiles.TrackFileMovingService.MoveTrackFile(TrackFile trackFile, LocalTrack localTrack) in ./Lidarr.Core/MediaFiles/TrackFileMovingService.cs:line 86 06/03/2023 3:47:16 PM at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeTrackFile(TrackFile trackFile, LocalTrack localTrack, Boolean copyOnly) in ./Lidarr.Core/MediaFiles/UpgradeMediaFileService.cs:line 79 06/03/2023 3:47:16 PM at NzbDrone.Core.MediaFiles.TrackImport.ImportApprovedTracks.Import(List`1 decisions, Boolean replaceExisting, DownloadClientItem downloadClientItem, ImportMode importMode) in ./Lidarr.Core/MediaFiles/TrackImport/ImportApprovedTracks.cs:line 219

[RandomNinjaAtk]

That might be from legacy tasks that were still queued previously before updating and clearing cache?

[espentruls]

Not legacy.

But the problem is that Tidal and Lidarr are not agreeing on the number of songs in that album. It's marked as missing because the script fetches it from Tidal which downloads 13 songs, but Lidarr is expecting 23 songs in that album. So in fact all the files it downloads are present in that folder as you can see from that warning.

[RandomNinjaAtk]

Nothing can be done about that, Lidarr is supposed to evaluate against all versions of an albums release. The entire process is basically sophisticated guesswork, it does its best to only download a release that should match a musicbrainz release group. But there are no guarantees, its more of a hope for the best and it works pretty well in practice. But all import decisions and data is managed by lidarr.

[RandomNinjaAtk]

Closing, now the script waits for all Lidarr tasks to complete before continuing, which eliminates the issue.

[espentruls]

This didn't fix the issue, Lidarr doesn't import the folder so the script waits forever it seems. It has been waiting now for 40 mins.

2023-06-03 16:15:19 :: Audio :: 1.0.7 :: 1 :: missing :: 3 of 697 :: Level 42 :: 12" Singles and Mixes :: Album :: LIDARR IMPORT NOTIFICATION SENT! :: /downloads-lidarr-extended/complete/Level 42-12 Singles And Mixes (2022)-MP3-332027627-DEEZER 2023-06-03 16:15:19 :: Audio :: 1.0.7 :: STATUS :: LIDARR BUSY :: Pausing/waiting for all active Lidarr tasks to end... [Info] RssSyncService: Starting RSS Sync [Info] DownloadDecisionMaker: Processing 731 releases [Info] RssSyncService: RSS Sync Completed. Reports found: 731, Reports grabbed: 0 2023-06-03 16:26:20 :: QueueCleaner :: 1.0.3 :: Starting... 2023-06-03 16:26:20 :: QueueCleaner :: 1.0.3 :: No items in queue to clean up 2023-06-03 16:26:20 :: QueueCleaner :: 1.0.3 :: Sleeping 15m... [Info] RssSyncService: Starting RSS Sync [Info] DownloadDecisionMaker: Processing 731 releases [Info] RssSyncService: RSS Sync Completed. Reports found: 731, Reports grabbed: 0 2023-06-03 16:41:20 :: QueueCleaner :: 1.0.3 :: Starting... 2023-06-03 16:41:20 :: QueueCleaner :: 1.0.3 :: No items in queue to clean up 2023-06-03 16:41:20 :: QueueCleaner :: 1.0.3 :: Sleeping 15m... [Info] RssSyncService: Starting RSS Sync [Info] DownloadDecisionMaker: Processing 725 releases [Info] RssSyncService: RSS Sync Completed. Reports found: 725, Reports grabbed: 0

[espentruls]

I see that Rescan Folders is running. It runs every 24 hours and takes 5 hours to complete. Making the script only useful for 19 hours at a time. I'll wait and see when the "Rescan Folders" task is complete if the script continues or if the error persists.

I'll report back in 5 hours, to see if it continues.

[RandomNinjaAtk]

You can't have it both ways... It appears that in the latest version, lidarr will not perform imports if its scanning folders... So it has to wait no matter what at this point. If the script didn't wait, it would just end up queuing up tons of data for lidarr to import when it finally does, and I don't see how that could be any more optimal and could likely cause other issues... At the end of the day, your still waiting either way....

[AndrewSpec]

Closing, now the script waits for all Lidarr tasks to complete before continuing, which eliminates the issue.

And that's what I was waiting for. Thanks!

[espentruls]

Quick question. My "Rescan Folders" task will run after every import from the script. Making it download an album, send the import notification to Lidarr. Lidarrr importing it and then running the "Rescan Folders" task. Then it waits 5 hours for it to complete before it goes on to the next. Is it supposed to trigger the "Rescan Folders" task after every import? I see it is scheduled to run every 24 hours but mine will run after every import as well.

And @Yosh82, how does your unraid install of the same container manage to run tasks in parallel, but mine doesn't anymore? Are you changing some standard settings in the installation process? Are you using the autoconfig settings? Mine used to work flawlessly until now.

[Yosh82]

I haven't checked mine at since the update yesterday, but when I looked at your logs, I saw this error a fair few times, not sure what it is but it's not in my logs:

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:48:59.9|Info|ConsoleApp|Exiting main. 2023-06-03 11:49:00.0|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.2|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.2|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

2023-06-03 11:49:00.3|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent]

[v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; message: Container is disposed and should not be used: "container without scope is disposed! You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())" at DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) in //src/DryIoc/Container.cs:line 14393 at DryIoc.Container.ThrowIfRootContainerDisposed() in //src/DryIoc/Container.cs:line 709 at DryIoc.Container.ResolveAndCache(Int32 serviceTypeHash, Type serviceType, IfUnresolved ifUnresolved) in //src/DryIoc/Container.cs:line 447 at DryIoc.Container.System.IServiceProvider.GetService(Type serviceType) in //src/DryIoc/Container.cs:line 338 at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType) at NzbDrone.Core.ThingiProvider.ProviderFactory2.GetInstance(TProviderDefinition definition) in ./Lidarr.Core/ThingiProvider/ProviderFactory.cs:line 135 at System.Linq.Enumerable.SelectListIterator2.ToList() at NzbDrone.Core.Notifications.NotificationFactory.OnTrackRetagEnabled() in ./Lidarr.Core/Notifications/NotificationFactory.cs:line 85 at NzbDrone.Core.Notifications.NotificationService.Handle(TrackFileRetaggedEvent message) in ./Lidarr.Core/Notifications/NotificationService.cs:line 339 at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)

It may we worth installing a second container for LE and test that with just one artist and see if that downloads ok (ensure you set a new appdata path for the test container).

Nothing unique with my config, I've used the auto seetings script before which worked fine. Have you checked permissions for "Host Path for /downloads-lidarr-extended:" - I would assume it would show access issues in the log, but I noticed in the logs that it can't find the files, so maybe it's trying to access old files on that which it can't see now / doesn't have permissions to?

Strange one as you say it does work sometimes, so possibly permissions related on the old downloaded files?