Competing feeds? -- same system / same site

[mtindor]

I don' t know if this question has ever been asked (couldn't find it in a search).

I run a Broadcastify Calls ingest feed for Ohio MARCS-IP (Jefferson County) -- Node 87.
Somebody else runs a Broadcastify Calls ingest feed for Ohio MARCS-IP (Jefferson County) -- Node 2544.

It appears that I do not see all calls that my feed sends to RR because oftentimes the "other" provider has uploaded the call first and thus mine is a duplicate and likely rejected.

That means that I can't really just park on my own Node 87 feed and get all of the traffic.

Both feeds are using SDRTrunk (if that matters).

Just wondering if anyone else noticed this. Sure would be nice if I could park on my own Calls Ingest feed and hear absolutely everything that I'm sending (even if some of the audio was actually sent by the other feed provider and those calls that I send were rejected as dupes).

I can put both Node 87 and Node 2544 up in two separate browser windows and compare. And when I'm not seeing a call on my feed that I know SDRTrunk attempted to upload, I can see that particular call on the other person's feed.

Any way around this?

Mike

 

[belvdr]

I don’t have an official answer but can you listen to the system and not the specific node? I’m not near a computer to check.

 

[mtindor]

I don’t have an official answer but can you listen to the system and not the specific node? I’m not near a computer to check.

I don't think that is possible on the Call-Ingest platform, versus the standard feed platform.

 

[AB5ID]

deleted

 

[GTR8000]

I don’t have an official answer but can you listen to the system and not the specific node? I’m not near a computer to check.

I don't think that is possible on the Call-Ingest platform, versus the standard feed platform.

Yes, it's possible...


However not entirely ideal, as you would literally be listening to activity from every node in the state, instead of just isolating Jefferson County. There are a ton of nodes from all over the state with the MARCS-IP system, so good luck with that.

Also to mtindor's point, it would be nice to be able to listen to all activity for just your own node, rather than missing "rejected" calls because of duplication from other nodes carrying the same traffic. Yes, the duplication rejection is nice from a listener standpoint, but from a node provider standpoint, not as ideal.

Obviously the ultimate "solution" would be to run Trunking Recorder to import the SDRTrunk audio, and listen that way. Now you're truly getting all of the activity from your node without BCFY interfering. If monitoring your own node is truly that important to you, that's the way to go.

 

[belvdr]

Yes, it's possible...
View attachment 152574

However not entirely ideal, as you would literally be listening to activity from every node in the state, instead of just isolating Jefferson County. There are a ton of nodes from all over the state with the MARCS-IP system, so good luck with that.

Also to mtindor's point, it would be nice to be able to listen to all activity for just your own node, rather than missing "rejected" calls because of duplication from other nodes carrying the same traffic. Yes, the duplication rejection is nice from a listener standpoint, but from a node provider standpoint, not as ideal.

Obviously the ultimate "solution" would be to run Trunking Recorder to import the SDRTrunk audio, and listen that way. Now you're truly getting all of the activity from your node without BCFY interfering. If monitoring your own node is truly that important to you, that's the way to go.

Sorry I used the incorrect term. I meant site, not system. In this case, can you listen to Jefferson County, not MARCS as a whole?

 

[mtindor]

Sorry I used the incorrect term. I meant site, not system. In this case, can you listen to Jefferson County, not MARCS as a whole?

I honestly knew what you meant. GTR likes to bust my balls though.

 

[GTR8000]

GTR likes to bust my balls though.

Nothing in my post was ball busting, so I'm not sure why you would interpret it as such. The question was asked if a system can be listened to instead of individual nodes, and I provided the answer. Of course the answer is different if the question is whether a site can be listened to (amalgamation of nodes), that's a "no".

 

[norwichfeeder]

I don' t know if this question has ever been asked (couldn't find it in a search).

I run a Broadcastify Calls ingest feed for Ohio MARCS-IP (Jefferson County) -- Node 87.
Somebody else runs a Broadcastify Calls ingest feed for Ohio MARCS-IP (Jefferson County) -- Node 2544.

It appears that I do not see all calls that my feed sends to RR because oftentimes the "other" provider has uploaded the call first and thus mine is a duplicate and likely rejected.

That means that I can't really just park on my own Node 87 feed and get all of the traffic.

Both feeds are using SDRTrunk (if that matters).

Just wondering if anyone else noticed this. Sure would be nice if I could park on my own Calls Ingest feed and hear absolutely everything that I'm sending (even if some of the audio was actually sent by the other feed provider and those calls that I send were rejected as dupes).

I can put both Node 87 and Node 2544 up in two separate browser windows and compare. And when I'm not seeing a call on my feed that I know SDRTrunk attempted to upload, I can see that particular call on the other person's feed.

Any way around this?

Mike

One way.. And this is a recent blessing thanks to the Sdrtrunk developers.. You can always use SdrTrunk v6 and create a OpenMhz account. It's a new built-in feature on sdrtrunk. So you can now feed to both CALLS and OpenMhz at the same time with sdrtrunk. Your Openmhz node is your own and it doesn't seem they have issues with you making backup/duplicate scanner systems. OpenMhz doesn't pool the ingest data like CALLS does.

This can be an issuse on CALLS when another person's CALLS talkgroup gets uploaded and accepted first but its garbled or subpar to yours and yours got rejected as duplicate. When you go back and try to listen/download the call you just heard, but you can only download the other guys garbled CALL. This could probaly be fixed with some kind of AI audio anylzer that checks duplicate for quality and length, instead of first come, first served. I find OpenMhz is a good system in this respect. And a good backup system to CALLS.