Post Reply 
the itemTags property
19-09-2013, 21:58
Post: #1
the itemTags property
I wonder if the itemTags property could be dropped to reduce the complexity of the properties dialog. This would require MinimServer to check the tagCustom, tagFormat and the tagOptions properties for tags which are not contained in indexTags. If it find such zombie-tags, it would automatically index them.

A problem may be that then it isn't possible to use +/- to customize the sort direction of these tags. But if I'm not wrong, this is only relevant when used in the Album.sortTags setting. This could be compensated when the Album.sortTags setting would allow to have +/- for its tags, too. For example, when Album.sortTags could be set to '{-Date, +Album}'.
Find all posts by this user
Quote this message in a reply
19-09-2013, 22:51
Post: #2
RE: the itemTags property
(19-09-2013 21:58)winxi Wrote:  I wonder if the itemTags property could be dropped to reduce the complexity of the properties dialog. This would require MinimServer to check the tagCustom, tagFormat and the tagOptions properties for tags which are not contained in indexTags. If it find such zombie-tags, it would automatically index them.

A problem may be that then it isn't possible to use +/- to customize the sort direction of these tags. But if I'm not wrong, this is only relevant when used in the Album.sortTags setting. This could be compensated when the Album.sortTags setting would allow to have +/- for its tags, too. For example, when Album.sortTags could be set to '{-Date, +Album}'.

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.

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.

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.
Find all posts by this user
Quote this message in a reply
19-09-2013, 23:22
Post: #3
RE: the itemTags property
(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.
Find all posts by this user
Quote this message in a reply
20-09-2013, 00:10
Post: #4
RE: the itemTags property
(19-09-2013 23:22)winxi Wrote:  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.

Not at all. All ideas and suggestions are welcome. I hope you don't mind when I decline some of them. Smile

Quote: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?

This code is performance-critical, so it can't do anything too fancy. It uses the first value of the specified tag that it finds in the album's tracks (searched in tracknumber order). If a track file contains multiple values for the same tag name, the value that appears first in the file is used.
Find all posts by this user
Quote this message in a reply
22-09-2013, 21:07
Post: #5
RE: the itemTags property
(20-09-2013 00:10)simoncn Wrote:  This code is performance-critical, so it can't do anything too fancy. It uses the first value of the specified tag that it finds in the album's tracks (searched in tracknumber order). If a track file contains multiple values for the same tag name, the value that appears first in the file is used.

Thanks for this information! It may be worth adding this to the user guide.
I think that this is a very reasonable and straightforward approach. There may be more fancy algorithms (for example to use the tag value with the most instances for sorting or the arithmetic mean for numeric tag values), but, besides the performance problem, I think that it would be difficult to find something that is appropriate for all use cases.
Find all posts by this user
Quote this message in a reply
22-09-2013, 21:41
Post: #6
RE: the itemTags property
(22-09-2013 21:07)winxi Wrote:  Thanks for this information! It may be worth adding this to the user guide.
I think that this is a very reasonable and straightforward approach. There may be more fancy algorithms (for example to use the tag value with the most instances for sorting or the arithmetic mean for numeric tag values), but, besides the performance problem, I think that it would be difficult to find something that is appropriate for all use cases.

As suggested, I've added this to the List sort order section of the User guide. Thanks!
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)