Support exact filesystem structure in subsonic api indexes/musicdirectory (as option)

[acroyear]

Is your feature request related to a problem? Please describe.

My collection is rather large and I tend to keep things organized on the file-system first, ID3 second. In particular, my classical collection divides things up by musical period (e.g., early 19th century Romantic, late 19th Century Romantic German, late 19th century Romanic Russian etc). Subsonic's original index/musicDirectory, which returns the filesystem's layout rather than the ID3, is perfectly suited for this.

Navidrome doesn't support this currently.

Describe the solution you'd like

An option in the config file (default false - if the user doesn't need it, they just leave it alone) that would tell the API to return the filesystem layout for indexes/musicDirectory instead of the ID3 sorting of Artist/Album tags. If off and by default, the application does what it currently does.

Describe alternative solutions that would also satisfy this problem

Can't really come up with any.

Additional context

I'm aware that if Navidrome isn't storing this info as part of the scan results, such storage will need to be added to the DB and that can take time to build out and increase the size of the sqllite file.

[acroyear]

hmm...an initial 'stab', a little less efficient, could be to return the file system 'live' since it is just basic local file system calls, and just filter the results down to just songs and folders. when song files are reached, match them up against the 'real path' in the DB. Nothing new needs to be cached.

Since the API is returning strings for IDs and the physical file path is guaranteed to be unique, the file path (relative to the root music folder) could be the return value for the ID field. No need to allocate a GUID if there's nothing in the DB. Song would have to change to give the parent file path as the parentId. (What would break until DB data is stored would be the 'star' endpoint applied to musicDirectory - star2 would work but the music directory star wouldn't)

that would get slow over a network/cloud drive, but again it would only happen when the owner of the server specifically turned the feature on, so not an issue for most users.

[RedKage]

Sounds like #1309

[simpz]

To provide this will allow more people to migrate from subsonic and it is part of the API for subsonic (the main reason I took subsonic over other systems). Even a sub-optimal solution as suggested by acroyear would be absolutely fine.

[Neurrone]

+1 to how important this feature is to migrate from Subsonic / Airsonic etc.

This is the only missing feature before I can migrate to Navidrome.

[Trufax]

+1 from my side as well. Really like Navidrome but folder based browsing would be the killer feature for people coming form *sonic's and make migration easy.

[mattneub]

I would like to echo the need for something along these lines.

First I would like to say how appreciative I am of the tremendous work that has been put into creating Navidrome and making it available and providing clear and simple instructions. I found that to obtain Navidrome and get it up and running and serving my huge Classical music collection was extremely easy and fast. The built-in web interface is pleasant and easy too. All quite brilliant, there's no doubt about it.

Having said that, I would now insist that the great shortcoming of most music organization systems, including the usual tags, is that they do not apply to classical music. In classical music the individual song is of reduced importance, because different "songs" can be movements of a single piece of music; more important, the artist is almost downright irrelevant — and thus, to put the artist front and center in the "folder" organization as Navidrome does, is simply wrong. A single piece of multimovement (multisong) music can have different artists for different movements of the very same work. And besides, personally I don't really care about who the artist is except as a piece of secondary information. The organizational principle for classical music is, plain and simple, the composer.

But composer information, even though it appears in the tags, is apparently ignored by the Subsonic API. The way I make up for that when serving with Subsonic is by organizing the folders by composer! In other words, I use folder organization as a stand-in for the key organization principle that the Subsonic API ignores. For example, I have dozens of Beethoven albums, but what unites them, and what I need to see at top level, is that they are by Beethoven. So they are all in a Beethoven folder — and Subsonic knows this, and Subsonic clients are able to display the folder organization. Problem solved.

But Navidrome does not obey the rules in this regard. And this is very odd, because Navidrome knows the folder organization — and do not try to tell me it doesn't, because it clearly does. When I do a Get Info on a song, I am correctly shown the folder hierarchy containing that song on my server's music folder! Thus, Navidrome has the information it would need in order to tell a client correctly what the folders are.

If Navidrome is not going to organize its "folder" information based on the actual folder, but would rather use tags, I can accept that, I suppose. But then I need Navidrome to do this, not based on the irrelevant Artist information, but based on spare tags that I am willing to use (misuse) as the basis of this organizational display. For example, Navidrome could use the composer tag! or it could use the genre tag, or some other "spare" tag that I could set, as the basis for the "folder" information it provides to clients. In this way we might be able to arrive at a useful compromise that takes the path of least resistance.

In fact, I can see one way forward in this regard: I could "misuse" the Album Artist tag to represent the top-level "folder". I have noticed that Navidrome uses this, in preference to the Artist tag, if the former exists, in its listing of the "folder" information.

Nevertheless I would prefer not to have to do this, for the simple reason that a folder is not an artist — and some clients, such as Play:Sub, permit the display of each of these categories, separately. At present, of course, the Artists display and the Folders display for Navidrome on Play:Sub are identical. But what I'm suggesting is that this is quite obviously wrong.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[simpz]

Sad this one has been closed (as have all requests like it). It seems a very popular request, and would implement the the biggest missing piece of functionality from the Android clients

[mattneub]

Well, it simply means that using navidrome is not an option for me. It's a pity but there it is.

[deluan]

For future reference: https://www.navidrome.org/docs/faq/#can-you-add-a-browsing-by-folder-optionmode-to-navidrome

[github-actions[bot]]

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.