BCFY Calls not using my node's calls

[hruskacha]

The BCFY Calls feed for 41FDN of MPSCS doesn't have my nodes calls anywhere and I cant figure out why... I operate node 999 and 4582, and for whatever reason, its only using calls from 999 which is in the neighboring county. Node 4582 is also in a neighboring county but has 41FDN traffic much much more often.

This morning 6-24-2025 at 7:44am there was a fatal car accident mentioned on 41FDN, but its not showing any calls from 4852, which I did verify had numerous calls around that time. I verified everything on my end, and all checks out. But then I noticed it saying my node 4852 was stale. Why doesn't it show any calls from 4852 this morning?

 

[hruskacha]

Correction, I accidentally put 4852 a few times... The correct node is shown in the image, 4582.

 

[Deziel0495]

Make sure I'm understanding this correctly. You're providing both nodes from the same PC and only 1 node is carrying the traffic from the talkgroup you mentioned, correct?

If that's the case, ensure your alias lists are configured correctly. Each channel should have its own alias list.
Also you can try turning off duplicate call detection in user preferences for streaming. The Broadcastify Calls system itself does a good job at filtering out duplicates on its own and that way all traffic for each node can be sent.

 

[hruskacha]

No. I have ownership of both nodes, but they are on two separate computers, at two different locations, monitoring two different sites of the same system (some common traffic)

Both nodes encounter the problematic talkgroup on a daily basis, but 4582 sees it much more consistently since it's closer geographically. But for some reason broadcastify isn't showing the calls, and there's no duplicates from the other node, so I don't understand why it would reject it

Also, both nodes actually use the same playlist file in SDRtrunk. The only changes I make are to the streaming config.

 

[HarryWilly]

No disrespect to the SDRtrunk team, those that contribute, etc, but I always had issues of it just missing talkgroup calls. Never really figured out what it was. I switched to it for a bit from Trunk-Recorder since it had a couple nice things like unit ID and a graphical UI for debug, but I just found Trunk-Recorder to almost never miss a TG. It may have totally been user error, but as an example the less interesting stuff like transportation and corrections would consistently be missed.

 

[hruskacha]

No disrespect to the SDRtrunk team, those that contribute, etc, but I always had issues of it just missing talkgroup calls. Never really figured out what it was. I switched to it for a bit from Trunk-Recorder since it had a couple nice things like unit ID and a graphical UI for debug, but I just found Trunk-Recorder to almost never miss a TG. It may have totally been user error, but as an example the less interesting stuff like transportation and corrections would consistently be missed.

I notice many small anomaly's with SDRtrunk honestly.

 

[rjdj2000]

One major thing with calls is having computer time dang near perfect. Use dimension 4 to do it, the skew could be off enough. Also you need to make sure the talk groups are all selected to stream on the calls. I run mine for legacy feed, calls, openmHz, an Icecast feed as well as a Rdio stream. I don't miss much and if I do it is because of too many calls going on at once.

 

[hruskacha]

One major thing with calls is having computer time dang near perfect. Use dimension 4 to do it, the skew could be off enough. Also you need to make sure the talk groups are all selected to stream on the calls. I run mine for legacy feed, calls, openmHz, an Icecast feed as well as a Rdio stream. I don't miss much and if I do it is because of too many calls going on at once.

I have an NTP program that syncs me every hour. I never drift more than a few ms every sync. Also, I use a "wildcard" that sends TGIDs 1-65,535 to be recorded, and sent to Broadcastify calls. I have known talkgroups imported on top of that, but it knows to use the known alias over the assumed wildcard (meaning I don't have duplicate errors)

 

[rjdj2000]

I have an NTP program that syncs me every hour. I never drift more than a few ms every sync. Also, I use a "wildcard" that sends TGIDs 1-65,535 to be recorded, and sent to Broadcastify calls. I have known talkgroups imported on top of that, but it knows to use the known alias over the assumed wildcard (meaning I don't have duplicate errors)

Ok.. Can't think of anything else off hand that could be the issue. Mine runs 24/7/365 without a hicup on the legacy feed and calls platform so not sure what to think that could be the issue.