Broadcastify Calls & Feeds Duplicate Detection

[Syd-MD]

G’day all,

I’m quite new to the SDRTrunk, apologies if this has already been flagged however I couldn’t find a similar feature request.

This feature request relates to streaming to Broadcastify when using both Calls and Feeds.

I monitor a trunked network using RTL-SDR’s which has multiple agencies transmitting. The fire agency I am specifically streaming has three districts where the channels are ‘patched’ together during quiet periods. During busy periods, the patched channels are unpatched and managed separately by dispatchers.

I am hosting the district via individual ‘Feeds' and all the transmissions are sent to ‘Calls’. When the districts are merged, the system appears to be uploading triplicate calls to the Calls system where the Calls listener must listen to the three recordings. Subsequently this is uploading three times as much data.

I am unable to use the duplicate detection feature as only one of the ‘Feeds’ would receive the transmission when it should be broadcasted across all three ‘Feeds’.

Essentially it would be great if the duplicate detection feature would be able to be applied specifically to the Calls uploading only. It would be an added bonus if the uploaded Call ‘display’ details would contain an amalgamated detail of the combined details for the transmissions during the duplicate detection process, so a listener would understand what’s going on.

Thoughts? Many thanks in advance.

[swiftraccoon]

Isn't that a problem of Broadcastify and not SDRTrunk? If you try to listen to a specific talkgroup on Broadcastify Calls feed you will listen to all nodes that are uploading that talkgroup.

[N8LOL]

Yes, that is correct. Broadcastify allows duplicate nodes (sites), and it makes listening to archives a real challenge.

