[Feature Request] Optional separate output root for singles & playlist tracks (so an "Albums" library can stay album-only)

[thisisandrewv]

Summary

Would it be possible to add an optional second output root, so album downloads can land in one folder and standalone singles + playlist tracks in another? The idea is to let people who want it run two separate media-server libraries — one for full albums, one for singles/playlists. It'd be fully opt-in: nothing changes unless the second path is set.

Why I'd find this useful

Mostly it's about keeping my Albums library tidy. When singles and one-off playlist tracks land in the same library as my albums, the album view gets cluttered with loose tracks and single-song "albums," and it's harder to browse actual full albums. If those went to a separate library, the album view stays clean.

The nice part is that splitting them doesn't really cost anything: Plex playlists can include tracks that live in a different library, so I can still keep playlists spanning both. The split just makes everything feel more organized without breaking playlist functionality.

What makes it tricky today

From poking around the code, a few things make this hard with current settings:

• Everything is written under one root (soulseek.transfer_path), and templates only pick sub-folders under it — so two libraries end up scanning the same tree.
• A single/playlist track that belongs to an album is treated as album content (build_final_path_for_track branches on album_info.is_album), so it routes into the album tree and shows up in the album library. I couldn't find a way to keep those out.
• "Organize by playlist" / materialize are symlink/copy views of the one real file, which still lives in the album tree — so the album library still sees it.

One approach that worked for me

For what it's worth, the thing that got me there was an optional key like file_organization.singles_transfer_path, with build_final_path_for_track choosing the base root from the existing is_album_download flag:

• is_album_download == True → transfer_path (unchanged)
• is_album_download == False → the new root (when set; otherwise it falls back to transfer_path, so it's a no-op by default)

is_album_download seemed like a natural fit, since it's already set consistently for the album-vs-not cases:

Source | Value -- | -- Album download / album auto-import / watchlist album | True Library Reorganize (core/library_reorganize.py) | True Standalone single (core/imports/resolution.py) | False Playlist / organize-by-playlist (core/playlists/organize_download.py) | False Discovery (core/discovery/sync.py) | False

Routing on it handled the awkward cases nicely — a playlist track that belongs to an album still goes to the singles/playlist root, and running Reorganize later keeps albums in the album root. A Settings field and a Docker mapping would round it out if it ever fit the roadmap, but those are just nice-to-haves.

Alternatives I tried

• Templates with ${albumtype} (Albums/… vs Singles/…): close, but couldn't force a playlist's album tracks into the singles tree, so the album library still picked them up.
• Playlist materialize in copy mode: still leaves the original in the album tree, so it double-counts.