the itemTags property

[winxi]

(19-09-2013 22:51)simoncn Wrote:  The timing of this is an interesting coincidence. I've just been looking at a problem which occurs when itemTags is used to specify reading a tag name that will be used in the tagUpdates file. Detecting that this tag should be read (without the benefit of itemTags) would require a complete preparse of the tagUpdates file.

I see. I hope you don't mind such requests, as from the users point of view it's often difficult to figure all the corner cases. I'm always very happy to still learn something new about MinimServer with your detailed explanations.

Quote:Another case is when itemTags is used to specify reading of a tag for use in aliasTags. There may be other such cases, either now or in the future.

The sort direction is used in all places where a tag can be sorted. A future release of MinimServer will add new facilities for customized sorting which will allow sorting to be controlled by itemTags values. I think it's better to specify the sort direction of a tag in one place only.

I'm very curious about the new sorting facilities and I'm looking forward to this future release.
However, I've a question about the existing Album.sortOrder property. How does MinimServer handle situations when a album list is sorted by a tag which has different values for some tracks within an album. For example, a 'Greatest Hits' release might have different date tags for each track. When the album list is now sorted by date, which date does MinimServer choose to position the album in the album list? Also, how does MinimServer handle multiple tags for sorting. For example, each track in an album may have two genre tags (genreA and genreB). Which of these tags is then used when albums are sorted by genre?

Quote:The current approach seems very simple to me: if a tag name is present in indexTags or itemTags, MinimServer reads it; otherwise, it doesn't. The approach you're suggesting would require a much more complicated set of rules to say whether or not a tag is read, and these rules would need to be updated every time a new feature is added that makes use of a tag.

I agree, the existing approach is not too complicated and it seems to be more straightforward as compared with my proposed approach.