Open rosecitytransit opened 1 year ago
robotastic
commented
1 year ago That is weird - I just made a change to the master branch to print out all of the Control Channels that were added for a system after it reads in the config file. Could you try running the this branch and seeing if the problem is still there and what it prints out after processing the config file?
rosecitytransit
commented
1 year ago For now, I added some logging to System_impl::get_next_control_channel() since I'm thinking weirdness should show in there:
double System_impl::get_next_control_channel() {
BOOST_LOG_TRIVIAL(info) << "[" << this->get_short_name() << "/" << short_name << "] old currrent_control_channel=" << current_control_channel << ", control_channels.size()=" << control_channels.size() << ", control_channels[]=" << this->control_channels[current_control_channel];
current_control_channel++;
if (current_control_channel >= control_channels.size()) {
current_control_channel = 0;
}
BOOST_LOG_TRIVIAL(info) << "[" << this->get_short_name() << "/" << short_name << "] currrent_control_channel=" << current_control_channel << ", control_channels[]=" << this->control_channels[current_control_channel];
return this->control_channels[current_control_channel];
}When I have time (I'm leaving for the weekend) and get every thing set up on the pi, or when I next need to restart the program, I can definitely try out your change. As well as see if I can induce the problem and further troubleshoot.
taclane
commented
1 year ago In the event there's an issue mixing up the channels sometime after initial t-r setup, a patch-free option is also to check out the status server plugin.
The html tables are a little flaky, but it it should still output each system's control channel list, up-to-date as of that moment the page is refreshed.
rosecitytransit
commented
1 year ago Well it did it again, and the added logging shows control_channels.size() magically growing from 8 to 10 and then 12, and hours and many retunes after start.
For now, I've just removed all but the current one in the config. They don't change that often anyways.
On Sat, Jun 10, 2023, 9:13 AM Nick @.***> wrote:
In the event there's an issue mixing up the channels sometime after initial t-r setup, a patch-free option is also to check out the status server plugin.
The html tables are a little flaky, but it it should still output each system's control channel list, up-to-date as of that moment the page is refreshed.
— Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/826#issuecomment-1585718319, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFAB7DMVWXK4E2S5D5HZ5ILXKSMKVANCNFSM6AAAAAAZBNW7EY . You are receiving this because you authored the thread.Message ID: @.***>
robotastic
commented
1 year ago I just tried to reproduce this but didn't have any luck. I have one system locked onto a control channel and the other is retuning. Could you share you config file?
{
"ver": 2,
"sources": [
{
"center": 855700000,
"rate": 2048000,
"error": 0,
"gain": 24,
"digitalRecorders": 1,
"driver": "osmosdr",
"device": "rtl=200,buflen=65536"
}
],
"systems": [
{
"control_channels": [
855462500,
855237500
],
"type": "p25",
"modulation": "qpsk",
"shortName": "test2"
},
{
"control_channels": [
855560001,
855570001
],
"type": "p25",
"modulation": "qpsk",
"shortName": "test1"
}
],
"controlWarnRate": -1
}I put a copy here: http://www.rosecitytransit.org/files/config.json
Note that I don't think I've had the issue since I went and removed all the other frequencies for the system it was happening on. I may try to do some troubleshooting myself, or close this issue for now and reopen it if I see it happen again.
tadscottsmith
commented
3 months ago You have a control channel for Pete's Mountain (770.093750) listed in your config for Mount Scott. If trunk-recorder tunes to that control channel it's going to automatically add the alternate CCs that are being broadcast for Pete's Mountain.
rosecitytransit
commented
3 months ago Don't think I'd get Pete's Mountain from where I'm located, and don't think that there should be any shared frequencies with the Oregon State Radio Project system, but that's a good catch. I know the DB doesn't have all the frequencies listed for Mt Scott.
As I said in the other issue, I could test a more current version and see if the issue still exists.
I'm using a modified version of the new_call_mgmt branch, including the cc-retune fix, and things are working pretty good. But I've noticed twice now that recordings start getting saved into the wrong system.
I looked at the logs when it started this time and it seems that after trying the last defined control channel, trunk-recorder isn't going back to the first one but instead trying ones in a different system.
Log excerpts:
The first 7 retunes are as expected, but then trunk-recorder tries 2 channels on a completely different system (
osrppdxc) and not even ones in a discernible order. The first one tried is parallel with where a next one on themssystem would be, but the next one seems random. And trunk-recorder does indeed lock onto theosrpppdxccontrol channel and start recording calls from it into themssystem.Note that I now have a Pi 3B+ that I was given up and running, and intend use that as a test bed if someone has some ideas to try