Sent from my Samsung Galaxy A13 5G. Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Swift Raccoon @.> Sent: Wednesday, October 4, 2023 1:26:34 AM To: DSheirer/sdrtrunk @.> Cc: Subscribed @.***> Subject: Re: [DSheirer/sdrtrunk] Broadcastify Calls & Feeds Duplicate Detection (Issue #1656)

Isn't that a problem of Broadcastify and not SDRTrunk? If you try to listen to a specific talkgroup on Broadcastify Calls feed you will listen to all nodes that are uploading that talkgroup.

— Reply to this email directly, view it on GitHubhttps://github.com/DSheirer/sdrtrunk/issues/1656#issuecomment-1746159869, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQC3R4UWWOWGFZ2K53NUTTDX5TXQVAVCNFSM6AAAAAA5HH6IMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBWGE2TSOBWHE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Syd-MD]

I wrote to Broadcastify about the situation prior to posting this, where it was put back to SDRTrunk as a responsibility.

I feel that perhaps communication between the two may be required to develop a solution.

Correct about listening to all nodes that are uploaded however does the user really want to listen to the same audio on three occasions? An advanced duplicate system is likely needed but to maintain the records of talk groups that the now one audio file was transmitted on for both solely listening to a talk group, replays etc.

I can see that perhaps the solution would best be achieved by SDRTrunk with the detection and processing completed on the hosting compute. Likewise would prevent the uploading of three audio files, compared to the one audio file where the file could be referenced on Broadcastify’s database and be available within the talk group the user may select to solely listen to.

[louisik1]

I don't understand why you think there is anything special sdrtrunk should be doing here. The only thing sdrtrunk is required to do is to send the audio clips. A person could be using a different app than sdrtrunk, or two (or more) people could be uploading duplicate content without using sdrtrunk at all.

Considering the clips are sent with metadata including channel/talkgroup, timestamp, and length, Broadcasting has the info they need to reject duplicates, don't they? If they have the ability to check for time skew and reject based on that, this would seem to be similar enough to also implement duplicate detection.

[Syd-MD]

One could say the same about Broadcastify - the only responsibility Broadcastify is required to do is broadcast to a listener the uploaded audio files and display the attached metadata. However this does not dismiss that there is an issue as to the management of duplicate calls. As I have previously stated 'communication between the two may be required to develop a solution.'

It may be feasible that another person may be using an app other than SDRTrunk however that too is something the developer of such other app would need to develop for the handling of duplicate calls, if that developer choses to adopt. This feature may be what attracts a contributor to use SDRTrunk (if feature implemented).

Considering SDRTrunk has implemented the specific API for uploading files to Broadcastify. This feature would potentially only be for uploading to Broadcastify. Realistically though, it could be used for other systems. This would ultimately be a developer decision.

As the audio files are being generated within SDRTrunk, yes they attach the metadata. This is the perfect time to detect duplicate audio files. Instead of uploading multiple files to Broadcastify, upload only one file to Broadcastify with combined listed metadata. Only one file would be available and played in the node, however would display multiple TGID’s for the user to identify that the audio clip was transmitted over the many listed TGID’s. This would then allow the display of this audio clip when a user reviews a specific TGID.

From a data management perspective it makes sense that SDRTrunk does this processing locally on the contributors server to spread this load rather than Broadcastify requiring more processing power and the implementation of a potential delay in making such data available to the listeners. Likewise it would save a contributor from uploading more data / files to Broadcastify than needed.

I would like to acknowledge the great work that the developers of SDRTrunk have completed to date, it is absolutely fantastic and I thank them for their continued development.

[N8LOL]

Absolutely keep Broadcastify separate. All they need to do is remove duplicates, which they shouldn't have allowed.

On Fri, Oct 13, 2023, 11:22 PM Syd-MD @.***> wrote:

One could say the same about Broadcastify - the only responsibility Broadcastify is required to do is broadcast to a listener the uploaded audio files and display the attached metadata. However this does not dismiss that there is an issue as to the management of duplicate calls. As I have previously stated 'communication between the two may be required to develop a solution.'

It may be feasible that another person may be using an app other than SDRTrunk however that too is something the developer of such other app would need to develop for the handling of duplicate calls, if that developer choses to adopt. This feature may be what attracts a contributor to use SDRTrunk (if feature implemented).

Considering SDRTrunk has implemented the specific API for uploading files to Broadcastify. This feature would potentially only be for uploading to Broadcastify. Realistically though, it could be used for other systems. This would ultimately be a developer decision.

As the audio files are being generated within SDRTrunk, yes they attach the metadata. This is the perfect time to detect duplicate audio files. Instead of uploading multiple files to Broadcastify, upload only one file to Broadcastify with combined listed metadata. Only one file would be available and played in the node, however would display multiple TGID’s for the user to identify that the audio clip was transmitted over the many listed TGID’s. This would then allow the display of this audio clip when a user reviews a specific TGID.

From a data management perspective it makes sense that SDRTrunk does this processing locally on the contributors server to spread this load rather than Broadcastify requiring more processing power and the implementation of a potential delay in making such data available to the listeners. Likewise it would save a contributor from uploading more data / files to Broadcastify than needed.

I would like to acknowledge the great work that the developers of SDRTrunk have completed to date, it is absolutely fantastic and I thank them for their continued development.

— Reply to this email directly, view it on GitHub https://github.com/DSheirer/sdrtrunk/issues/1656#issuecomment-1762543522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQC3R4VO6CDYJN63UY46S6TX7IAOPANCNFSM6AAAAAA5HH6IME . You are receiving this because you commented.Message ID: @.***>

[louisik1]

Syd-MD:

You described a specific situation that isn't what most people are complaining about, when talking about duplicates on Broadcastify: "upload only one file to Broadcastify with combined listed metadata. Only one file would be available and played in the node, however would display multiple TGID’s for the user to identify that the audio clip was transmitted over the many listed TGID’s. "

That led me to read your original post (which I admit I didn't read initially, so, very-much my-bad, sorry).

There's the very common issue of Broadcastify Calls nodes broadcasting the same audio from multiple feed providers. By the title of your post, it's understandable that people (including me) thought that's what you were talking about.

I don't know if you can change the title of your request. If you can, you might try rewording it to be specific about 'patched talk groups generating multiple uploads to Calls', or something like that. If you can't reword it, I'm going to go so far as to say you should close this one, with all of our noise, and open a new one with a different title.

Best wishes

[ghost]

Absolutely keep Broadcastify separate. All they need to do is remove duplicates, which they shouldn't have allowed. … On Fri, Oct 13, 2023, 11:22 PM Syd-MD @.> wrote: One could say the same about Broadcastify - the only responsibility Broadcastify is required to do is broadcast to a listener the uploaded audio files and display the attached metadata. However this does not dismiss that there is an issue as to the management of duplicate calls. As I have previously stated 'communication between the two may be required to develop a solution.' It may be feasible that another person may be using an app other than SDRTrunk however that too is something the developer of such other app would need to develop for the handling of duplicate calls, if that developer choses to adopt. This feature may be what attracts a contributor to use SDRTrunk (if feature implemented). Considering SDRTrunk has implemented the specific API for uploading files to Broadcastify. This feature would potentially only be for uploading to Broadcastify. Realistically though, it could be used for other systems. This would ultimately be a developer decision. As the audio files are being generated within SDRTrunk, yes they attach the metadata. This is the perfect time to detect duplicate audio files. Instead of uploading multiple files to Broadcastify, upload only one file to Broadcastify with combined listed metadata. Only one file would be available and played in the node, however would display multiple TGID’s for the user to identify that the audio clip was transmitted over the many listed TGID’s. This would then allow the display of this audio clip when a user reviews a specific TGID. From a data management perspective it makes sense that SDRTrunk does this processing locally on the contributors server to spread this load rather than Broadcastify requiring more processing power and the implementation of a potential delay in making such data available to the listeners. Likewise it would save a contributor from uploading more data / files to Broadcastify than needed. I would like to acknowledge the great work that the developers of SDRTrunk have completed to date, it is absolutely fantastic and I thank them for their continued development. — Reply to this email directly, view it on GitHub <#1656 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQC3R4VO6CDYJN63UY46S6TX7IAOPANCNFSM6AAAAAA5HH6IME . You are receiving this because you commented.Message ID: @.>

The duplicate situation on broadcastify isn't as cut and dry as you think though. Broadcastify should utilize an AI system that uses the best audio of the duplicates, or even just allow duplicates to be attributed to a owner and sorted by owner. I imagine they working on something like this, as I told Lindsey about this years ago.

One thing to take note is p25 simulcast systems create many duplicates by nature. I've had another local SDRTRUNK user uploading garbled stuff to CALLS. For whatever reason, and we've all been there, he had crazy digital interference. It was duplicate on CALLS but his was extremely garbled, mine wasn't. Shouldn't broadcastify utilize a AI system that anylizes both duplicates and selects the best one based on audio quality and other factors?

I noticed the broadcastify has recently removed feed owner names from all CALLS platforms, since its a pool system. So they most likely moving in this direction.

AI could be utilized to sort out the best audio file. AI could even be used to merge duplicates to create a better version of both. I think they working on something like this.

[louisik1]

I've had another local SDRTRUNK user uploading garbled stuff to CALLS.

Seattle/King County?