SDRtrunk Broadcastify Calls Issues

[Twister_2]

I run SDRtrunk v0.5.2 with one Airspy r2 on a very robust windows 10 machine hardwired straight to my unify router with 400/400Mbps fiber service. I decode the Dauphin Simulcast cell of SCIN and provide a conventional audio feed and a calls node directly from the program. Decode rate is great and very few calls are garbled or not decoded by the software.

I am having issues with the calls getting uploaded to Broadcastify Calls. I have a significant number of calls not get uploaded to Broadcastify despite being decoded in the program and being uploaded to the feed. I have done the following to isolate the problem.

1. Confirmed no duplicate call protection is enabled in SDRtrunk.
2. Reduced the number of talkgroups set to stream to each feed to the same 8 talkgroups.
3. Tried different versions of software.
4. Confirmed no upload errors on the streaming window.

A few related observations:

1. Most of the missed call uploads occur when there is a series of quick transmissions on a single talkgroup by one or more radio ID. For example, an EMS dispatch consists of an alert tone from the dispatch console ID followed by a short unkey and rekey from the same radio ID with the voice dispatch. The tone alert gets uploaded to the calls node but usually the voice dispatch doesn’t. Also when there’s a back and forth between two units of different radio ID, flip a coin as to what gets uploaded after the initial call.

2. I disabled the audio stream and may have improved the upload rate on calls. It’s hard to be confident because I don’t have the number of audio feed uploads to compare to but by comparing the calls node to a subscriber unit, it seems less are missed. If this is a remedy it presents an issue because the majority of users are using the feed and I’m the only one who appreciates having an archive of calls by PTT. I don’t want to ditch the feed.

3. I made a similar post to the SDRtrunk Facebook group but couldn’t find any valuable input there. One said I must be fine since I don’t have any upload errors listed under the streaming window.

I attached some screenshots to show the discrepancy. Sometimes it gets as bad as 3:1 success rates.

 

[DSheirer]

Are both channel configurations using the exact same alias list name?
Is every alias that you're streaming, set to dual-stream to both calls and feed?

Are both channels using P25 protocol, or is one P25 and the other FM simulcast? The squelching behavior of the FM decoder may allow multiple call segments to be aggregated into one call, resulting in fewer total call streams/uploads. The P25 decoder detects breaks in transmissions and fragments the call audio into multiple segments. If they're both using P25, the simulcast may be doing some level of call segment fusing as well.

If you record the audio for both streams and do a comparison between the recorded audio for each call, do you see any audio missing on one or the other stream? If you set all of the aliases that you are currently streaming to also record, you should have access to exactly what is being streamed from each channel, minus any audio segments that get 'aged-off' or 'rejected' by the broadcastify calls system when it detects that the call is duplicate to a call sourced from another provider.

 

[Twister_2]

Are both channel configurations using the exact same alias list name?

I only have one channel configuration. One channel configuration with two streaming options.

Is every alias that you're streaming, set to dual-stream to both calls and feed?

I have an identical list of 8 talkgroups set to stream both the audio feed and calls platform upload.

Are both channels using P25 protocol, or is one P25 and the other FM simulcast?

Again, only one channel setup. LSM.

If you record the audio for both streams and do a comparison between the recorded audio for each call, do you see any audio missing on one or the other stream?

If I understand your question correctly, yes. I miss a significant number of back to back calls on my calls node that I confirm are present on my audio feed.

 

[Twister_2]

Upon closer inspection, the calls that fail to make it to my calls node, sit in the queue for the node upload for a split second then disappear without ever getting added to the uploaded or failed list. They just disappear. Is RR denying them maybe?

 

[DSheirer]

Are you seeing any errors in the application log?

 

[Twister_2]

Yes a few recurring errors. The most frequent one I assume is unrelated? I also see some that specifically deal with the audio feed but after a quick glance I do not see any explicitly about the calls node.

