Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Leading ellipsis for nested folder names replaced with dot on import #2371

Open
1 task done
gaizaharduz opened this issue Aug 21, 2021 · 3 comments · May be fixed by #2372
Open
1 task done

[BUG]: Leading ellipsis for nested folder names replaced with dot on import #2371

gaizaharduz opened this issue Aug 21, 2021 · 3 comments · May be fixed by #2372
Labels
Area: Organizer Issue is related to the Organizer Type: Bug Issue is a bug Type: Enhancement Current situation is suboptimal and could use improvement.

Comments

@gaizaharduz
Copy link

gaizaharduz commented Aug 21, 2021

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I saw this issue was reported and fixed before in #604, but I think it was probably reintroduced with the recently added nested path feature.

Using a track format such as:

{Album Title}/{Artist Name} - {Album Title} - <etc>

When importing an album with the name ...My Album..., it gets renamed to:

.My Album./My Artist - .My Album. - <etc>

Expected Behavior

Despite the name being a bit weird, the main issue is that the leading dot of course causes the album folder to be viewed as hidden, and ultimately ignored by Lidarr on re-scan (and also other software such as Jellyfin).

Steps To Reproduce

No response

Environment

- OS: KDE Neon
- Lidarr: Lidarr 0.8.1.2135
- Docker Install: Yes
- Using Reverse Proxy: No
- Browser: Vivaldi

What branch are you running?

Master

Anything else?

I think that calling CleanFolderName instead of using the FileNameCleanupRegex directly here would at least solve the hidden file issue:

component = FileNameCleanupRegex.Replace(component, match => match.Captures[0].Value[0].ToString());

I also noticed that Radarr previously had a similar issue and introduced a test case, which may be a good idea to prevent reoccurrence: Radarr/Radarr@b336cb0

AB#1483

@gaizaharduz gaizaharduz added Status: Needs Triage New Issue needing triage Type: Bug Issue is a bug labels Aug 21, 2021
gaizaharduz added a commit to gaizaharduz/Lidarr that referenced this issue Aug 21, 2021
@gaizaharduz gaizaharduz linked a pull request Aug 21, 2021 that will close this issue
2 tasks
@scottfridwin
Copy link
Contributor

Just recently ran into the issue in 2 different ways:

  1. Importing an artist folder where some albums begin with '...' (such as Metallica/...And Justice For All). The album is not recognized during the import.
  2. After import and all files names are set, a refresh will not recognize files in a folder beginning with '.' (such as Slipknot/.5- The Gray Chapter), which results in the album appearing as missing.

To me, the second issue is more concerning since it essentially results in those files disappearing. Lidarr will try to query indexers for replacements and potentially download over and over again.

@chrisjameschamp
Copy link

What's the status on this being fixed, I see over a year ago it is marked as fixed but never merged

@bakerboy448 bakerboy448 added Type: Enhancement Current situation is suboptimal and could use improvement. Area: Organizer Issue is related to the Organizer and removed Status: Needs Triage New Issue needing triage labels Dec 19, 2022
@ohsnapword
Copy link

I am still seeing this behavior in version 1.1.1.2762.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Organizer Issue is related to the Organizer Type: Bug Issue is a bug Type: Enhancement Current situation is suboptimal and could use improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants