Questions about tag formatting limitations

[eseb63]

Hello,

I would like to handle work rating, to see quickly which works i prefer among all those of a composer.

For that, i thought to use a WORK_RATING tag and tag formatting to concatenate the work name with it :

• i would need Work.displayFormat but work is not allowed
• i can't use Work.indexFormat because it combines multiple tag values to create one concatenated value instead of create multiple tag values, which prevents other settings from working (see https://forum.minimserver.com/showthread.php?tid=7504)
• using tagupdate works, but it would require to handle hundreds or thousands entries : it would be tedious, difficult to maintain, and i guess it's not recommanded to use such a huge file.
  

So, my questions are :
1) why is displayFormat only allowed for some tags and not work in this case ? would it be possible to add work in the allowed tags ?

2) you told me earlier that indexFormat was developped on the displayFormat model : i understand it was easier, but the goal is not the same ? while it's logic to combine multiple tag values in one for displayFormat, i don't see in which use cases it is useful to do so for indexformat : any example ?

[simoncn]

displayFormat is used for tags that correspond to UPnP properties sent by MinimServer to the control point in DIDL-Lite (album, artist, title, etc.) There is no DIDL-Lite property corresponding to Work.

A user might want the Work index to show more than just the Work name. For example, they might want to see Artist names as well. They can do this by setting these properties:

aliasTags: Work:WorkTag
itemTags: WorkTag
tagFormat: Work.indexFormat={$worktag^$artist^ [^]}

This produces a single Work index entry showing the work name and all artist names for this performance of the work. This is what most users would want to see.

This works well if all files have a Work tag but not so well if some files don't have this tag. These files will have an entry in the Work index showing artists but without a work name. I am considering what can be done about this.

[eseb63]

(18-04-2025 19:45)simoncn Wrote:  displayFormat is used for tags that correspond to UPnP properties sent by MinimServer to the control point in DIDL-Lite (album, artist, title, etc.) There is no DIDL-Lite property corresponding to Work.

So displayFormat was required for these tags to support DIDL-lite controlpoint needs, but what prevents implementing displayFormat for other tags and other needs?

Thanks for the indexFormat example : it's more a performance index rather a work index ...

Besides the specific case that I mentioned in the thread of the first post, it does not work well either in the more general case of works that are part of a group: in this case we get a value concatenating all the works in the group: very annoying

[simoncn]

(18-04-2025 20:53)eseb63 Wrote:  So displayFormat was required for these tags to support DIDL-lite controlpoint needs, but what prevents implementing displayFormat for other tags and other needs?

This is what indexFormat is doing. As you have seen, this doesn't work exactly the way you would like because it was designed for a different purpose.

Quote:Thanks for the indexFormat example : it's more a performance index rather a work index ...

I am not sure what you mean by "performance index." I gave this example because you asked for an indexFormat example where combining multiple values of the same tag is useful.

Quote:Besides the specific case that I mentioned in the thread of the first post, it does not work well either in the more general case of works that are part of a group: in this case we get a value concatenating all the works in the group: very annoying

See my first comment above.

[eseb63]

(18-04-2025 22:05)simoncn Wrote:  

Quote:Besides the specific case that I mentioned in the thread of the first post, it does not work well either in the more general case of works that are part of a group: in this case we get a value concatenating all the works in the group: very annoying

See my first comment above.

With your example, the concatenation of work and artists concern all artists involved in this work execution : it makes sense.

But with the setting :

work.indexFormat={$work$Work_Rating^ [^]}} and by example Work1 Work2 Work3 in a group groupW

I get the value

work1, groupW, work2, work3, [rating1, rating2, rating3]

instead of

work1 [Rating1]

work2 [Rating2]

work3 [Rating3]

I don't understand the goal of concatenation between several different works, even if they belong to a same group ?

for what kind of use case is it useful ?

[simoncn]

I have reproduced this behaviour. You are seeing this because of how MinimServer groups work.

A group is an item, just like an ungrouped track. It appears in Browse and Search results alongside ungrouped items (tracks). The contents of the group do not appear in Browse and Search results. To see these contents, you need to open the group.

To enable this behaviour, the tags from the tracks in a group (Artist, Composer, Genre, Work, etc.) are copied to the group item. The enables the group to appear in Browse and Search requests when any of the contained tracks is a match.

In your scenario, the group contains tracks with different Work tag values. All these values are copied to the group item. When displayFormat or indexFormat is applied to the Group item, all Work tag values are included in the formatted result.

[eseb63]

thanks for the explanation...
so, we can't use together group and displayFormat/indexFormat for tags having multiple values in the group because the result is quite inconsistent.
nothing to do to avoid this ?

[simoncn]

The result is not inconsistent. It correctly reflects the tags in the group. It should be suitable for displayFormat (for example, a list of artists) and is also suitable for indexFormat except in the case of the index tag having multiple values.

[eseb63]

(19-04-2025 22:43)simoncn Wrote:  The result is not inconsistent. It correctly reflects the tags in the group. It should be suitable for displayFormat (for example, a list of artists) and is also suitable for indexFormat except in the case of the index tag having multiple values.

(19-04-2025 22:37)eseb63 Wrote:  so, we can't use together group and displayFormat/indexFormat for tags having multiple values in the group because the result is quite inconsistent.

I think we said the same : the inconsistence exists in this particular case : is it possible to fix it ?

[simoncn]

I am investigating a possible fix for this issue with groups and indexFormat. Instead of having Work.indexFormat produce a single merged Work value for the group, it could apply Work.indexFormat to each item in the group and add all these formatted values to the group. In your example, the group groupW would have these tags:

WORK=work1 [Rating1]
WORK=work2 [Rating2]
WORK=work3 [Rating3]

This would give you the Work index entries that you want. Selecting any of these Work index entries would show the group, not the individual item, maintaining the principle that items within a group cannnot be accessed directly from outside the group.