20230322 081809.118 [NioProcessor-2] INFO i.g.d.a.b.AudioStreamingBroadcaster - [Dauphin County Fire and EMS Dispatch - Digital] status: Disconnected [1GB/1GB 77%]
20230322 081813.013 [NioProcessor-12] INFO i.g.d.a.b.AudioStreamingBroadcaster - [Dauphin County Fire and EMS Dispatch - Digital] status: Connected [1GB/1GB 75%]
20230322 082646.930 [AWT-EventQueue-0] INFO i.github.dsheirer.gui.SDRTrunk - Application shutdown started ... [829MB/1GB 50%]
20230322 082646.936 [AWT-EventQueue-0] INFO i.github.dsheirer.gui.SDRTrunk - Stopping channels ... [841MB/1GB 51%]
20230322 082646.937 [AWT-EventQueue-0] INFO i.github.dsheirer.gui.SDRTrunk - Stopping spectral display ... [845MB/1GB 51%]
20230322 082646.938 [AWT-EventQueue-0] INFO i.github.dsheirer.gui.SDRTrunk - Stopping tuners ... [848MB/1GB 51%]
20230322 082646.942 [AWT-EventQueue-0] INFO i.g.d.s.t.m.DiscoveredTuner - Stopping Tuner: Airspy USB Bus:2 Port:4 [855MB/1GB 52%]
20230322 082646.942 [sdrtrunk USB tuner - bus [2] port [4]] ERROR i.g.d.s.t.u.USBTunerController - Error submitting USB transfer - LIBUSB_ERROR_NOT_FOUND [855MB/1GB 52%]
20230322 082646.944 [sdrtrunk USB tuner - bus [2] port [4]] INFO i.g.d.s.t.m.DiscoveredTuner - Tuner Error - Stopping - Airspy USB Bus:2 Port:4 Error: Usb I/O Error - Can't submit buffers to tuner - stopping tuner [855MB/1GB 52%]
20230322 082646.944 [sdrtrunk USB tuner - bus [2] port [4]] INFO i.g.d.s.t.m.DiscoveredTuner - Stopping Tuner: Airspy USB Bus:2 Port:4 [855MB/1GB 52%]
20230322 082655.591 [main] INFO i.g.d.log.ApplicationLog - SDRTrunk Version : 0.5.2 [7MB/512MB 1%]
20230322 082655.592 [main] INFO i.g.d.log.ApplicationLog - Gradle Version : Gradle 7.6 [7MB/512MB 1%]
20230322 082655.593 [main] INFO i.g.d.log.ApplicationLog - Build Timestamp : 2023-03-05T07:05:49.414-0500 [7MB/512MB 1%]
20230322 082655.593 [main] INFO i.g.d.log.ApplicationLog - Build-JDK : 19.0.1 (BellSoft 19.0.1+11 [7MB/512MB 1%]
20230322 082655.593 [main] INFO i.g.d.log.ApplicationLog - Build OS : Windows 10 (amd64 10.0 [7MB/512MB 1%]
20230322 082655.593 [main] INFO i.g.d.log.ApplicationLog - [7MB/512MB 1%]
20230322 082655.594 [main] INFO i.g.d.log.ApplicationLog - ******************************************************************* [7MB/512MB 1%]
20230322 082655.594 [main] INFO i.g.d.log.ApplicationLog - **** sdrtrunk: a trunked radio and digital decoding application *** [7MB/512MB 1%]
20230322 082655.594 [main] INFO i.g.d.log.ApplicationLog - **** website: GitHub - DSheirer/sdrtrunk: A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website: *** [7MB/512MB 1%]
20230322 082655.594 [main] INFO i.g.d.log.ApplicationLog - ******************************************************************* [7MB/512MB 1%]
20230322 082655.595 [main] INFO i.g.d.log.ApplicationLog - Memory Logging Format: [Used/Allocated PercentUsed%] [7MB/512MB 1%]
20230322 082655.595 [main] INFO i.g.d.log.ApplicationLog - Host OS Name: Windows 10 [7MB/512MB 1%]
20230322 082655.595 [main] INFO i.g.d.log.ApplicationLog - Host OS Arch: amd64 [7MB/512MB 1%]
20230322 082655.595 [main] INFO i.g.d.log.ApplicationLog - Host OS Version: 10.0 [7MB/512MB 1%]
20230322 082655.596 [main] INFO i.g.d.log.ApplicationLog - Host CPU Cores: 8 [7MB/512MB 1%]
20230322 082655.596 [main] INFO i.g.d.log.ApplicationLog - Host Max Java Memory: 7 GB [7MB/512MB 1%]
20230322 082655.596 [main] INFO i.g.d.log.ApplicationLog - Storage Directories: [7MB/512MB 1%]
20230322 082655.597 [main] INFO i.g.d.log.ApplicationLog - Application Root: C:\Users\mbrul\SDRTrunk [7MB/512MB 1%]
20230322 082655.597 [main] INFO i.g.d.log.ApplicationLog - Application Log: C:\Users\mbrul\SDRTrunk\logs [7MB/512MB 1%]
20230322 082655.598 [main] INFO i.g.d.log.ApplicationLog - Event Log: C:\Users\mbrul\SDRTrunk\event_logs [7MB/512MB 1%]
20230322 082655.599 [main] INFO i.g.d.log.ApplicationLog - Playlist: C:\Users\mbrul\SDRTrunk\playlist [7MB/512MB 1%]
20230322 082655.600 [main] INFO i.g.d.log.ApplicationLog - Recordings: C:\Users\mbrul\SDRTrunk\recordings [7MB/512MB 1%]
20230322 082655.600 [main] INFO i.g.dsheirer.util.ThreadPool - Application thread pool created SCHEDULED and CACHED executors threads [7MB/512MB 1%]
20230322 082655.601 [main] INFO i.github.dsheirer.gui.SDRTrunk - Home path: C:\Users\mbrul\SDRTrunk [7MB/512MB 1%]
20230322 082655.606 [main] INFO i.g.d.p.SystemProperties - SystemProperties - loaded [C:\Users\mbrul\SDRTrunk\SDRTrunk.properties] [7MB/512MB 1%]
20230322 082655.608 [main] INFO i.g.d.p.SystemProperties - SystemProperties - application properties loaded [C:\Users\mbrul\SDRTrunk\SDRTrunk.properties] [7MB/512MB 1%]
20230322 082655.832 [main] INFO i.g.d.s.t.manager.TunerManager - Discovering tuners ... [14MB/56MB 26%]
20230322 082655.946 [main] INFO i.g.d.s.t.manager.TunerManager - LibUsb API Version: 1.0.262 [15MB/56MB 28%]
20230322 082655.947 [main] INFO i.g.d.s.t.manager.TunerManager - LibUsb Version: 1.0.22.11312 [15MB/56MB 28%]
20230322 082656.090 [main] INFO i.g.d.s.t.manager.TunerManager - LibUsb - discovered [6] potential usb devices [16MB/56MB 28%]
20230322 082656.096 [main] INFO i.g.d.s.t.manager.TunerManager - Discovered tuner at USB Bus [2] Port [4] Tuner Class [Airspy] [16MB/56MB 28%]
20230322 082656.099 [main] INFO i.g.d.s.t.manager.TunerManager - Tuner: USB Tuner - Airspy USB Bus:2 Port:4 - Added / Starting ... [16MB/56MB 29%]
20230322 082656.147 [main] WARN i.g.d.vector.VectorUtilities - CPU supports maximum SIMD instructions of Species[float, 8, S_256_BIT] [18MB/56MB 33%]
20230322 082656.211 [main] INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [10000000.0] providing [400] channels at [25000.0] Hz each [20MB/56MB 37%]
20230322 082656.212 [main] INFO i.g.d.s.t.manager.TunerManager - Tuner: USB Tuner - Airspy USB Bus:2 Port:4 - Applying Tuner Configuration [20MB/56MB 37%]
20230322 082656.219 [main] INFO i.g.d.s.t.manager.TunerManager - LibUsb Hotplug event notification Is Not Supported on this platform. [21MB/56MB 37%]
20230322 082656.227 [main] INFO i.g.d.settings.SettingsManager - SettingsManager - loading settings file [C:\Users\mbrul\SDRTrunk\settings\settings.xml] [21MB/56MB 37%]
20230322 082657.262 [main] INFO i.g.d.playlist.PlaylistManager - Loading playlist [C:\Users\mbrul\SDRTrunk\playlist\default.xml] [23MB/56MB 41%]
20230322 082657.588 [main] WARN i.g.d.p.mp3.MP3Preference - MP3 Setting [CBR - Constant Bit Rate 16 kbps (default)] does not support input sample rate [SR_22050] - updating to supported sample rate [SR_16000] [26MB/56MB 47%]
20230322 082657.927 [NioProcessor-2] INFO i.g.d.a.b.AudioStreamingBroadcaster - [Dauphin County Fire and EMS Dispatch - Digital] status: Connected [41MB/284MB 14%]
20230322 082658.146 [main] INFO i.github.dsheirer.gui.SDRTrunk - starting main application gui [53MB/284MB 18%]
20230322 082701.544 [AWT-EventQueue-0] INFO i.g.d.c.c.ChannelAutoStartFrame - Channel auto-start canceled by user [124MB/284MB 43%]
20230322 082757.471 [sdrtrunk cached thread 2] INFO i.g.d.a.c.mbe.JmbeAudioModule - Loading JMBE library from [C:\Users\mbrul\SDRTrunk\jmbe\jmbe-1.0.9.jar] [142MB/412MB 34%]
20230322 082757.481 [sdrtrunk cached thread 2] INFO i.g.d.a.c.mbe.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.9 [142MB/412MB 34%]
20230322 082757.481 [sdrtrunk cached thread 2] INFO i.g.d.a.c.mbe.ImbeAudioModule - JMBE audio conversion library IMBE CODEC successfully loaded - P25-1 audio will be available [142MB/412MB 34%]
20230322 082757.495 [sdrtrunk cached thread 2] INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [10000000.0] providing [400] channels at [25000.0] Hz each [144MB/412MB 35%]
20230322 083518.077 [sdrtrunk polyphase channel] ERROR i.g.d.d.f.c.neChannelOutputProcessor - Error extracting channel samples from one polyphase channel results buffer [3GB/3GB 81%]
java.lang.ArrayIndexOutOfBoundsException: Index 500 out of bounds for length 500
at java.desktop/javax.swing.DefaultRowSorter.setModelToViewFromViewToModel(Unknown Source)
at java.desktop/javax.swing.DefaultRowSorter.rowsDeleted0(Unknown Source)
at java.desktop/javax.swing.DefaultRowSorter.rowsDeleted(Unknown Source)
at java.desktop/javax.swing.JTable.notifySorter(Unknown Source)
at java.desktop/javax.swing.JTable.sortedTableChanged(Unknown Source)
at java.desktop/javax.swing.JTable.tableChanged(Unknown Source)
at java.desktop/javax.swing.table.AbstractTableModel.fireTableChanged(Unknown Source)
at java.desktop/javax.swing.table.AbstractTableModel.fireTableRowsDeleted(Unknown Source)
at io.github.dsheirer.module.decode.event.DecodeEventModel.prune(DecodeEventModel.java:174)
at io.github.dsheirer.module.decode.event.DecodeEventModel.receive(DecodeEventModel.java:159)
at io.github.dsheirer.module.decode.event.DecodeEventModel.receive(DecodeEventModel.java:38)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.module.HistoryModule.receive(HistoryModule.java:108)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.sample.Broadcaster.receive(Broadcaster.java:50)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.channel.state.AbstractDecoderState.broadcast(AbstractDecoderState.java:83)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.processBroadcast(P25P1DecoderState.java:657)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.processBroadcast(P25P1DecoderState.java:651)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.processTSBKUnitRegistrationResponse(P25P1DecoderState.java:1499)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.processTSBK(P25P1DecoderState.java:1212)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.receive(P25P1DecoderState.java:308)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderState.receive(P25P1DecoderState.java:153)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.sample.Broadcaster.receive(Broadcaster.java:50)
at io.github.dsheirer.module.decode.Decoder$MessageDistributor.receive(Decoder.java:97)
at io.github.dsheirer.module.decode.Decoder$MessageDistributor.receive(Decoder.java:90)
at io.github.dsheirer.module.decode.p25.phase1.P25P1MessageProcessor.receive(P25P1MessageProcessor.java:92)
at io.github.dsheirer.module.decode.p25.phase1.P25P1MessageProcessor.receive(P25P1MessageProcessor.java:34)
at io.github.dsheirer.module.decode.p25.phase1.P25P1MessageFramer.dispatchMessage(P25P1MessageFramer.java:325)
at io.github.dsheirer.module.decode.p25.phase1.P25P1MessageFramer.receive(P25P1MessageFramer.java:204)
at io.github.dsheirer.module.decode.p25.phase1.P25P1MessageFramer.receive(P25P1MessageFramer.java:70)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.sample.Broadcaster.receive(Broadcaster.java:50)
at io.github.dsheirer.dsp.psk.PSKDemodulator.broadcast(PSKDemodulator.java:61)
at io.github.dsheirer.dsp.psk.DQPSKGardnerDemodulator.calculateSymbol(DQPSKGardnerDemodulator.java:88)
at io.github.dsheirer.dsp.psk.PSKDemodulator.receive(PSKDemodulator.java:117)
at io.github.dsheirer.dsp.psk.PSKDemodulator.receive(PSKDemodulator.java:93)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderLSM.receive(P25P1DecoderLSM.java:116)
at io.github.dsheirer.module.decode.p25.phase1.P25P1DecoderLSM.receive(P25P1DecoderLSM.java:39)
at io.github.dsheirer.sample.Broadcaster.broadcast(Broadcaster.java:151)
at io.github.dsheirer.sample.Broadcaster.receive(Broadcaster.java:50)
at io.github.dsheirer.source.tuner.channel.StreamProcessorWithHeartbeat.receive(StreamProcessorWithHeartbeat.java:118)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelSource.receive(PolyphaseChannelSource.java:149)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelSource.receive(PolyphaseChannelSource.java:43)
at io.github.dsheirer.dsp.filter.channelizer.output.OneChannelOutputProcessor.process(OneChannelOutputProcessor.java:109)
at io.github.dsheirer.dsp.filter.channelizer.output.ChannelOutputProcessor.lambda$new$0(ChannelOutputProcessor.java:50)
at io.github.dsheirer.util.Dispatcher$Processor.run(Dispatcher.java:182)
at java.base/java.lang.Thread.run(Unknown Source)
20230322 083524.809 [sdrtrunk polyphase channel] ERROR i.g.d.d.f.c.neChannelOutputProcessor - Error extracting channel samples from one polyphase channel results buffer [1GB/1GB 74%]
java.lang.ArrayIndexOutOfBoundsException: null
20230322 083524.862 [sdrtrunk polyphase channel] ERROR i.g.d.d.f.c.neChannelOutputProcessor - Error extracting channel samples from one polyphase channel results buffer [279MB/1GB 13%]
java.lang.ArrayIndexOutOfBoundsException: null
20230322 083524.945 [sdrtrunk polyphase channel] ERROR i.g.d.d.f.c.neChannelOutputProcessor - Error extracting channel samples from one polyphase channel results buffer [525MB/1GB 25%]
java.lang.ArrayIndexOutOfBoundsException: null
20230322 083532.100 [sdrtrunk polyphase channel] : null

 

[Twister_2]

Additional info:

I decided to create a new channel configuration with a new alias list, both being identical to the original. I assigned one alias list as the feed audio provider and the other as the calls node provider. With two channels running, I am still getting a boatload of traffic to sit in the calls node upload queue for a split second before disappearing - never uploading to the node - but still uploading to the audio feed. The missed calls are still mainly the quick back and forth between two units.

 

[Twister_2]

Here's a short video showing a voice call go to the queue but disappear without ever uploading. Video on Google Photos

 

[scan18]

I run SDRtrunk v0.5.2 with one Airspy r2 on a very robust windows 10 machine hardwired straight to my unify router with 400/400Mbps fiber service. I decode the Dauphin Simulcast cell of SCIN and provide a conventional audio feed and a calls node directly from the program. Decode rate is great and very few calls are garbled or not decoded by the software.

I am having issues with the calls getting uploaded to Broadcastify Calls. I have a significant number of calls not get uploaded to Broadcastify despite being decoded in the program and being uploaded to the feed. I have done the following to isolate the problem.

1. Confirmed no duplicate call protection is enabled in SDRtrunk.
2. Reduced the number of talkgroups set to stream to each feed to the same 8 talkgroups.
3. Tried different versions of software.
4. Confirmed no upload errors on the streaming window.

A few related observations:

1. Most of the missed call uploads occur when there is a series of quick transmissions on a single talkgroup by one or more radio ID. For example, an EMS dispatch consists of an alert tone from the dispatch console ID followed by a short unkey and rekey from the same radio ID with the voice dispatch. The tone alert gets uploaded to the calls node but usually the voice dispatch doesn’t. Also when there’s a back and forth between two units of different radio ID, flip a coin as to what gets uploaded after the initial call.

2. I disabled the audio stream and may have improved the upload rate on calls. It’s hard to be confident because I don’t have the number of audio feed uploads to compare to but by comparing the calls node to a subscriber unit, it seems less are missed. If this is a remedy it presents an issue because the majority of users are using the feed and I’m the only one who appreciates having an archive of calls by PTT. I don’t want to ditch the feed.

3. I made a similar post to the SDRtrunk Facebook group but couldn’t find any valuable input there. One said I must be fine since I don’t have any upload errors listed under the streaming window.

I attached some screenshots to show the discrepancy. Sometimes it gets as bad as 3:1 success rates.

I know this thread is rather old, but just wanted to mention that I am seeing something very similar. I don't believe the issue is specific to SDRTrunk, because I tried turning off the Calls upload in SDR Trunk and activated the upload from my Trunking Recorder instance which is ingesting the SDR Trunk recordings. The log file is clearly showing that Broadcastify is rejecting some calls randomly as a duplicate even though I know for a fact it's not a duplicate. The reason I know is because the TG in question is not present on the one other node in my county, and if I review all the traffic for that one TG systemwide in the Calls database, the calls are still missing. So that means no one else is uploading that TG.
As you mentioned, the issue seems to happen during quick back and forth transmissions.

And to take SDR Trunk completely out of the mix, I setup another instance of Trunking Recorder on another PC to ingest ProScan recordings of the TG from my BCD996P2 and I still see that TG occasionally being rejected as a duplicate. It's not quite as bad because the 996P2/Proscan is combining the transmissions into longer MP3 files, so it's not as many files as how SDR Trunk outputs them. I can't really prove it, but I suspect something is amiss in how Broadcastify is identifying duplicates. It's like it thinks my own surrounding transmissions of that TG are duplicates or something.

 

[n0esc]

Going to add my six rupees to the pile here and add that I feel that I am seeing the same behaviour. My process of elimination was switching from an older SFF Win10 PC to updated PC running Debian purpose configured for SDRTrunk. It's "dropping" calls in the same manner as described by Twister_2 and scan18, though I haven't had a chance to look at any log or upload activity as the machine is running headless currently. My main goal in the switch was stability and more reliable restarts after any power failures or service disruption.

Similar to Twister_2, I see this happen when it is several calls in quick succession, with PD dispatcher and an officer exchanging info for a call, or likewise with EMS. A single "dispatch" for police or EMS around here typically is a 4-5 transmission exchange, most less than a second or so, and it seems like the second to last is the one that gets dropped. I'll hear an officer call dispatch, their ack, then nothing, and a final 10-4 from the dispatcher, all in the span of 10 or so seconds.

 

[techlogix]

Same issue here. I have 2 nodes with SDRTrunk (2 separate computers) and find that back-and-forth conversations will have a few missed transmissions. I also regularly have the issue of no voice after tones. This has been going on since I setup the nodes months ago. I also have audio streams running on the same SDRTrunk instances and they catch everything with no problems.

I should add that these 2 nodes have no overlapping channels with each other or with any other nodes.

 

[louisik1]

This may only be worth two rupees, but have you set your max recording age to something reasonable? I have mine set to 10 minutes and sometimes the call queue gets over 100 calls waiting to be uploaded. I think if it was set to only a couple seconds, then any queued up recordings that your system made would basically be immediately purged and not uploaded to broadcastify.

 

[Twister_2]

Still have this issue and it has only gotten worse. I am actively monitoring the system with a portable and SDR trunk. SDR trunk is receiving all of the voice calls but only a very VERY few are making it online to Broadcastify's calls platform. Yes, there is another user of the same TRS supplying calls to his own node, but even when you listen to the combination of both feeds in the systemwide calls, we're still missing a bunch. It makes it nearly impossible to hear a back and forth conversation whatsoever.

If there must be duplicate call filtering but it doesn't work right, please let us monitor our individual node without any filtering. I understand the necessity to filter but its current configuration makes my node ineffectual.

Thank you.

 

[louisik1]

I'm not sure if this helps, but if I go to the Broadcastify (web) Listen menu, then the Calls Platform, the next page has some menu 'buttons'



If I click on Manage, it shows my node:



When I click on the lightning bolt ('Node Live Calls'), it takes me to my node where I can monitor just my uploads.



Also, the url is simple in that it just takes my node number to navigate to my node: ://www.broadcastify.com/calls/node/2353

 

[techlogix]

I’m also still having the issue of back to back communications not being uploaded to the Calls platform. No one else is uploading the same talkgroups so it’s not an issue of getting declined for duplication. If this issue could be resolved, I would use Calls playlists every day but it just misses so much traffic from back to back talking between dispatch and units. The regular audio feeds being streamed by the same computer/software have no missed traffic.

 

[louisik1]

What version of sdrtrunk are you guys using? And how long has this been going on for? Can you explain a bit about how your system is configured in terms of hardware, tuners, and software?

 

[techlogix]

What version of sdrtrunk are you guys using? And how long has this been going on for? Can you explain a bit about how your system is configured in terms of hardware, tuners, and software?

I'm using the latest 0.6.0 beta 2 of sdrtrunk. This issue has been going on since I started streaming back on version 0.5.0 beta 5. I update to the latest once each time just to see if it fixes this issue. The system is the WV SIRN system. I have 2 separate computers (each one in a separate location) running 2 different Calls nodes. Each node is for a different county and tower. The nodes do not have any overlap in talk groups nor do they overlap with other nodes in WV. One node is setup using two RTL-SDR v3 dongles. The other node is setup using two Airspy Minis. One computer is running Windows 10, while the other is using Windows 11. Each computer has at least 2 Broadcastify audio feeds and 1 Calls upload. As mentioned earlier, all traffic, including back to back communications, are heard through the speakers of the computer and through the Broadcastify audio feeds. It's just the Calls uploads that misses those back to back communications.

 

[louisik1]

Are you using any other software (trunking recorder,etc) besides the sdrtrunk in your broadcasting setup?

In the main sdrtrunk window, the bottom pane that lists your broadcasts has the columns Aged Off and Upload Error. Do you see an unusual amount for either?

Is the Java cmd window giving any clues? It tells me when Broadcastify rejects a call for excessive skew, for example.

In the sdrtrunk settings, under Audio - Duplicate Calls, what are your settings for those five options?

Are you using one Playlist/Channel for all your broadcasts or multiple?

 

[techlogix]

Are you using any other software (trunking recorder,etc) besides the sdrtrunk in your broadcasting setup?

In the main sdrtrunk window, the bottom pane that lists your broadcasts has the columns Aged Off and Upload Error. Do you see an unusual amount for either?

Is the Java cmd window giving any clues? It tells me when Broadcastify rejects a call for excessive skew, for example.

In the sdrtrunk settings, under Audio - Duplicate Calls, what are your settings for those five options?

Are you using one Playlist/Channel for all your broadcasts or multiple?

No other software being used for broadcasting.

No aged off uploads. I do get upload errors occasionally. The CMD windows says the errors are a 503 error "Please reduce your request rate". Although that CMD error only shows a couple times vs the bottom pane of sdrtrunk shows over 160 upload errors and 51,702 successful uploads.

For duplicate calls I have just Radio ID enabled, that way the audio feeds don't hear Fire/EMS dispatch audio repeated due to the dispatcher selecting both the fire and ems channels during dispatching of a call. Suppression enabled on all methods. Although I don't do any recording with sdrtrunk.

Each computer just has a single playlist/channel setup for a single phase 1 non-simulcast tower.

 

[louisik1]

I have just Radio ID enabled

All your other answers seem good. But this one, have you tried disabling the Radio ID duplicate detection, even though it duplicates on the audio broadcasts, to see if it affects the Calls issue?

I am curious about the 503 message you're getting too. How often do you get that?