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

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.

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]

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

sdrtrunk_app.log

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]

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

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]

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.