Replies: 2 comments 2 replies
-
|
Sounds like an upstream lidarr issue. Scripts only do what lidarr tells it to… and lidarr manages all the files. Edit: 2nd edit: |
Beta Was this translation helpful? Give feedback.
-
|
Another thought, maybe disabling album disambiguation in the file/folder naming would resolve it… That’s assuming it’s importing the release to the same release group. It’s something you could try to see if it fixes it… |
Beta Was this translation helpful? Give feedback.
-
|
So i did some more digging on my specific setup and what i changed recently. I believe the issue stems from mounting the volume to a SMB share using cifs and not specifying UTF-8 (or some people alluded to cifs just not doing well with non-english characters in general) I switched back to mounting the drive directly (on wsl2) and lidarr definitely detected some changes, right now it's in the process of re-importing everything i believe. Hopefully just everything i gathered after making the change. I'll post here what the fallout ends up being, helps to articulate what is actually going on 😊 |
Beta Was this translation helpful? Give feedback.
-
|
No issues to report, it appears it was entirely cifs through wsl2. Lidarr has moved all files to correct directories. I have a few empty albums with only meta data in them but its not worth the hassle to go and delete them at this point. |
Beta Was this translation helpful? Give feedback.
-
Attached image shows it best but yeah. The correctly named files that are imported were done on 1/29/24 but it looks like lidarr recently imported the same album again on 02/14/24 but with a messed up file name. Files exist in both folders, the new one looks more complete even as far as lyrics go.
I can create a issue but i wanted to make sure this wasn't something stupid i am doing before clogging up that area with false reports.
Beta Was this translation helpful? Give feedback.
All reactions