+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: Bug in smart playlist behavior when using tags (/showthread.php?tid=353769)
Bug in smart playlist behavior when using tags - teriyaki - 2020-04-22
Hi. My household has several people and I recently dumped using kodi's built-in favorites for using tags + smart playlists instead. It makes it far easier to maintain everyone's own `favorites` lists, what shows we watch together, etc. The bug is in the "is" operator behavior. By definition, the relevant operators are:
contains: True if the field contains the parameter as a substring
doesnotcontain: True if the field does not contain the parameter as a substring
is: True if the field matches the parameter exactly
isnot: True if the field does not match the parameter exactly
Say I have a tv show called "SomeShow" and I add my favorite tag "fav-me" to it. Then in a smart playlist to list only shows I watch, I add the rule:
<rule field="tag" operator="is"><value>fav-me</value></rule>
When I run the xsp, the result is SomeShow as expected. The value is exactly "fav-me". Let's say I then add another favorite tag, "fav-you", to SomeShow so now SomeShow has 2 tags; fav-me, fav-you. If I run the xsp again, I still get SomeShow as a result even though the tag field is not exactly just "fav-me". If I look at the tags in the webif, it shows "fav-me; fav-you". Since "is" is supposed to be true only when the value matches exactly, it should not be triggered when the value does not match exactly.
Because of this broken "is" behavior, to single out tv shows only the "fav-me" tag watches, you have to manually exclude every other favorite tag out as a workaround. Something like this:
<rule field="tag" operator="contains"><value>fav-me</value></rule>
<rule field="tag" operator="doesnotcontain"><value>fav-you</value></rule>
<rule field="tag" operator="doesnotcontain"><value>fav-kid1</value></rule>
<rule field="tag" operator="doesnotcontain"><value>fav-kid2</value></rule>
<rule field="tag" operator="doesnotcontain"><value>fav-kid3</value></rule>
And then you'd have to do that for each different person where you should only need a single "is" rule.
RE: Bug in smart playlist behavior when using tags - jjd-uk - 2020-04-23
Sounds like it is operating exactly as it should to me. if you have
xml:<rule field="tag" operator="is"><value>fav-me</value></rule>
Then it will look at all tags individually for a match, so yes it will always match fav-me even when there's multiple tags.
RE: Bug in smart playlist behavior when using tags - jjd-uk - 2020-04-23
For your example if the people represented by fav-me and fav-you share favourite items you wish to exclude on the individual lists then an alternative would be to create an fav-me&you tag.
RE: Bug in smart playlist behavior when using tags - teriyaki - 2020-04-23
(2020-04-23, 13:34)jjd-uk Wrote: Sounds like it is operating exactly as it should to me. if you have
xml:<rule field="tag" operator="is"><value>fav-me</value></rule>
Then it will look at all tags individually for a match, so yes it will always match fav-me even when there's multiple tags.
If it looks at each tag individually, then it's still producing a false-positive. If I have "fav-me" and "fav-you" assigned, it correctly matches the tag. "fav-me" is value "fav-me" so match=yes. But when it checks against the second tag, "fav-you", it's not setting match=no, still saying match=yes or "fav-you" is value "fav-me", which violates the definition of the is operator.
Quote:For your example if the people represented by fav-me and fav-you share favourite items you wish to exclude on the individual lists then an alternative would be to create an fav-me&you tag.
This is a terrible solution! I have 5 people in my household which permeates to 31 different unique combinations. The number increases significantly the more people in your house. If we have a relative staying with us, the number of combinations jumps to 63. Adding/removing people should be as easy as removing their fav-<name> tag, not maintaining 31 combinations minimum rather than just 5.
RE: Bug in smart playlist behavior when using tags - jjd-uk - 2020-04-23
(2020-04-23, 16:29)teriyaki Wrote: If it looks at each tag individually, then it's still producing a false-positive. If I have "fav-me" and "fav-you" assigned, it correctly matches the tag. "fav-me" is value "fav-me" so match=yes. But when it checks against the second tag, "fav-you", it's not setting match=no, still saying match=yes or "fav-you" is value "fav-me", which violates the definition of the is operator.
It doesn't work like that.
It will simply check all tags to see if any match fav-me then display the result, it does not care about any other tags if you have not specified a rule for them.
(2020-04-23, 16:29)teriyaki Wrote:Quote:For your example if the people represented by fav-me and fav-you share favourite items you wish to exclude on the individual lists then an alternative would be to create an fav-me&you tag.
This is a terrible solution! I have 5 people in my household which permeates to 31 different unique combinations. The number increases significantly the more people in your house. If we have a relative staying with us, the number of combinations jumps to 63. Adding/removing people should be as easy as removing their fav-<name> tag, not maintaining 31 combinations minimum rather than just 5.
That's what you get for using a function that is not designed to be used in such a way.
RE: Bug in smart playlist behavior when using tags - teriyaki - 2020-04-23
(2020-04-23, 16:37)jjd-uk Wrote: It will simply check all tags to see if any match fav-me then display the result, it does not care about any other tags if you have not specified a rule for them.That's the behavior of the "contains" operator - does the field contain a value regardless of what other values may be present? The "is" operator is supposed to match exactly.
Does Kodi store tags in a single entry using a field separator, or does it store multiple entries all called "tag" or something? In other words:
tags="tag1;tag2;tag3;tag4" field-separated by ; or tag="tag1", tag="tag2", tag="tag3", tag="tag4"I guess it doesn't really matter, either way it checks every tag individually. Kodi just applies these operators in a weird way, imo, I guess. If I ask `is the tag list "fav-me"?`, I don't expect the logic to be `is any tag in the tag list "fav-me"?`. Does List = "1"? Yes if List ="1", no if List = "1; 2; 3; 4; 5". It's bizarre that Kodi thinks List="1" when List="1;2;3;4;5". Kodi tags is the only case I've ever encountered where an is operator behaves like a contains operator.
Quote:That's what you get for using a function that is not designed to be used in such a way.Isn't the whole point of user-defined tags so they can be added and used to find specific items that pass whatever conditions you require? It's pretty silly to suggest I'm not using tags `correctly`. I'd argue the exact opposite in fact.
RE: Bug in smart playlist behavior when using tags - jjd-uk - 2020-04-23
It doesn't operate the same way as contains as it does an exact match. Each tag is stored as an independent piece of data so if a library entry has 5 tags it was check each independent tag for an exact match, so it only needs one of those tags to be an exact match.
So
Tag1 - fav-me - exact match found list all items with this tag
Tag 2 - fav-you - no match found nothing to be added to list
Tag3 - fav-kid1 - no match found nothing to be added to list
Tag4 - fav-kid2 - no match found nothing to be added to list
Tag5 - fav-kid3 - no match found nothing to be added to list
Contains would be having a tag "Marvel Avengers" applied to all the films that feature the Avengers characters, then having a tag "Marvel X-Men" for for the movies featuring the X-Men characters, from this you could have a Contains rule to match on "Marvel" is to list both sets of movies. So for contains it searches the each tag for whether it contains a partial or full string match, then lists all Movies for any tag that produces a match.
RE: Bug in smart playlist behavior when using tags - scott967 - 2020-04-23
tag1; tag2 in the UI is just a display function. In the database each unique tag has a tag_id and the id is linked to media items. I guess there is an unwritten rule that when there are multiple items, there is an implicit OR between the items. Haven't tested but assume things like studio and genre work the same way.
scott s.
.
RE: Bug in smart playlist behavior when using tags - jjd-uk - 2020-04-23
It really quite simple
Fav-me
Movie1, Movie2, Movie3, Movie4
Fav-you
Movie3, Movie4, Movie5, Movie6
Fav-kid1
Movie7, Movie9, Movie11, Movie13
Fav-kid2
Movie6, Movie8, Movie10, Movie12
xml:<rule field="tag" operator="is"><value>Fav-me</value></rule>
Searches for an exact match in the list of defined tags, it matches on Fav-me so displays all Movies with that tag applied, so that's
Movie1, Movie2, Movie3, Movie4
If doesn't matter that Movie3 and Movie4 have also been tagged with Fav-you as it only looking for an exact match on Fav-me then displays everything in the Fav-me list.
xml:<rule field="tag" operator="contains"><value>Fav-kid</value></rule>
Searches for a partial or full match in the list of defined tags, it matches on Fav-kid1 and Fav-kid2 so displays all Movies with either of those tags applied, so that's
Movie6, Movie,7, Movie8, Movie9, Movie10, Movie11, Movie12, Movie13
RE: Bug in smart playlist behavior when using tags - teriyaki - 2020-04-23
(2020-04-23, 19:57)scott967 Wrote: tag1; tag2 in the UI is just a display function. In the database each unique tag has a tag_id and the id is linked to media items. I guess there is an unwritten rule that when there are multiple items, there is an implicit OR between the items. Haven't tested but assume things like studio and genre work the same way.
scott s.
.
Yeah, that's why I asked actually. I thought the UI was showing me the literal value which is why returning true didn't make any sense when match value and tag value weren't equal. The only thing I could figure it each tag being its own entry and not the single-entry-using-a-field-separator the UI presented. I think there should definitely be a note/warning on the smart playlist wiki page that when you have an item with multiple tags, a rule will apply to each tag individually with positive hits being final. The unwritten OR rule should be documented to make the behavior more clear.