[BUG] Downloaded albums are removed before Lidarr scans it #248
Comments
|
ok, I've updated once again to the current version from hour ago and it's working fine. |
|
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. |
|
Its working as designed, not really a bug... An issue with your lidarr and processing things... Edit: |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Thank you for the tip on Dozzle. Great tool |
|
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. |
|
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. Is there a way to force a different build of Lidarr in your docker container to test if that helps? Im on UNRAID |
|
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) |
|
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. |
|
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... |
|
Same problem with the missing list. How do you address Lidarr to import the completed downloads from the script? |
Any running task will now cause the script to pause.... #248 - Fix.... ?
|
Wait a half hour and update to the latest version, it should fix the issue... |
RandomNinjaAtk
added
bug
|
I've already fetched the new update. Can I try it out now or should I still wait 30 mins for something? |
|
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... |
|
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.
|
|
That might be from legacy tasks that were still queued previously before updating and clearing cache? |
|
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. |
|
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. |
|
Closing, now the script waits for all Lidarr tasks to complete before continuing, which eliminates the issue. |
|
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.
|
|
I see that Rescan Folders is running. I'll report back in 5 hours, to see if it continues. |
|
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.... |
And that's what I was waiting for. Thanks! |
|
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. |
|
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; 2023-06-03 11:48:59.9|Info|ConsoleApp|Exiting main. [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.1|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.2|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.2|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 2023-06-03 11:49:00.3|Error|EventAggregator|NotificationService failed while processing [TrackFileRetaggedEvent] [v1.2.2.3242] DryIoc.ContainerException: code: Error.ContainerIsDisposed; 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. Strange one as you say it does work sometimes, so possibly permissions related on the old downloaded files? |
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.
The text was updated successfully, but these errors were encountered: