Broadcastify Calls Duplicate Calls Handing Updates

[blantonl]

If his are handling majority of calls, then mine is useless (unless his goes down).

This is where you need to think outside the box here with regards to Broadcastify Calls.

I'd like to have as many nodes as possible participating in the network. The vast majority of providers are volunteers, so the quality and participation in the network varies constantly, even between individual talkgroups.

You know that we have 10-20 feeds of turnover per day with the regular feeds?

A calls provider can pack up shop and move on, with no notice to anyone on the network. Having multiple nodes all feeding contributes to the health of the network. I'm designing this network to better and better self heal with nodes that quality drastically varies.

 

[mtindor]

This is where you need to think outside the box here with regards to Broadcastify Calls.

I'd like to have as many nodes as possible participating in the network. The vast majority of providers are volunteers, so the quality and participation in the network varies constantly, even between individual talkgroups.

You know that we have 10-20 feeds of turnover per day with the regular feeds?

A calls provider can pack up shop and move on, with no notice to anyone on the network. Having multiple nodes all feeding contributes to the health of the network. I'm designing this network to better and better self heal with nodes that quality drastically varies.

I wouldn't really pull my feed. But I do like to know it's performing the best it can. I completely understand making it as resilient as possible.

 

[blantonl]

Also, I pulled some stats from the calls platform this weekend.

Broadcastify Calls has coverage for:

• 42% of every Law Dispatch talkgroup in the RadioReference database
• 40% of every Fire Dispatch talkgroup in the RadioReference database

That is extraordinary.

 

[blantonl]

Here's are some representation of what the "back end table" looks like for a talkgroup where we are receiving calls from multiple nodes for a talkgroup.

 

[Napalm]

I already said this, but you fixed all the thousands of missed calls and duplicates I was getting in my admin page. I'm watching the stats for openmhz and bcalls on SDRTrunk and the difference is less than 10. Which accounts for the one dude uploading his three talkgroups. Thanks again.

I also installed Dimension 4 and my skew has been less than a second ever since Lol.

 

[mtindor]

you should be using playlists to listen on Broadcastify calls

This is going to sound lame. I knew there were Dashboards for feeds. But I forgot that there were Playlists for Calls. At some point I obviously knew, because I had partially set one up. But that must have been during beta testing or something. Aside from the 20 TG limit, monitoring a playlist is definitely the way to go. Like you said, no more worry about missing calls that another node outvoted you on. Nice.

Mike

 

[blantonl]

It’s not lame… it’s bad user experience on my part to not craft an interface that is as intuitive. I need to step up my game and get to work

 

[blantonl]

Don’t forget you can create unlimited playlists, so there’s that

 

[mtindor]

Don’t forget you can create unlimited playlists, so there’s that

That’s cool. Fortunately, my law playlist was exactly 20. I’ll create another one that is fire and EMS and that’ll be under 20 and I’ll be good to go..

Thanks man

Mike

 

[egftechman]

Given the above I'm going to weed out duplicates at the node level in this algorithm. Looks like I'll need to reach out to some of these SDRTrunk users who are presumably capturing 38 different sites and feeding it up as one node without the dup detection feature enabled. 🙄

That's the one danger with a platform for power users supported by power users. They'll do some of the wildest stuff and then be like "what? should I not have done that?"

It's also common for someone to contact me and say something like "My calls node stopped sending calls and is getting errors, nothing has changed on my end."

Me: "Those error logs indicate that something on your internal network is blocking outbound requests to our servers, did you enable a firewall or something?"

Them: "oh yeah, well, I did switch to a new ISP cable modem, and I also installed Starlink as a backup with a new router, and I decided to segment all my radio equipment on a dedicated VLAN tagged specifically for iOT devices, and on that I installed a firewall that blocks x, y, and z, and does packet shaping for maximum performance, but also blocks all outbound Port 80 http access unless I whitelist it - it does an auto-whitelist based on heuristics and the firewall also blocks porn from 8am-5pm but if at night when the port blocker is off (for my "special site that I visit at night") the AI engine might have categorized a broadcastify calls node as malicious due to some of the talkgroup names. I disabled all that and that fixed it. Thanks. "

Me: "🙄"

The rules clearly state one site per node, so they are in violation of the rules, IMHO

Issue in SDRTrunk is you have to create a separate alias list for each site if you want to separate feeds, if you use the same alias list (which makes sense for listening to multi site systems, since talkgroups and units will be the same) they will all be sent to the same feed.

I haven't looked closely at the SDR trunk code to see how easily site id metadata could be added to a feed ....and calls api updated to take a "site id" parameter in request. That could be a future path that would not require many duplicate alias lists in SDRTrunk...just a thought.

 

[KD8FSJ]

