v0.5.0-beta3 Streaming to Broadcastify. Long delays.

[Dan G]

I am converting my feeds over to SDRTrunk.

I am running 1 instance of Broadcastify Call and 3 Broadcastify Feeds.

My problem is with the feeds. I am seeing very long delays from the time the call is uploaded to Broadcastify to the time it finally gets to the player. This seems more a problem with Broadcastify but I'm not sure. When I stream using Radiofeed, or Proscan the delay is only about 30 seconds. Using SDRTrunk delays are running 4-5 minutes behind, sometimes as long as 15 minutes.

Is there anyone that experiences this problem? And is there any clues as to why it is happening?

[Austin Hruskach]

What is your internet upload speed? https://www.speedtest.net/. SDRTrunk might output WAVE files and those can add up in size pretty quick, in addition to 3 audio feeds. Make sure you aren't uploading too much. You can see total network upload in Task Manager.

[Dan G]

Provider upload is 10Mbps and the amount being uploaded is averaging 200 kbps so I have plenty of bandwidth. Best I can tell, SDRTrunk is streaming MP3 at a bitrate of 16kbps

I have already spoke with Lindsay over on Broadcastify but he doesn't seem too interested in looking to see what is happening on his end but, I'm pretty sure the delay issue is caused by the separate uploads coming from SDRTrunk for each call that is received, whereas Broadcastify like to have a steady stream all the time. This works great for Broadcastify calls but not for their traditional feeds.

The interesting observation I see is the busier the feed, the less delay there is. I run one feed that is very active and normally see several calls stacked in the queue. Taking the que into count there is about 30 second delay (which is normal for a Broadcastify stream)

My other two feeds are low traffic volume, sometimes going 20 minutes between calls. It is those feeds that I am getting crazy delays, as long as 45-50 minutes. I know Broadcastify received the call but for some reason they are not processing it in a timely fashion. It is almost like they have a buffer that needs to be filled up before they send it out in their stream. Of course this is all speculation as Lindsay doesn't care much into looking into it. Too bad as SDRTrunk is amazing software that could benefit Broadcastify immensely.  

[Bote Man]

That sounds like a Broadcastify issue that I have noticed on many feeds. It is unlikely that they see it as a problem as the longer the latency, the less heat they get from public safety about streaming their communications.

 

On my rinky-dink icecast server with a small handful of feeds my turnaround time is on the order of 4-10 seconds.

 

 

Bote Man

http://www.botecomm.com/bote/radio/streaming.html

--
You received this message because you are subscribed to the Google Groups "sdrtrunk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sdrtrunk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sdrtrunk/653774b9-c8ed-4b69-ba13-e0341bc6dcb3n%40googlegroups.com.

[CT POLICE LIVE]

I've also noticed more of a delay on my streaming feeds since v0.5.0-Beta 3. But CALLS is getting it all instantly. I know purposely delaying a feed on broadcastify is against the rules. I asked for a slight delay option years ago when BLM was taunting police with my feed through a bullhorn and was told no.

[Austin Hruskach]

Ping the Broadcastify Calls API url, or whatever ip goes to broadcastify.

[Dan G]

I already ping, using node-red (15 second intervals), the three audio servers that I am uploading to. I do that in order to notified of problems with their servers. Have you found benefit as in relation to the delay problem?