Broadcastify Calls Duplicate Calls Handing Updates
- Thread starter blantonl
- Start date
egftechman
Member
- Joined
- Dec 26, 2023
- Messages
- 87
There was mention of a calls API for third party players. What is typical licensing or allowed use for such?
Looking creating an app that will play talkgroups based on the listener's regularly updated location, so if like one is on a cross country trip, they could listen local stuff the whole way. (Side project for me, if someone has adequate time to devote to it, please run with the idea).
Looking creating an app that will play talkgroups based on the listener's regularly updated location, so if like one is on a cross country trip, they could listen local stuff the whole way. (Side project for me, if someone has adequate time to devote to it, please run with the idea).
it’s based on a royalty model. Right now, we have a bunch of developers all lined up ready to go.
@blantonl This may be fixed in SDRTRunk version 0.6.1 beta 1 I'm running that as of today, and so far I have not seen any missed calls on BCFY that showed up in my SDRTrunk. I'm not sure what in the SDRTrunk changelog would be relevant to this issue. Then again, all morning i've been the preferred node for all of the traffic (and maybe that has something to do with it).
At any rate, looking good this morning. Let's hope it holds up.
Thanks for the update, it appears this also fixes the patch talkgroup problem that was driving me nuts as well, updating now.
Sad to see whoever was running the Philly trunked system node took their stuff offline after the recent changes. Can't use playlists if there's no node to feed 'em. I was really confused at first when I brought up my playlist and it said "no traffic in the last 10 minutes". Philly barely has 10 seconds of dead air most days. Bucks County PA has had fewer dupes (maybe none) since the changes, but it has also had an increase in missed traffic on my playlist as compared to an APX radio on the system.
When this was first rolled out, the duplicates pretty much stopped. Now I'm seeing duplicates again. I haven't cought when it did it to tell what exactly is going on. Maybe @blantonl can see more into it to see what is happening? I'm not sure if it is 2 calls with same length & talk group back to back and it is thinking the 2nd one a duplicate? I'm running SDRTrunk V0.6.1 Beta 1 and the only node for the system.
What time was the pic taken? 20 ish dupes isn't bad. Did you see if someone else is feeding?
Before the changes, I was at thousands of dupes and I was and still am the only feeder for my system. Now it's in the double digits all day.
n0esc
Feed Provider
One other thing I experience at least with the system my node feeds, is when a unit subscriber radio that's supposed to be on a roaming TG so it doesn't pull traffic halfway across the state is left on one of my local TGs or vice versa and I'll pull all the traffic for a neighboring county or agency that wouldn't normally have tower priority in my area. Many of those calls would show up as duplicates since there is a [A] preferred node for the home agency, and my node will feed calls it wouldn't normally hear.
Picture was taken the same time I made the post. I know for sure I am the only person uploading calls because if computer goes down, there are no uploads to the node as I listen to it all day at work. So the only thing I can figure is that there is 2 calls in succession on same TG and one gets tagged as a duplicate. Just looked and calls system is showing 7 for today, it is now 6:33am EST and on SDRTrunk it is showing 17 upload errors. So not sure what is going on.
This is probably what happened. I wouldn't be terribly concerned about it.
Ok. Just stinks as end up missing part of a conversation LOL Oh well, I like the way it is setup, direct through SDRTrunk so not going to go through the whole setup of trunk recorder, would probably get duplicates with that also... LOL
When the change was made a few weeks ago and others reported less missed calls, I may have agreed but it may have just been a good time that I checked the system wide calls. I checked multiple times the past 7 days and it's worse than before.
I played around this morning by turning my node off (272). I continued to listen to the system wide calls (mainly supplied by node 1927) side by side with SDRtrunk v0.6.1-beta-1 and my APX. In the period of monitoring, the system wide calls did not miss a single back to back call. Upon restarting my node, it began to miss calls again.
As I type this message, BCFY completely missed out on about 60 seconds of audio spread over 9 transmissions over a 90 second period on a single TG. My SDRtrunk tried uploading each but they got rejected. The transmissions never made it to the system wide calls online. These were not even the typical back to back misses.
I'm not sure what changed but it's worse than before.
I played around this morning by turning my node off (272). I continued to listen to the system wide calls (mainly supplied by node 1927) side by side with SDRtrunk v0.6.1-beta-1 and my APX. In the period of monitoring, the system wide calls did not miss a single back to back call. Upon restarting my node, it began to miss calls again.
As I type this message, BCFY completely missed out on about 60 seconds of audio spread over 9 transmissions over a 90 second period on a single TG. My SDRtrunk tried uploading each but they got rejected. The transmissions never made it to the system wide calls online. These were not even the typical back to back misses.
I'm not sure what changed but it's worse than before.
Attachments
If you restart your node, it's going to take some time for the system to "heal" and switch over to the other node to pickup where you left off. That's not an instantaneous process, it takes time for the system to learn that your node is no longer providing calls for the network. During that switchover process it is entirely possible to miss a few calls as the system heals.
I get that but it happens all the time. The link here is to a video on Google drive that I captured this morning. There was a crash down the street from me that took down my power and put my calls offline. This calls in this video were supplied by the other calls supplier and him alone. After each beep there should have been a dispatch. It missed every dispatch.
RPReplay_Final1709646771.mov
drive.google.com
Did the dispatches possibly happen on a patch?
We've seen numerous instances of calls providers telling me "calls is missing transmissions" only to find the transmissions are showing up on patches. Look in the system all captured talkgroups and see if they are showing up on a patch ID somewhere.
Note that we can handle patches on the backend using a "priority" talkgroup method where we specify a list of talkgroups that are "priority" and if they get patched then we capture the transmissions on that talkgroup that is designated as a priority.
We've seen numerous instances of calls providers telling me "calls is missing transmissions" only to find the transmissions are showing up on patches. Look in the system all captured talkgroups and see if they are showing up on a patch ID somewhere.
Note that we can handle patches on the backend using a "priority" talkgroup method where we specify a list of talkgroups that are "priority" and if they get patched then we capture the transmissions on that talkgroup that is designated as a priority.
Nope not a patch. It's a pure Motorola system. Both the beep and dispatch come out on the same dedicated talkgroup. I do remember a while ago the beep would come over as RID 0 on some software with the rest of the dispatch coming over with the correct console ID but I see in the video I posted that the beeps come from the console ID too.
Ok, I'm going to make a tweak here for this. let me know if you see this behavior continue.
Thank you. I'll report back. I'm so glad there's an open dialog on how to make this service better. It means a lot to us.
