Not tuning control channels on multiple sources.

[jessm33]

One system I monitor recent switched control channels and trunk-recorder wouldn't switch to the new control channel, it kept cycling thru all 4 control channels. Restarting trunk-recorder did not fix the issue. Reordering the control channels in the config so the current control channel was first in the config fixed the issue. Further testing shows it will tune the control channel, even if it is not the first one listed in config file, if it doesn't need to switch sources, before getting to the active control channel.

My config file is attached: config.json.txt

[rosecitytransit]

Does anyone else have this issue? I'm currently running version 3.3 and when a control channel changes the program either never finds the new one or crashes. I was hoping that upgrading would address the issue.

When it crashes I see:

sched: <block fft_filter_ccc (1081)> is requesting more input data
  than we can provide.
  ninput_items_required = 10314
  max_possible_items_available = 8191
  If this is a filter, consider reducing the number of taps.

then

terminate called recursively
terminate called after throwing an instance of 'boost::thread_interrupted'

I think the offending code would be somewhere in https://github.com/robotastic/trunk-recorder/blob/master/trunk-recorder/main.cc#L1309 Doing a quick comparison between the version I'm using and the current master shows only the addition of system->smartnet_trunking->reset(); which wouldn't matter for P25.

But to confirm, are you using the current version 4.5.0? And could you post a log of it happening? Also, if you can, try adding some logging statements within the retune section to see if you can narrow the issue down.

[jessm33]

I am running 4.5.0, there wasn't anything useful in the logs(some p25 parse errors, and control rate message from not being able to tune the control channel). I've not seen any crashes when this happens, last time this happened it was stuck in the cycling thru control channels but kept running for a few hours before I could update the config to work around this issue.

I have found in my case this retune issue is caused by having different sample rates on the 2 sources with possible control channels. Changing the sample rates for these 2 sources to same value allows trunk-recorder to retune across the sources.

[taclane]

I have found in my case this retune issue is caused by having different sample rates on the 2 sources with possible control channels. Changing the sample rates for these 2 sources to same value allows trunk-recorder to retune across the sources.

Out of curiosity, can you share what the control channel freq is, and the order they were in that worked, and didn't work?

Might be onto something with the sample rates; it's possible something isn't getting reset when it switches to a new source that sometimes, but not always, causes an issue. I'd suspect that it probably isn't just the sample rate itself, but but some downstream calculation like decimation or prefilter settings.

It should be pretty to replicate this on other systems by using mismatched sample rates and throwing a couple dummy freqs into the control channel list.

[jessm33]

The system has these 4 control channels, with my sdr setup the first 2 are on one source, and the last 2 are on another source. 856262500, 857262500, 858262500, 859262500

With 856262500, as the active control channel the original order works fine.

With this order trunk-recorder and different sample rates on the 2 sources, trunk recorder will loop continuously and never lock on to a source.

858262500, 859262500, 856262500, 857262500

With the above order, and the same sample rates on both sources, trunk-recorder will correctly try the first 2 freqs on one source then move on the next source and lock on to the control channel.

[robotastic]

Interesting! It probably is the change in sample rate between sources. I can go check out the retune code for the Control Channel stuff. It probably doesn't recalculate the filters and things when it switches to a new source.

[robotastic]

Whelp - That is as close to a smoking gun as you get... https://github.com/robotastic/trunk-recorder/blob/9d9def8ce7afbbd324a36ccd7cb746f7d749d73d/trunk-recorder/systems/p25_trunking.cc#L297-L300 I will go fix this up...

[robotastic]

OMG - that is non-trivial... It honestly maybe better to just kill the system block and create a new one.

so... gave that a try! It compiles, but it may dump memory at an alarming rate. I am not sure how well everything gets cleaned up each time a new trunking decoder block is created.

Anyhow - can you give the cc-retune branch a try?

[jessm33]

Just gave the branch a try, and it does fix this issue. I tested with a config that has the current active control channel last, and different sample rates on the 2 sources. I will let it run and see if any issues pop up.

[gonzoblue]

Looks like I had a similar issue. Even with only a single CC or the primary CC as the first in the json it wouldn't lock on. I tried the cc-retune branch and it immediately started working again.

[robotastic]

OK - Seems like it is a good idea to merge this branch in!