Tvheadend

PR sent: https://github.com/tvheadend/tvheadend/pull/1199

When exclude flag was on, the code was going through the list of existing tags and skipping the user selected ones.
Later the check was to see if the channel tags were in that list, failing on channels that didn't have any tag.

Now, the code builds the list of user setup tags and saves the exclude flag.
Later the check is simply a boolean XOR (a != b) between "has tag" and "exclude flag".

+1

Just a couple of days ago I experienced something similar:

Most channels are tagged with 'HDTV' and 'TV channel' resp. 'SDTV' and 'TV channel',
but some channels just have got the tag 'TV channel'
and two userprofiles are used

Userprofile 'Wlan' exclude tag 'HDTV'
Userprofile 'LAN' exclude tag 'SDTV'

Result: Both users, A and B, have got full access to all channels, because 'TV channel' is not marked to be excluded.

As Luis pointed out I would have expected some kind of OR-behaviour: If a channel owns at least one tag marked to be excluded, then the channel should not be displayed.

Yep... that's another (different) issue the current code causes:

channel1 - tagA, tagB
channel2 - tagA, tagB
channel3 - tagA
channel4 - tagB

Setting "exclude" + "tagA" will result on access to: channel1, channel2, channel4
Where it should only grant access to: channel4

PR updated: https://github.com/tvheadend/tvheadend/pull/1199

Works like this (with access rule chaining):

channel1 - tagA, tagB
channel2 - tagA, tagC
channel3 - tagB, tagC
channel4 - tagA, tagB, tagC
channel5 - tagA
channel6 - tagB
channel7 - tagC
channel8 (untagged)

access1:
tagA (exclude)

access2:
tabB
tagC

access3:
tagA

Assuming a user access matches:
1) access1:
rule is "not tagA" = channel[3,6,7,8]

2) access1->access2:
rule becomes "not tagA && (tagB or tagC)" = channel[3,6,7]

3) access1->access2->access3:
rule becomes "tagA or tagB or tagC" = channel[1 to 7]

Tim Bremer,
If you get the chance, please test your case with a build from:
https://github.com/ljalves/tvheadend/commits/tag_exclude

This can be marked as fixed
(merged on commit 4f9fdd0f1517ea07508c54e80d623422959a012b)