🚀 Feature Request: Support Folder Organization Based on Release Type (Single, EP, LP, Mixtape) #4300

Closed
opened 2026-02-20 03:03:32 -05:00 by deekerman · 1 comment
Owner

Originally created by @emigrating on GitHub (Jul 26, 2025).

Is there an existing issue for this?

  • I have searched the existing open and closed issues

Lidarr currently places all music releases for a given artist into a single folder, regardless of whether the release is a Single, EP, LP, Mixtape, or Compilation. This results in disorganized file structures, making it difficult to curate, back up, or browse large discographies — especially for artists with diverse catalogs.
While Lidarr categorizes release types in its UI and metadata profiles (e.g. “Singles,” “EPs,” “Albums”), this classification is not reflected in the folder structure, nor exposed via the renaming engine. The user has no way to separate these releases physically on disk using Lidarr’s automation.

Describe the solution you'd like

Introduce support for folder-level organization based on release type, utilizing the MusicBrainz metadata that Lidarr already ingests. Specifically:

  • Add a new {Release Type} token to Lidarr’s renaming and folder template engine
  • Allow users to define custom folder paths such as:

{Artist Folder}/{Release Type}/{Album Title}/{Track Number} - {Track Title}

Example resulting structure:

  • /Radiohead/Singles/Everything In Its Right Place/

  • /Radiohead/EPs/My Iron Lung/

  • /Radiohead/Albums/Kid A/

  • Provide global or per-artist toggles to enable release-type sorting

  • Fall back gracefully to existing folder formats if Release Type is unavailable

Describe alternatives you've considered

  • Manual file sorting: Users can move singles and EPs manually, but this breaks Lidarr’s automated rename/import flow and requires locking files or using .ignore tags.
  • Post-processing scripts: External tools (like FileBot or bash scripts) can reorganize files post-import, but this adds complexity and duplicates Lidarr’s role.
  • Multiple artist entries: Some users create pseudo-artist folders like “Artist - Singles,” which complicates tracking and clutters the UI.

None of these alternatives provide a seamless, native solution for organizing music by release type within Lidarr itself.

Anything else?

  • Lidarr already fetches release type from MusicBrainz and uses it internally — this data is surfaced in the UI and likely stored in the database.
  • This proposal doesn’t require a major rewrite of metadata ingestion, but rather an extension of existing data into file system logic.
  • Folder-level organization based on metadata is already standard in apps like Sonarr and Radarr — Lidarr would benefit similarly.
  • Would gladly help test the implementation or provide mock naming formats based on real-world libraries.
Originally created by @emigrating on GitHub (Jul 26, 2025). ### Is there an existing issue for this? - [x] I have searched the existing open and closed issues ### Is your feature request related to a problem? Please describe Lidarr currently places all music releases for a given artist into a single folder, regardless of whether the release is a Single, EP, LP, Mixtape, or Compilation. This results in disorganized file structures, making it difficult to curate, back up, or browse large discographies — especially for artists with diverse catalogs. While Lidarr categorizes release types in its UI and metadata profiles (e.g. “Singles,” “EPs,” “Albums”), this classification is not reflected in the folder structure, nor exposed via the renaming engine. The user has no way to separate these releases physically on disk using Lidarr’s automation. ### Describe the solution you'd like Introduce support for folder-level organization based on release type, utilizing the MusicBrainz metadata that Lidarr already ingests. Specifically: - Add a new `{Release Type}` token to Lidarr’s renaming and folder template engine - Allow users to define custom folder paths such as: {Artist Folder}/{Release Type}/{Album Title}/{Track Number} - {Track Title} Example resulting structure: - `/Radiohead/Singles/Everything In Its Right Place/` - `/Radiohead/EPs/My Iron Lung/` - `/Radiohead/Albums/Kid A/` - Provide global or per-artist toggles to enable release-type sorting - Fall back gracefully to existing folder formats if `Release Type` is unavailable ### Describe alternatives you've considered - **Manual file sorting:** Users can move singles and EPs manually, but this breaks Lidarr’s automated rename/import flow and requires locking files or using `.ignore` tags. - **Post-processing scripts:** External tools (like FileBot or bash scripts) can reorganize files post-import, but this adds complexity and duplicates Lidarr’s role. - **Multiple artist entries:** Some users create pseudo-artist folders like “Artist - Singles,” which complicates tracking and clutters the UI. None of these alternatives provide a seamless, native solution for organizing music by release type within Lidarr itself. ### Anything else? - Lidarr already fetches release type from MusicBrainz and uses it internally — this data is surfaced in the UI and likely stored in the database. - This proposal doesn’t require a major rewrite of metadata ingestion, but rather **an extension** of existing data into file system logic. - Folder-level organization based on metadata is already standard in apps like Sonarr and Radarr — Lidarr would benefit similarly. - Would gladly help test the implementation or provide mock naming formats based on real-world libraries.
deekerman 2026-02-20 03:03:32 -05:00
Author
Owner

@emigrating commented on GitHub (Jul 26, 2025):

Turns out there is already an (undocumented??) {Album Type} token, so closing this. My bad.

@emigrating commented on GitHub (Jul 26, 2025): Turns out there is already an (undocumented??) {Album Type} token, so closing this. My bad.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Lidarr#4300
No description provided.