I've noted on some Motorola Type II Smartnet systems that occasionally they'll have some instance of a very long squelch tail like the repeater just doesn't want to let the signal go for whatever reason.
Motorola analog systems send a disconnect word - a repeating 10101100 bit pattern sent at 300 bps - which mutes the subscriber units and sends them back to the control channel, which is why they have no squelch tail. I've seen some SZ traffic channels that never dekey - if you monitor them in conventional mode, your receiver hangs indefinitely.
If it's not something on your end there's nothing you can do about it, basically.
The OP indicated that other SDR software is functioning properly, so there seems to be an issue with SDR Console's squelch logic. Obviously, there's something different about the particular channel, like a higher noise floor or something.
The only thing that I've ever found that helped to reduce the traditional "static" kind of short burst is adjusting the squelch itself a bit higher to cut out such things. Would be fantastic to find a way to get rid of the static at all like an actual scanner tends to do but I'm not sure that's possible with SDR hardware and software, maybe someone will figure it out someday.
Shouldn't be that hard. The reason you hear a squelch tail is because the software takes a bit of time to decide that the signal has changed (from being present to being gone); it takes time because otherwise, weak signals would chatter as the squelch logic opened and closed rapidly as the signal level fluctuates.
The trick is to take the time needed to see that the signal is really gone and then determine exactly where the transition from signal present to signal gone occurred, and then only play the audio up to that point. Of course, this means you need to delay the audio you're playing by a bit - maybe 100 to 200 ms.