ProppFrexx ONAIR User-Forum

We have been having some issues with the MODStream player being stuck on "Trying to connect..." in the "None" state, even though the streaming server is active and a connecting should be possible.

The big issue here is that the MODStream player cannot be closed when this happens. Clicking the "Close" button or sending "MODSTREAM_WATCHER_STOP" does not close the MODStream and ProppFrexx must be restarted in order to reopen the MODStream and attempt to connect again.

Can you please provide the URL you are trying to connect to. And how long have you waited.
This actually sounds like a connection issue with that URL. Normally the connection request will receive a 'timeout' and fails after that time. Here it seems, that you either don't receive a timeout or your timeout takes very long...?

I will provide you with our streaming URLs in a PM.

The bug here is not being able to close the MODStream when this connection process is happening.

Unfortunately I can not reproduce the issue.

Can you explain when it enters the 'None' state? I.e. is this happening initially already (when the MODStream Player popup is displayed first)?
And to what have you set your MODStream settings, i.e.
- Check MODStream sec.
- Start Delay Time sec.
- Stream Timeout sec.
- Duration
(see general settings, section Streaming...)

I have been able to reproduce it just now consistently multiple times.

Steps for reproduction:

1. Stream from one ProppFrexx instance to an IceCast server over OPUS.
2. Pause the playlist on this instance to stream silence.
3. Start the MODStream watcher on another instance of ProppFrexx using the following command: 4. The MODStream player will show "None" and "Trying To Connect To URL..." and clicking the "Close" button or sending "MODSTREAM_WATCHER_STOP" will have no effect and the MODStream player will remain open.

Once you press play on the streaming ProppFrexx instance the MODStream player will instantly close. It is kinda like the close action is only executed when the MODStream status != "None"

Something which also may be important to reproduce:

* MODStream Start Delay Time: 0 sec
* MODStream Timeout: 20 sec

Ahh, now I see your issue. And yes, I can reproduce this as well (even it only happens when streaming to/from an ICEcast stream using OPUS).
Unfortunately, it seems, that this is actually a known OPUS issue, as OPUS encoding handles 'silent' input quite differently.

However, I am in contact with the developer of the audio engine to find a workaround...

So if possible, try using any other format, e.g. MP3, OGG, FLAC or AAC ... those formats anyhow deliver better quality or streaming music.

A new v4.3.4.1 is out, which fixes the issue with 'silent' OPUS streams.
THX for finding this rare edge case!