SDRtrunk Broadcastify Calls Issues

[techlogix]

Looks like it has shown up twice since I last restarted sdrtrunk on 10/4. I will try disabling the radio ID duplicate detection. On the Windows 10 machine, I have to restart the software often because it starts to ignore that setting and my feed will get the duplicate audio from the dispatch console talking on multiple talk groups. Never had that issue on the Windows 11 machine so I just chalked that one up to a random bug.

 

[n0esc]

Just popping back in to concur with @techlogix and I am still seeing/hearing the same issue with my node as well.

Such an elusive bug.
Just to rule out the non-common factors, my node is run on a dedicated Debian stable release using one Airspy Mini and one RTL-SDR. All suggested settings related to duplicate call and recording age have been set as suggested. Also running SDRTrunk 0.6.0 Beta 1.

Last error was on 9/21 paraphrased as an error during shutdown of processing chain - Key is "null". Only occurred once.
A few rare keep-alive errors attributable to internet connection issues.
Last skew rejection was 9-18
Streamed ~151000 calls with ~800 errors.
This instance has run since 8/30/2023 without any restarts.

 

[louisik1]

All suggested settings related to duplicate call and recording age have been set as suggested.

Do you mind sharing your exact settings on the duplicate call tab?

 

[techlogix]

After a couple days of testing with all options disabled on the duplicate call tab I can confirm this did not fix the issue. I still very regularly get missing transmissions on the calls platform. No errors for those missing transmissions appear in the cmd prompt window.

I even tried starting fresh by fully removing SDRtrunk and all its files. Started with a fresh profile, fresh download of all the items from Radio Reference, and fresh setup of the streaming. Unfortunately that didn’t solve the problem

 

[n0esc]

Duplicate call detection by Talkgroup and Radio ID are both off. That greys out the lower section for suppression of listening, recording and streaming, so I would assume those being on or off would have no effect since the initial detection is off. Max recording age in the playlist for the feed is 600 seconds. my node is a comparatively low traffic, so rarely do calls get stacked, or for that matter it isn't even that often that there are simultaneous transmissions, at least not often enough to attribute that to why this type of traffic is getting dropped.

 

[louisik1]

Dang.. that sucks. Collegiate effort though.

If I get any more bright ideas I'll let you know. Sorry guys, super frustrating.

I wonder, And sorry if you mentioned this before, but do your counts increase in the main sdrtrunk window on your Calls node at the same rate you would expect to include all of the replies, or does it only increase at the same rate that broadcastify is actually showing your calls come in? I hope that makes sense.

 

[blantonl]

Those of you experiencing this issue and are operating a calls node where you are the only person broadcasting for a specific system, open a ticket with me at support@broadcastify.com and I'll disable duplicate call detection for your node to test how that works out.

Tell me in the ticket:

Your Node ID
Your Username
"I'd like to test disabling duplicate detection for my node"

Remember, only do this if you are the only person broadcasting a node for a system

Thanks,

 

[n0esc]

Those of you experiencing this issue and are operating a calls node where you are the only person broadcasting for a specific system, open a ticket with me at support@broadcastify.com and I'll disable duplicate call detection for your node to test how that works out.

Tell me in the ticket:

Your Node ID
Your Username
"I'd like to test disabling duplicate detection for my node"

Remember, only do this if you are the only person broadcasting a node for a system

Thanks,

Lindsay made this change on my node about a half an hour ago. Fairly slow node, and not a ton going on at the moment, but I will say in the 30 or so minutes of testing this so far it feels like this may be where the glitch was. Exchanges feel more complete. Some of the back and forth between dispatch and officers that before would have only caught one side of the conversation is getting both sides of the conversation. Evening shift change with all of the back to back in and out of service acknowledgements will be the real tell for my node, but so far so good.

 

[techlogix]

I wanted to provide an update. Since multiple people upload to our statewide system I can't have the duplicate detection disabled. I talked to a fellow calls uploader in the state who switched from SDRTrunk to trunk-recorder. He told me that is solved the issues of back-to-back transmissions not uploading. I listened to his node for a while and confirmed that was true. Today I switched 1 of my 2 nodes over to trunk-recorder using WSL and it is working great so far. No missed communications. This leads me to believe the issue is on the SDRTrunk side. I always update to the latest version every time a new one comes out but none of them have resolved the issue. Maybe in the future, I will see if it gets fixed on SDRTrunk and move back to it because it is so much more user-friendly.

 

[dave3825]

This leads me to believe the issue is on the SDRTrunk side. I always update to the latest version every time a new one comes out but none of them have resolved the issue.

Have you let the author know about the issue?

 

[n0esc]

Have you let the author know about the issue?

Not sure how closely he's been following updates in this thread, but @DSheirer is the author of SDRTrunk and was active when this was first reported.

