Require network stream to keep retrying until told to stop/next trac- here's why

Hello,

Thanks for your reply. Yep StereoTool has its own VU meter however it is really resource intensive when the GUI for StereoTool is open, so we prefer not to open it at all. With regards to RadioCaster - we would prefer not to install yet another application :(

Insertion of the line input to the playlist would not be ideal really - I see how it could work, but would prefer not to do it this way if possible. The volume of this radio boss instance would be 0% at this stage anyway - would the silence detector even work like this?

A constant reconnect would be VERY beneficial to us. I realise it may have never been requested before, but as you probably know, the more people who use your software the more defects/bugs/enhancements will evolve due to all the different ways in which people use the software. Obviously testing can only go so far and you can only assume so much, but cannot test each and every path a user of the software will take (and in what order!).

With regards to the backward compatibility issue - you stated previously if this was to be implemented it could be a config option in a text file? As with any change which could effect backwards compat. it should by default be 'off' (or the old behaviour) until the user decides to turn it on - this would prevent this?

The switchover of 2 - 3 seconds is not always the case - sometimes it is instant which is actually too much (there is no 'gap'). A small gap between the auto DJ + live DJ is ok to us and our listeners.

I know you have provided other options - but for our situation and setup of how our station + remote DJ's work, it doesn't suit us.

Thanks - appreciate your time on this :)
 
eddr said:
With regards to RadioCaster - we would prefer not to install yet another application :(
RadioCaster is well optimized, you can safely use it for level monitoring purposes without any impact on PC performance - with no encoders set up, it will use around 0% CPU :)

eddr said:
Insertion of the line input to the playlist would not be ideal really - I see how it could work, but would prefer not to do it this way if possible. The volume of this radio boss instance would be 0% at this stage anyway - would the silence detector even work like this?
Yes, silence detector does not take into account playback volume, it checks the stream before that.

eddr said:
A constant reconnect would be VERY beneficial to us. I realise it may have never been requested before, but as you probably know, the more people who use your software the more defects/bugs/enhancements will evolve due to all the different ways in which people use the software. Obviously testing can only go so far and you can only assume so much, but cannot test each and every path a user of the software will take (and in what order!).
That's correct, but we only support solutions that provide benefits over what's currently possible. Your way to switch between DJs, I'm afraid, is not such a case, and I doubt that anyone else will be using it this way. This means that the feature you request is too situation specific (=used by only one user) and we generally avoid adding such features. It's still under consideration, and there's a chance it'll be added in RB 5.6. I'd suggest you to review other options I mentioned earlier.
 
Hello,

Thanks for your responses.

So the silence detector actually does detection on the outgoing stream not the audio mix? Interesting 😁

With regards to the other options suggested, your right and our setup may be unique - but it works really well for us and we wouldnt want to change it. The main reasons being our 'auto dj' is processed through stereotool and we can control switching between auto and love djs with more control this way. For now, we are running two instances of stereotool and it's ok - but we have a problem. You suggested when switching, we put volume down on auto and volume up on live (and vice versa when switching back). What we actually have ended up doing is stopping playback on auto and playing on live, then when switching back we stop live and do 'next' on auto so it starts playing the next track. This works ok but when we have schedules setup to generate playlist on the auto instance, it starts playing!!

Is there anyway to stop it playing automatically on the generate playlist command if it's stopped?

By the way, the reason we have gone with stop & play rather than volume down & volume up is because it sounds better as the track starts rather than just switching into a track halfway through - another reason we want it this way and not using mountpoints for switching.
 
eddr said:
Is there anyway to stop it playing automatically on the generate playlist command if it's stopped?
You can disable the scheduler completely using the API. Or in addition to stopping the playlist, also set volume to zero, so even if it starts playing, it will not matter.
 
The problem with disabling the scheduler is we need it to be filling the playlist in the background even when a live DJ is on - so would need to be left enabled.

I thought about setting the volume level to zero as a workaround, and then setting it back to 100 when we switch back from live dj -> auto but I think if doing this, the listeners may hear a track fading out as it moves on to the next one (if it was already playing). Any recommendation on this?

Thanks
 
