Using extended/custom tags

[simonbun]

Whilst I appreciate that OpenSubsonic/LMS already supports an extensive set of tags, it doesn't, and never will support everything I want it to.

To support additional tags (those that don't change the meaning or aggregation of existing ones) whilst keeping changes to a minimum and ensuring they make it to downstream clients e.g. Symfonium, I was thinking that an abstraction layer might be a good option.

I appreciate that VERSION is possibly going to make it into the OpenSubsonic standard at some point, but let's use it as an example. VERSION is used to hold album disambiguation information e.g. Deluxe Edition; because LMS/OpenSubsonic doesn't support it I have albums that appear duplicated in my album listing:

The Dark Side Of The Moon
The Dark Side Of The Moon  (tagged with VERSION = 'Experience Version')

If there was a way to tell LMS to read the VERSION tag and to append it to the ALBUM tag (an already supported object in LMS/OpenSubsonic) my problem would be solved, and with little code change.

Using the foobar2000 syntax as example, my current configuration could look something like:

Album: %album%[' ('%version%')'][' ['%remasterdate%' Remaster]']	The Dark Side Of The Moon (Experience Version) [2011 Remaster]
Title: %title%[' ('%subtitle%')'][' ['%tracktype%' Track]']		Speak To Me (Live) [Bonus Track]

The tags within [] are evaluated and if not empty the expression is added.

With such a configuration in the lms.conf, LMS would only need to:

• Read the additional tags

• Modify the existing supported tags

Nothing else will need to be changed and the modified values would flow through to downstream clients.

[epoupon]

Hello!
I do understand your use case and will think about it. I strongly believe in tags though, but that's indeed a lot of work to support all the relevant ones from the servers to the clients using the OS API.
I guess these different albums already have different release mbid (but same release group mbid) and are already split using release mbid?
(I do plan to think about a way to use the release group mbid to better group releases like that, while keeping the UI as clean as possible)

[simonbun]

I strongly believe in tags though, but that's indeed a lot of work to support all the relevant ones from the servers to the clients using the OS API.

I'd imagine it to be endless, and it still wouldn't support my custom ones.

I guess these different albums already have different release mbid (but same release group mbid) and are already split using release mbid?

They're now split on barcode 👍

I don't use many musicbrainz tags, and in some scenarios they won't help because I don't like box-sets grouped (although I'm sure I could create my own ids to force the behaviour).