I'm not so sure it's a bug so much as it is just the difference in methodology of how each call is "packaged" by the different software, and back to back calls of similar length in rapid succession from the method SDRTrunk is using are being picked up as duplicates by BCFY. In a perfect world that wouldn't happen, but weird bugs crop up everywhere. Last week RR was fixing date stamps of database updates that were pulling from completely unrelated fields. No particular rhyme or reason. And in that case only one person was involved. Now try and coordinate the functions on BCFY, with SDRTrunk, TrunkRecorder, the myriad of smaller and more fringe options, and make changes that don't break any of the 636 online feeds, regardless of what solution they've implemented. The somewhat unknown question at this point as it isn't totally germane to this thread is whether or not this is being seen by any other feeders using other software.

 

[DSheirer]

I don't normally have time to follow all threads on RR. Just happened to see this thread ... I created an issue in sdrtrunk for this: Broadcastify Calls - HTTP 503 Error - Slow Down Request Rate · Issue #1736 · DSheirer/sdrtrunk

Denny

 

[chriswheeler795]

Just popping in to say that I am having same issue. About 1/3 make it to broadcastify, but if I do a stream to Openmhz with duplicate settings just a different service, they all get uploaded correctly. Almost seems that broadcastify is keeping them from getting uploaded somehow, but if that were the case I'd think they would still show as streamed but just show up in the error box.... Idk. Mystery for sure. If I could get this fixed, I would have a SOLID setup for my community.

 

[blantonl]

Just popping in to say that I am having same issue. About 1/3 make it to broadcastify, but if I do a stream to Openmhz with duplicate settings just a different service, they all get uploaded correctly. Almost seems that broadcastify is keeping them from getting uploaded somehow, but if that were the case I'd think they would still show as streamed but just show up in the error box.... Idk. Mystery for sure. If I could get this fixed, I would have a SOLID setup for my community.

Are you viewing calls and making this determination based on your individual node? Because there is another node providing calls for the system you are monitoring

You can view ALL the received calls for the entire system here:

St. Mary's County - All Calls Live

Trunked System: St. Mary's County - All Received Calls

www.broadcastify.com

You shouldn't be listening to a system based on what your individual node is sending. You should listen via playlists, which ensure that all calls received for those talkgroups are presented to you, or listen to an individual talkgroup.

 

[mtindor]

Can SDRTrunk log information related to the Broadcastify Calls uploading (success / failure / duplicates)? If so, where is that enabled and in what logs is it seen? I thought that this information could be logged but wasn't by default, but as I look through all of the options now I can't seem to find anything that mentions logging of Streaming.

 

[belvdr]

Can SDRTrunk log information related to the Broadcastify Calls uploading (success / failure / duplicates)? If so, where is that enabled and in what logs is it seen? I thought that this information could be logged but wasn't by default, but as I look through all of the options now I can't seem to find anything that mentions logging of Streaming.

My first attempt would be to check logging.properties. The file looks almost like a template, so I'm not sure if it will do anything. Here's a snippet:

 Default global logging level.
# This specifies which kinds of events are logged across
# all loggers.  For any given facility this global level
# can be overridden by a facility-specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= INFO

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1

 

[mtindor]

My first attempt would be to check logging.properties. The file looks almost like a template, so I'm not sure if it will do anything. Here's a snippet:

 Default global logging level.
# This specifies which kinds of events are logged across
# all loggers.  For any given facility this global level
# can be overridden by a facility-specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= INFO

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1

Thanks, I just figured that somewhere in SDRTrunk there may have already been a place in the GUI where Broadcastify Call activity is shown / errors logged, or at least a checkbox to enable such a thing. Maybe not.

 

[Twister_2]

You can view ALL the received calls for the entire system here:

This would be fine and true if the suspected duplicate calls weren’t deleted. It’s been a few months so I went back to check and yet again the system wide calls page still misses more transmissions than it catches. Any time there is a back and forth conversation, I’m lucky to hear 50% of it.

If we need duplicate call protection, can we only implement it on the combined feeds that pull from multiple users’ nodes? Is it possible to turn it off for individual nodes? Right now the Dauphin County SCIN calls feed is useless - I’m uploading hundreds of thousands of transmissions that nobody can even listen to. Seems counter productive to the essence of duplicate deletion.

 

[techlogix]

I will chime in and say that even when listening to all received calls on the entire WV SIRN system, a lot of back-to-back transmissions are missed to the point that I can't reliably listen to it. Audio feeds are the only reliable way to hear all the traffic.

 

[techlogix]

I wanted to say that after the change in the back-end for the calls system, I am noticing a huge improvement in the back-to-back transmissions. I've been listening to my node that uses SDRtrunk and it's very close to perfectly getting all the transmissions. I have still heard a few missed ones here and there (even using playlists to listen) but WAY less than before. I think it's good enough to change my other node that is using Trunk-Recorder back to SDRtrunk.