I would like to hear an explanation as to how exactly trunking priority is supposed to work if the scanner is unable to decode messages carried on the traffic channels?
As we are talking about a trunked system, there would be only two sources of voice grant messages: the control channel, or the traffic channel. So then, if the scanner does not use "preemption priority", exactly how is there any priority at all? The notion that "the scanner will favor priority talkgroups over others" makes absolutely no sense. When a grant comes across the control channel, as long as that talkgroup is not avoided/locked out and/or the scanner is in ID Search mode, it's going to follow the grant and tune to that traffic channel. If another talkgroup that is flagged as priority becomes active, the scanner has no way to "favor" that priority talkgroup if it doesn't respond to the grant broadcast over the traffic channel. So how exactly is this "favoring" working? If two channel grants come across the control channel simultaneously, the scanner will tune to the one flagged for priority? That's rather pointless in the grand scheme of things, as it's a pretty infrequent occurrence to have a tie like that @ 40 opcodes per second.
Long story short, once the scanner tunes to the traffic channel, there is no other way for it to "favor priority talkgroups" without using preemption. If this feature works with other system types like EDACS or Motorola 3600, and if it works with P25 FDMA transmissions, but does not work with P25 TDMA transmission...then that is unexpected behavior, which by definition is a bug. Period.
I won't belabor the point any further; it's on your list, so be it.