Switching the volume is a good enough solution (and I can't think of any other easy solution). If you're OK for listeners to hear the several seconds of silence, then I think if they hear songs fading, it's not a big deal :)
 
We want the tracks to fade, but what i meant was if there's a song playing on the auto instance then they may hear that stopping then playing the next. I've got round this for now by stopping auto then waiting a second then playing the next tune. It seems to work OK - not ideal still with the two instances, but ok until hopefully one day the retry on steam can be indefinate.
 
When switching between the instances using the setvol command, you can change the volume gradually e.g setvol 0 1000 - change volume to zero during over a 1000ms (1 second) period.
 
eddr said:
Well i would like to consider it a workaround until the option is implemented in 5.6?  ;D This would make us VERY happy.
Well, it turns out that you don't have to wait for 5.6. The config option you ask for already exists :) It was not documented anywhere and I completely forgot about it. I'm sorry about that.

To use it, please do the following:
1. Start RadioBOSS
2. In the menu click Settings->Open Settings Folder
3. Close RadioBOSS - this is important as RadioBOSS saves its settings when closed and it will overwrite your manual changes
4. In the settings folder, open the player.ini file using Notepad
5. Find the following lines
  StreamRestartAttempts = 2
  StreamRestartTimeoutMS = 2500

StreamRestartAttempts controls how many attempts to connect to the stream does it make before giving up. Set it to a million or so to make it effectively unlimited.

StreamRestartTimeoutMS sets the interval between the attempts, in milliseconds (1 second = 1000 milliseconds).

6. After edits are made, save the file.
 
Hello!

Excellent! This is great news, and seems to be doing exactly what we need - very happy that you remembered this setting  ;D

I'll test this thoroughly in the lab  8)
 
Hello,

This has been working ok for us 90% of the time, however I have noticed that there are 2 different connections coming from RadioBOSS - one with RadioBOSS as the useragent and the other one is NSPlayer.

Can you tell me more about why there is two? Are both connections capable of playing audio out into radioboss? Is there a way to stop two connections?

I have a suspicion that we are hearing something stuck in a buffer somewhere when radioboss losses connection (as DJs are changing over). The shoutcast server is set to drop connections when no source is connected so trying to track down how this (sometimes) happens.

Thanks!
 
eddr said:
I have noticed that there are 2 different connections coming from RadioBOSS - one with RadioBOSS as the useragent and the other one is NSPlayer.
RadioBOSS can sometimes (depending on stream format) utilize the OS media foundation codecs, and this can in turn lead to NSPlayer instances, theoretically. We did not test this so I'm not sure... What format does the stream have?

eddr said:
I have a suspicion that we are hearing something stuck in a buffer somewhere when radioboss losses connection
Yes, it can happen. Playback and stream connect/disconnect are handled separately, so sometimes you can hear buffered audio. This is because stream is constantly connected and disconnected.

If you need seamless transitions then I suggest going the ways I described earlier in this thread (using Icecast fallback mounts, or use Liquidsoap to handle DJ connections).
 
Hello,

Thanks for coming back to me on this. The stream was mp3 then the next DJ connected with AAC (See the log cuts below from our auto switcher which controls radio boss when they connect). I have never seen an instance whereby the NSPlayer ends up playing our stream, it is always RadioBOSS. Anyway to disable the second one?

Here's the log from the SHOUTCast server showing RadioBOSS's connections:

Code:
2017-07-21 18:07:56	INFO	[SRC X.X.X.X sid=1] SHOUTcast 1 source disconnected.
2017-07-21 18:07:58	ERROR	[DST 127.0.0.1 sid=1] SHOUTcast 1 client connection rejected. Stream not available as there is no source connected. Agent: `RadioBOSS'
2017-07-21 18:07:58	ERROR	[DST 127.0.0.1 sid=1] SHOUTcast 1 client connection rejected. Stream not available as there is no source connected. Agent: `NSPlayer/12.0.10011.16384 WMFSDK/12.0'
2017-07-21 18:07:58	ERROR	[DST 127.0.0.1 sid=1] SHOUTcast 1 client connection rejected. Stream not available as there is no source connected. Agent: `RadioBOSS'
2017-07-21 18:07:58	ERROR	[DST 127.0.0.1 sid=1] SHOUTcast 1 client connection rejected. Stream not available as there is no source connected. Agent: `NSPlayer/12.0.10011.16384 WMFSDK/12.0'
2017-07-21 18:07:59	INFO	[SRC X.X.X.X sid=1] SHOUTcast 1 source connection starting.

It's almost as if it tries twice or tries once with each?

I found out that last week a new situation occurred where RadioBOSS was playing the stream after it was added to the playlist, and the DJ was having connection issues - during these issues he was disconnecting and reconnecting a few times and RadioBOSS somehow got mixed up with what it was playing - the 'Now Playing' in RadioBOSS showed a track which was in the playlist but the playlist showed the stream playing and it was playing a MP3 not the stream (So now playing was correct). Can you check this out?

I think RadioBOSS is definitely getting mixed up and continues to try and connect even when it moves on to the next track and this starts playing, so it tries to continue connecting in the background (I can show logs of this happening if required).

Log from auto switcher:
Code:
[SIZE=11px]2017-07-21 15:59:31,739 INFO  ? Title: platinum g Bitrate: 320 Content: audio/mpeg
2017-07-21 15:59:40,846 INFO  ? Switching to LIVE (Auto switch)
2017-07-21 15:59:40,846 INFO  ? RUN LIVE!
2017-07-21 15:59:40,846 INFO  ? Starting C:\live.bat
2017-07-21 18:07:09,677 INFO  ? Source disconnected
2017-07-21 18:07:10,983 INFO  ? Source connected
2017-07-21 18:07:10,983 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp
2017-07-21 18:07:54,113 INFO  ? Source disconnected
2017-07-21 18:07:55,616 INFO  ? Source connected
2017-07-21 18:07:55,616 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp
2017-07-21 18:07:56,918 INFO  ? Source disconnected
2017-07-21 18:07:59,226 INFO  ? Source connected
2017-07-21 18:07:59,226 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp
2017-07-21 18:08:03,039 INFO  ? Source disconnected
2017-07-21 18:08:07,152 INFO  ? Source connected
2017-07-21 18:08:07,152 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp
2017-07-21 18:08:09,962 INFO  ? Source disconnected
2017-07-21 18:08:11,565 INFO  ? Source connected
2017-07-21 18:08:11,565 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp
2017-07-21 18:08:13,269 INFO  ? Source disconnected
2017-07-21 18:08:13,871 INFO  ? Source connected
2017-07-21 18:08:13,871 INFO  ? Title: JD Sparxx Bitrate: 128 Content: audio/aacp[/SIZE]

Thanks!
 
eddr said:
Thanks for coming back to me on this. The stream was mp3 then the next DJ connected with AAC (See the log cuts below from our auto switcher which controls radio boss when they connect). I have never seen an instance whereby the NSPlayer ends up playing our stream, it is always RadioBOSS. Anyway to disable the second one?
If the NSPlayer doesn't cause any problems then I'd suggest to simply ignore it (I'm also not sure if it comes from RadioBOSS or it's something else. Tests show that RadioBOSS registers as one listener on both Icecast and Shoutcast servers, so I'm sure there's no double-connection issue.

eddr said:
I think RadioBOSS is definitely getting mixed up and continues to try and connect even when it moves on to the next track and this starts playing, so it tries to continue connecting in the background (I can show logs of this happening if required).
If there are pending network requests,they may continue to run in the background when RadioBOSS already moved to the next track.
 
Did you test connecting when the shoutcast server won't accept connections? You will see it then. What happens if just by chance, the first connection doesn't work but then the NSPlayer connection does? What happens in this situation?

Hmm so it does continue to try and connect even when playlist has moved on - can a check be made to stop the thread to prevent this happening perhaps?

Also any thoughts on the issue we had with playlist and now paying?
 
eddr said:
Did you test connecting when the shoutcast server won't accept connections? You will see it then. What happens if just by chance, the first connection doesn't work but then the NSPlayer connection does? What happens in this situation?
NSPlayer will not work either as server does no accept the connection. Even if it does, e.g. server starts to accept connections before the attempts are made, nothing bad will happen - just stream will be processed by the OS codec (WMF). The end result will be the same.

eddr said:
Hmm so it does continue to try and connect even when playlist has moved on - can a check be made to stop the thread to prevent this happening perhaps?
It doesn't, but there may be some connection attempts started and that were not yet terminated - they have to finish. We'll make more tests about it to see if there's some bug that prevents it to stop connection attempts.

eddr said:
Also any thoughts on the issue we had with playlist and now paying?
I'm not sure yet. Could be related to the issue when it does not abandon connection attempts.
 
Hello,

Just checking in to see if you have made any progress on checking this?

Also the playlist issue happened again recently :(

Thanks
Edd

 
eddr said:
Just checking in to see if you have made any progress on checking this?
Not really, but it's in the queue to be looked at for the future updates.
 
Hello,

Sorry to raise this thread from the dead again - but our station has been having issues with the stream retries recently, but it has mostly been ok....

Usually, we get the 'Stream connection lost/unstable connection' error when our DJ's disconnect from the shoutcast server and the next dj then connects - due to setting the  StreamRestartAttempts = 1000000
  StreamRestartTimeoutMS = 500 this normally results in it retrying and not causing a problem.

However recently we have noticed sometimes the error is 'Unable to play! Error code 40 (network timeout)' and when this happens, RadioBOSS moves on to the next track! Our DJ is then connected but not being listened to :(

Can you tell me how I can prevent RadioBOSS moving on to the next track when Error 40 happens?
 

Attachments

  • screenshot.jpg
    screenshot.jpg
    212.2 KB · Views: 408
eddr said:
Can you tell me how I can prevent RadioBOSS moving on to the next track when Error 40 happens?
There's no option to prevent this from happening. We'll see of this behavior can be changed in the RadioBOSS 5.7.
 
Back
Top