You're not going to have much success with properly following trunked communications with just one stick, it's the nature of how trunking and how Unitrunker allows for such operation (as I best understand it, that is) -
you can monitor them, sure, but following the conversations can be very difficult and frustrating in many respects because you can't Hold or stay with a given talkgroup, at least not yet with any setup or any SDR hardware in a relatively easy to do manner. I think there's a way to Hold on a talkgroup now using a recent build of OP25 but that requires a Linux install and a rather complicated build process with a lot to get it functional for even the basics, and not many people will go to such lengths I suppose, but maybe some will.
Trunk tracking scanners follow all the stuff properly because they are able to decode the subchannel audio data which is passed on to the software in the scanner so it "knows" when to either return to the control channel directly and wait for another transmission on any talkgroup or do the same but only listen for activity on a given talkgroup if the Hold aspect has been put into effect. Even the most complex and expensive trunk tracking scanners made today still have just one tuner/VFO in them.
It's very difficult to do that with just a single tuner and Unitrunker because as Rick just noted above - and he would know more about Unitrunker than anybody else since it's his program - you can only tune one frequency at a time in such a manner, so you either tune the control channel for activity or you tune a voice channel to listen to voice comms but you can't do both at the same time.
Because this setup isn't using the subchannel audio data to allow for proper trunk following as noted above, that means when the voice comms are done then the receiver/Unitrunker tunes back to the control channel (what you use for for "Park" frequency) and then it has to start the decode all over again once it picks up the sync - and again, this is how I understand it. Picking up the sync for decoding the control channel can take from 2-10 seconds on some systems, I've seen it myself here in my area with dozens of trunked systems: sometimes it'll "lock on" in a second flat, other times it just takes a full 10 seconds.
That means basically that trying to follow trunked systems with a single piece of SDR hardware is going to be somewhat difficult in terms of timing, and of course so far there's no way to hold on a talkgroup either (not sure that'll be possible anytime soon, unfortunately).
Two pieces of SDR hardware, whether it's two RTL-based or some other "cheap USB TV tuners" or actual higher end stuff like bladeRF, HackRF, etc, is the preferred method: one of them is used to tune the control channel exclusively and do nothing else which allows Unitrunker to decode it consistently and pass the info along to the sdrsharptrunking.log so that SDR# can then pull that info using the trunking plugin and then tune the second SDR device accordingly.
In that manner you can monitor a trunked system properly - still can't hold on a talkgroup but at least you'll be following things in real-time with no 2-10 second delay to keep playing catch up with the control channel activity.
And of course, when you have two devices working in tandem in this manner, it's easy to just pipe the output from SDR# to the Windows mixer (Recording or virtual audio cables) for passing to DSD or DSD+ to decode the digital protocols as well.
I've read where people get Unitrunker working with just a single SDR device but in my experience it never worked anywhere near as well as I'd hoped. I guess I went into this thinking that SDR software had matured to the point where someone had written a program that could pull that subchannel audio data from the baseband so we could do proper trunk following, but that hasn't happened yet (and again I'm not sure if anyone will be able to code such a thing - it seems possible but maybe it just isn't).
As of v1.0.27.10 for Unitrunker (a preview version, not the public version) you're able to use just Unitrunker itself for controlling two RTL sticks: it can use one for the control channel (a signal receiver) and the second for the voice channels (voice receiver) and it actually works - I haven't had a great deal of success with it myself because I get some weird intermod or heterodyning-type of interference and I've yet to figure out why. What I eventually ended up doing for myself is this:
Instead of using Unitrunker as the control channel receiver - meaning it tunes the RTL stick directly - I use SDR# to tune the control channel frequency on the first RTL stick and pass that "baseband" by virtual audio cable to Unitrunker using a Discriminator (Signal) receiver, and then use the same copy of Unitrunker to control the second RTL stick directly for tuning the voice channels and it works remarkably well overall, much better than trying to control both sticks directly with Unitrunker itself, and I can even then pass that voice channel audio to DSD or DSD+ by way or a second virtual audio cable if needed.
Works for me, but there's several ways to do this stuff...
Also a tip to help decoding, especially P25 control channels with Unitrunker: when you're doing this, uncheck every protocol in the Unitrunker receiver dialog
except the one you're trying to decode - that allows Unitrunker to not waste resources trying to decode everything; same principle with DSD or DSD+, use the proper switch for the protocol when you're using it (-f1 for P25 traffic, -fr for DMR/MOTOTRBO, etc). More efficient decoding in that respect using those switches.