Just a Michigan MPSCS observation... I use your calls platform to identify a lot of new talkgroups. I am noticing a lot of bogus talkgroups showing up, broadcasting the same dispatch on many different talkgroups. Michigan MPSCS TG-3067 is coming across the following in just the last 24hrs. I am pretty sure this is not patched traffic.

523
643
2555
2901
3064
3066
8587
8697
9211
13307
19451
21921
28691
29022
35832
35835
38123
39931
40494
41391
41976
44026
44027
45047
45561
52219
56315

 

[blantonl]

It's probably just a node that's falsely decoding the talkgroup. Click on the magnifying glass for a call and find out which node it is and send them a problem report.

 

[Napalm]

If I create a playlist, can I share it for another registered user to listen to? Might not be the right place to ask but here we are.

 

[blantonl]

If I create a playlist, can I share it for another registered user to listen to? Might not be the right place to ask but here we are.

Not yet, but my idea along this line is to allow registered users to "publish" playlists into county pages (they will have to be approved and will have guidelines around their creation etc) that the public can access - essentially allowing people to create "feeds" from the broadcastify calls system. These playlists will be available for view on the Broadcastify County pages.

 

[depster00]

Just a Michigan MPSCS observation... I use your calls platform to identify a lot of new talkgroups. I am noticing a lot of bogus talkgroups showing up, broadcasting the same dispatch on many different talkgroups. Michigan MPSCS TG-3067 is coming across the following in just the last 24hrs. I am pretty sure this is not patched traffic.

523
643
2555
2901
3064
3066
8587
8697
9211
13307
19451
21921
28691
29022
35832
35835
38123
39931
40494
41391
41976
44026
44027
45047
45561
52219
56315

SDRTrunk recently enabled a feature to send the voice traffic to all talkgroups found in the call. I am recording calls on my machine which have unknown talkgroups names associated. I have seen traffic being recorded for several of the talkgroups listed above. My SDR is receiving the traffic with multiple talkgroups, I don't know what I can do about that.

 

[blantonl]

SDRTrunk recently enabled a feature to send the voice traffic to all talkgroups found in the call. I am recording calls on my machine which have unknown talkgroups names associated. I have seen traffic being recorded for several of the talkgroups listed above. My SDR is receiving the traffic with multiple talkgroups, I don't know what I can do about that.

Umm... turn that feature off? 😏

 

[mtindor]

I have a BCFY Calls feed for Ohio MARCS. At least one other individual is providing a similar feed for the same site (3.1 Jefferson Co Simulcast). I don't know who the other guy is, but he and I both use SDRTrunk to upload calls.

I have a playlist configured. And a playlist should be playing _all_ Saline Twp PD traffic. You'll notice that on BCFY screenshot (my playlist) there is one blurb at 10:41:19 for SALINE TWP PD. If I listen to it, it was less than a second and didn't contain more than a blurb of what was really said.

Then if you look at the SDRTrunk screenshot you'll see that SDRTrunk actually caught the full dialog (two back-n-forths between dispatch and car) of about 16 seconds. The vast majority of that did not make it to BCFY.

Did BCFY reject them all (both from me and the other provider)? Does the other provider even provide SALINE TWP PD calls? No idea. But looks like some problem somewhere between SDRTrunk and BCFY. Others have reported similar findings in another thread, and they report that the problems go away if they switch to Trunk Recorder (although I don't know if that's definitive/proven).

 

[blantonl]

you can click on an individual call details (magnifying glass) and see which node captured the call.

 

[mtindor]

you can click on an individual call details (magnifying glass) and see which node captured the call.

Thanks, I see that now. That blurb at 10:41:19 was uploaded by me. But I don't think it is any issue with me, per se. I think it's likely an issue with SDRTrunk and may likely happen to whomever, providing whatever Calls feed, with SDRTrunk (based upon reports in another thread).

So just throwing it out there that it is possible that there may be a bit of missing audio from those using SDRTrunk to upload to BCFY calls. I can't prove it. I know the audio exists in my recordings but isn't on BCFY. But I don't see facility within SDRTRunk that would give any clue (via logging) of why it happened.

I'll try to engage @DSheirer about this in the future.

Mike

 

[Napalm]

Thanks, I see that now. That blurb at 10:41:19 was uploaded by me. But I don't think it is any issue with me, per se. I think it's likely an issue with SDRTrunk and may likely happen to whomever, providing whatever Calls feed, with SDRTrunk (based upon reports in another thread).

So just throwing it out there that it is possible that there may be a bit of missing audio from those using SDRTrunk to upload to BCFY calls. I can't prove it. I know the audio exists in my recordings but isn't on BCFY. But I don't see facility within SDRTRunk that would give any clue (via logging) of why it happened.

I'll try to engage @DSheirer about this in the future.

Mike

There are some threads over on the SDRTrunk group about missing/distorted audio.