Feature Request : Truly allow lockout of talkgroups so that tuner does not even tune to frequency

[mbt25]

I'm running 0.5.0 Alpha 1

Maybe there is a way to do this, but I haven't found it. I certainly can and do turn off "Listen" on talkgroups I do not want to hear. But I notice that the tuner still locks/tunes to the frequency of the talkgroup. That seems like it might be a little inefficient and could result in unnecessary decode issues at times (not that I have experienced this thus far).

I think it would be nice to have the ability to essentially disable the talkgroup (no listening, no recording, no tuning to the frequency that the talkgroup is active on), and perhaps it would be wise to automatically disable a talkgroup that is encrypted. Although I guess some people would like the ability to send encrypted talkgroup audio to BCFY calls in order to keep track of radio IDs associated with a particular encrypted talkgroup. So maybe automatically disabling all encrypted talkgroups would not be a good idea.

[ghost]

This is a feature that is really needed.

[jpryor223]

Recommend similar to channel decoder Ignore Data Calls option.

As a user, I want to ignore tuning and not display traffic channels for multiple scenarios, so that I can have capacity and visibility for traffic channels I do want to see and listen, record and/or stream.

Possible options:

Ignore Muted Alias Calls (no listen, record or stream) Ignore Encrypted Status Calls Ignore Idle Status Calls (more for Now Playing list screen real estate with non active channels or slots)

GIVEN the channel decoder screen WHEN configuring THEN the possible options are present GIVEN the possible scenario option is configured to ignore WHEN monitoring control and tuning THEN the ignored scenario is not tuned and not displayed

Also consider the following option (likely best to split to a new issue):

Preempt Lower Priority Calls with Higher Priority Calls

As a user, I want to preempt lower priority calls with higher priority calls, so that the higher priority call is tuned and displayed in order to be heard, recorded and/or streamed.

Useful when a user does not have the max traffic channel capacity or tuner range to capture all calls, and there is a desire to capture the highest priority calls.

~~GIVEN the channel decoder screen WHEN configuring THEN the preempt option is present GIVEN the preempt option is configured and max traffic channels are tuned WHEN monitoring control and tuning THEN the lowest priority call is preempted with the next higher priority call GIVEN the preempt option is configured and higher priority traffic is out of tuning range WHEN monitoring control and tuning THEN the lowest priority call is preempted with the next higher priority call (this will require most consideration for the current priority of multiple active calls on the call stack compared to priority of possibly active calls from control)~~

[mbt25]

Hmm. This is beginning to look more like an RR forum thread (everyone throw their idea in) rather than a specific issue/request. Maybe for the dozen new features you want you can open up another Feature request, Jeff :) My feature request has nothing to do with either aesthetics or user convenience. Mine is more along the lines of freeing up the tuners from having to tune to a frequency whose talkgroup is never going to be heard / recorded / streamed. If the control channel says there is a call active on 853.425 for TG 12345 and TG 1234 is muted / not streaming / not being recorded (and optionally is encrypted), then it would save on system resources not having that particular tuner channel active and would avoid any issues that might otherwise arise with voice/control frequencies being switched between multiple tuners when there are many talkgroups being decoded simultaneously across multiple tuners.

[jpryor223]

I moved the two possible features (hide idle, preempt priority) to two new issues. All four options will potentially reduce the number of locked tuners needed. These will allow a user to focus on tuning (and displaying) only calls that are desired.

[efirstalert]

I'm several months late to the party, but I'm curious if anything else has happened along the "lockout" idea. I just SDRTrunk running to monitor a P25 Phase 2 system, and this was the first thing I started to look for. There are a subset of talkgroups I do want to monitor, and a huge amount that I don't.
I'm running Alpha 0.5.0 Alpha 6

[wri3ght]

This is something that would be helpful to me for the reasons already stated here previously.

[Awnage]

Bringing this back to life because it would be really helpful. The local airport buses clog up my tuners.

[louisik1]

This keeps coming up in Radio Reference's forums. Of all the issues I've seen with sdrtrunk (which I am a big fan of), this seems like the most common request.

https://forums.radioreference.com/threads/can-sdrtrunk-drop-a-channel-grant-so-it-doesnt-tie-up-a-dongle.459423/

http://forums.radioreference.com/threads/sdr-trunk-no-audio.456813/post-3842790

What are your thoughts, Mr. Shreirer?

[PhillyPhoto]

2 years with a semi-working solution in a branch but no movement on main. This is a waste of resources and would be very valuable to us! Hopefully we get this working soon.