search

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:
GNU General Public License v3.0
1.58k stars 255 forks source link

OpenMHz went down today and SDRTrunk wouldn't start after that.. #1948

Closed ghost closed 1 month ago

ghost commented 2 months ago

sdrtrunk Version any with Openmhz feature

Describe the bug OPENMhz went down today for whatever reason and it took my other broadcastify feeds with it. Sdrtrunk wouldn't even restart. When restarting my it kept failing on "Connecting to OpenMhz feeds.."

I had to manually edit my playlist XML file with a XML editor, and change the Openmhz server startup to false.

Desktop (optional - complete the following information): -Linux Mint

Additional context Need some kind of option to retry openmhz server 3 times at start up and then continue without it, if it fails.

ghost commented 2 months ago

Happened again today. I have 5 Openmhz and 8 broadcastify streams. When Openmhz goes down it forces sdrtrunk to disconnect my other broadcastify streams and no other streams will restart until either openmhz is responsive, or I disable my openmhz streams.

I can see sdrtrunk tries to reconnect but can't get past that many down openmhz servers in time to reconnect to broadcastify servers. It gets stuck in a loop.

So a simple tweak may be needed in the reconnect timing of streams so it doesn't take down everything if openmhz goes down.

DSheirer commented 2 months ago

Can you please post the application log from when this happens so I can see if there are any logged errors.

ghost commented 2 months ago

sdrtrunk_app.log

ghost commented 2 months ago

Had to shut down my Openmhz streams until this can be fixed. It keeps happening. Some kind of skew issues apparently. If Openmhz website goes down for even one second it takes all my other feeds with it. Not sure if Openmhz is being DDOSed or just overwhelmed. Either way it shouldn't be tied at the hip to my other streams. Thanks for taking a look at this.

tadscottsmith commented 2 months ago

Are you on at least v0.6.1-beta-1? There were some OpenMHz reconnection issues addressed in that version.

ghost commented 2 months ago

Are you on at least v0.6.1-beta-1? There were some OpenMHz reconnection issues addressed in that version.

Yes, on a recent nightly. Doesn't matter which version. Happen on all. Just happened again today. Openmhz goes down and my other feeds won't reconnect until I disable Openmhz. The log I provided above seems to explain whats happening. Thanks

DSheirer commented 1 month ago

OpenMHz is configured to take up to 20 seconds trying to connect before it fails with a timeout. This was happening on the main application thread and may have been what was causing the perception that the application was failing to start.

I've updated the code to spin off all stream configuration startups into their own threaded startup so that they don't cause any delay in the main application start sequence.

I'm not sure what was causing the Broadcastify Calls streaming delays with the call time skew. From the posted log file, it appears that OpenMHz was at least partially responding from the nginx gateway timeout responses.