[BUG] - Lidarr - Are download paths hard coded?
Closed this issue · 4 comments
Application
Lidarr
Host platform
Unraid
Script
Lidarr Extended
Script Version
Latest release as of 04/10/2024
Describe the bug
I'm setting the download path to /data/processing/downloads/music/incomplete and /complete but the path being used is /data/processing/downloads/music/incomplete/audio/incomplete (behavior also exists when using /mnt/user/media prefix, which /data is a container alias for)
To Reproduce
Steps to reproduce the behavior:
- set path in extended.conf
- run script
Expected behavior
Downloads reflect path set in extended.conf
Logs/Screenshots
TLDR /audio/incomplete is being appended to the download path I set
This might be unrelated and a separate configuration error or something but my downloads are also like... phantom downloading it seems. The script logs appear to be downloading stuff but they're not actually appearing in the directory. Idk where they're going/what's happening to them. They're not in the default appdata folder either lol. Idk if these errors are related but they're the only thing I see:
I did have successful downloads and imports when using the stock path settings so I'd hope it's not something I did wrong. The reason I want the paths changed from default is so I can have atomic moves (not needing to move downloaded songs from appdata -> my media folder). I guess maybe I could set the main docker path to /mnt/user/ and specify the full long paths from there (/mnt/user/appdata/lidarr/extended/downloads/audio/incomplete and /mnt/user/media/processed/Music) but I've never setup a container with such high level paths before
Sorry I keep adding to this, but it also appears the "auto config" ignores any custom paths too and just configures with the default paths. These are fresh paths I just made and the fresh download folder config it made. This might be intended behavior and users are expected to not use auto config if they're customizing paths, and that's fine but just figured I'd mention in case you want the auto config to reflect changes. Might be worth adding a comment in the path section to mention you'll wanna turn auto config off if they're to intended to be hard coded.
I think I've sort of achieved my desired atomic move functionality by heavily modifying all of the paths to use a high level mapping that I mentioned above (/mnt/user/ for everything within Lidarr and retaining the default extended.conf paths to download within appdata instead of my dedicated media processing folder like I would prefer) but I'll wait to hear your thoughts on whether you don't mind this much intervention to get that outcome. It took me a solid couple hours of working through these quirks to get here.
(my modified paths)
It also may have already been using atomic moves idk I'm kind of dumb when it comes to this stuff but my understanding was that it wouldn't with the default config.
So it was hardcoded and I just fixed that, however... The script has no way to update an existing client that was already added to Lidarr. So once the client has been added, it's whatever path it was originally set at.
If using queuecleaner, it should only at most ever be a temporary location.
This should be resolved with the latest change.
Sweet thank you. One extra question.
"If using queuecleaner, it should only at most ever be a temporary location."
Could you clarify what you mean by that? Is "it" in this case the download/import paths? What does queue cleaner do being on vs off and when would you use it/not use it? Just wanna gain a little better understanding of how these scripts work and how I should be configuring them.