Curious about new option in Lidarr extended.conf

[stayupthetree]

Noticed this line added to the extended.conf. Curious about configuration. Is this if I setup my Lidarr instance with SAB? Is there any particular mapping I need to do in my docker setup?
importPath="/config/extended/import" # OPTIONAL, only change if needed.... Completed downloads are stored here for the Usenet Blackhole client to import from. When Using queue cleaner, failed imports will be automatically cleaned up.

[RandomNinjaAtk]

The change allows you to see the completed downloads in Lidarr web interface on the queue page.

It shouldn’t interfere with sab

[PapaBearDoes]

New to the script, but it's working great. Just one question, because I don't see what the script is doing in lidarr (I can only see what's happening queue-wise by attaching to and watching the docker logs). Is there a particular setup I should be using in regards to lidarr / SAB to enable this feature? (or am I just dumb and missed a step somewhere?)

P.s. I feel like I'm missing something silly ...

[stayupthetree]

ok cool. Ill setup sab later. Quick question, did something change? Im redoing my server and I swear I had this setup previously without any download client configured in Lidarr. I only used the deezer/tidal setup, but now unless I add an import folder to the download client section things get downloaded but nothing gets imported to Lidarr when "LIDARR IMPORT NOTIFICATION SENT!" happens.

[RandomNinjaAtk]

So a bug was introduced when attempting to resolve another request. I just pushed a fix for the bug... Restart (twice, first to pull the script, 2nd to run the script...) and pull the latest script and it should be resolved

Reference: #233

[clayboyx]

I set a new import path but Lidarr is not post processing the files it downloads to my root music folder how can i fix this or was this part of the bug

[stayupthetree]

Its workingISH. What it is doing currently is downloading the albums, and not importing them YET. Once the script reaches the end of its current run and restarts in 15 minutes, then it is picking up the albums for import. The albums are remaining however in the import folder and not being removed. I am going to add an artist and let it run overnight to see if that corrects itself with cleanup

[stayupthetree]

Looks like everything is working now. Im now running into permission issues in the final destination. Everything is owned by nobody:users except for the music files now for some reason. The music added last night all have nobody:users as owner.
The only thing I've changed on my end this morning was the default import folder.

[Warn] UpdateTrackFileService: Unable to set date of file [/data/media/music/Noah Kahan/Noah Kahan - Single - 2017 - Fine/0101 - Fine.flac]

[v2.2.3.4098] System.UnauthorizedAccessException: Access to the path '/data/media/music/Noah Kahan/Noah Kahan - Single - 2017 - Fine/0101 - Fine.flac' is denied.
---> System.IO.IOException: Operation not permitted
--- End of inner exception stack trace ---
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func2 errorRewriter) at System.IO.FileStatus.SetAccessOrWriteTime(String path, DateTimeOffset time, Boolean isAccessTime) at System.IO.File.SetLastWriteTime(String path, DateTime lastWriteTime) at System.IO.Abstractions.FileWrapper.SetLastWriteTime(String path, DateTime lastWriteTime) at NzbDrone.Common.Disk.DiskProviderBase.FileSetLastWriteTime(String path, DateTime dateTime) in ./Lidarr.Common/Disk/DiskProviderBase.cs:line 350 at NzbDrone.Core.MediaFiles.UpdateTrackFileService.ChangeFileDate(TrackFile trackFile, Artist artist, List1 tracks) in ./Lidarr.Core/MediaFiles/UpdateTrackFileService.cs:line 79

[RandomNinjaAtk]

Lidarr itself manages the files in the final destination. So it’s out of scope for support here.

[stayupthetree]

Im happy to hit them up, but if I change back to the default import folder in extended.conf the issue goes away. Worked around it with folder mapping in my compose file to /config/extended/import