Ability to change playlist scan functionality to only scan a specific mount

[bjhiltbrand]

Currently, playlists are automatically scanned and imported if they are found anywhere under the /music directory. If there are playlists that one doesn't necessarily want imported from that directory, they have no control over whether or not those specific playlists get picked up and imported.

I would propose that a check be made at startup to see if a /playlists directory has been mounted. If so, then only load playlists from that mount and not from a recursive check of the /music directory.

A docker-compose file could then look something like this for volumes:

- /volume1/docker/navidrome/data:/data
- /volume1/Media/Music:/music:ro
- /volume1/Media/Playlists:/playlists

and a user could control what playlists are imported into Navidrome.

[adamdmoss]

I would propose that a check be made at startup to see if a /playlists directory has been mounted. If so, then only load playlists from that mount and not from a recursive check of the /music directory.

I think it'd be simpler and less surprising if the playlist import path could just be configured separately from the music library path.

[deluan]

I was hoping to tackle this as part of the Multi-Library support (#192), but in the interim I may introduce something to allow the user to specify where Navidrome should look for playlists.

[anarcat]

I was hoping to tackle this as part of the Multi-Library support (#192), but in the interim I may introduce something to allow the user to specify where Navidrome should look for playlists.

this would fix the problem i described in #1237 quite elegantly. to avoid seeking there, let me rephrase:

My problem is that the current playlist import code imports a lot of playlists (hundreds!) which are mostly useless because they are .m3u files shipped within album directories. so, basically, many albums show up as playlists as well, and drown out my normal playlists.

having a specific folder for playlists would fix this issue, provided that the playlists are parsed as relative to the top-level mount, however. a common mistake when implementing this is to look for relative paths from within the playlist directory... in the current setup, this requires me to put the playlist mount at the top level (in /music) and other music mounts under it, which is not super elegant. it kind of works by sheer luck here. ;)

[Forceflow]

@anarcat: It's probably besides the point, but do you end up using these album-specific playlists a lot? I know Bandcamp releases sometimes come with them, but I'm always listening in a context where the album tags are used to play an album, and not an album-specific playlist.

A good old find + rm will get rid of those playlists for you, if they are annoying atm ;)

[anarcat]

I don't even remember *ever* using such playlists. I find them completely useless, but I'd understand why they were historically useful. Right now it's just noise. :)

[metalheim]

I also endend up deleting all these playlists, because they annoyed me and I had no use for them.
But I get that isn't a solution for everyone

[Forceflow]

I don't even remember ever using such playlists. I find them completely useless, but I'd understand why they were historically useful. Right now it's just noise. :)

If you're on Linux / WSL / Mac:

find "/path/to/music/folder" -name '*.m3u' to see the playlist files found in the directory structure.
find "/path/to/music/folder" -name '*.m3u' -exec rm -v {} \; to delete them (obviously, move your actual useful playlists to somewhere else first)

Obviously change the *.m3u path to other extensions when you've got playlists in other formats :)

Anyway, back on topic: a designated playlist directory that when set only makes Navidrome look for playlists there would be the cleanest solution, imho.

[anarcat]

as a workaround for this, I did the following hack over the sqlite database directly:

DELETE FROM playlist WHERE path LIKE "/music/%/%";

this implies that the playlists care about are at the root of /music. if they are elsewhere, you'll need to tweak the SQL request. then, of course, you also need to tweak the config to disable auto loading those playlists (ND_AUTOIMPORTPLAYLISTS/AutoImportPlaylists set to false). enjoy!

[deluan]

Added new option: PlaylistsPath: list of path globs from where ND should import playlists. Default: '.:**' (or '.;**' in Windows, meaning all folders and subfolders under MusicFolder.

Examples, assuming MusicFolder is /music:

• To only search for playlists at the root of MusicFolder: '.'
• To only search for playlists in folder /music/playlists: 'playlists'
• To search for playlists in folder /music/playlists and its subfolders: 'playlists:playlists/**' (or 'playlists;playlists\**' in Windows)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.