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

eddr

Member
With reference to https://www.djsoft.net/smf/index.php/topic,4651.msg23413.html#msg23413

The problem here is that we need RadioBOSS to keep playing/retrying the stream and not move on to the next track until told to do so, or our live DJs feed (from a shoutcast server) will be interrupted when there is a brief disconnect from them OR (more importantly) when the DJ's change over.

Here's how things are working at the moment:
We use Winamp to play a 'auto' playlist which is just a playlist of MP3's on shuffle. DJ's connect into the SHOUTcast server where Winamp is running and we have a program watching the SHOUTcast server so that when a DJ connects, Winamp switches from the 'auto' playlist to a 'live' playlist which is pointed to the local SHOUTcast server (http://127.0.0.1:8000). Because Winamp is on repeat mode, even if the DJ disconnects briefly because of a network problem, Winamp will keep trying to reconnect as it is the only item in the playlist - this works great. When the next DJ is due on air, the current DJ disconnects from the SHOUTcast server which causes Winamp to begin reconnecting (as there is no source, the SHOUTcast server does not allow the connection yet). The next DJ then connects, and so Winamp is then able to connect and playback resumes.

Here's how we would like things to work with RadioBOSS:
Schedules are setup to generate playlists and added to the queue according on time of day, which day it is etc. This cannot interrupt a live DJ if they are playing (This could be at any time) and so the event is setup to add tracks to the queue and remove existing. When a DJ connects to SHOUTcast, the external program triggers a batch file which uses RadioBOSS API and adds the local shoutcast server to the queue, plays it and then deletes it. When the DJ disconnects, after 10 seconds the external program runs another batch file which tells RadioBOSS to go on to the next track - it's now back in 'auto' mode.

Our current method is very basic and it works - but we now want to create more advanced playlists and use the features of RadioBOSS (this issue did not become apparent in testing using the trial). It's a shock to me that such a basic scenario doesn't work well in RadioBOSS as it is so advanced!  ;D

Can anyone think of a method which we can use to get round this problem? Ideally, just having a parameter added to a stream in the playlist to say "play indefinitely" or "retry indefinitely" would be great - the network retries even when specifying a duration does not help here.

Thanks in advance
 
What about enabling the Repeat Track feature when you play an internet stream? This will make it retry indefinitely.
 
This was looking very promising! The track plays until we tell it not to - so to test further I created a playlist, made a generate playlist event and ran it manually - for some reason the 'repeat track' does not take effect and it moves on to the playlist (the first track has been queued as it has (1) next to it).

Is this supposed to happen?

To reproduce:

1) Add a stream to the playlist (Local shoutcast server for example)
2) Enable Repeat Track
3) Play the stream
4) Run event to generate playlist - the tracks get inserted
5) Shutdown the shoutcast server - you now see the track move on and not repeat

So nearly there - I think, it would be perfect if this didn't happen. There's also no need to delete the track from the playlist as we planned to before if it can work this way.
 
Yes, it's supposed to happen: a new event (generate playlist) started, and it has priority over the Repeat Track.

From what I see, you need a way to switch between DJs and RadioBOSS without disconnecting listeners. There are much easier (and more reliable) ways to do it :) Your setup is complicated, because you try to make RadioBOSS do the work that should be done by the server. And even if it worked as you desire, there will still be 1-2 (or more) second gaps when DJs are switched.

Please see how we handle it for our stream hosting: https://www.radioboss.fm/support/using-shoutcast-dj-accounts/ - the switch between AutoDJ and DJ's (or between different DJs) is seamless and with no gaps. Every DJ has own password for broadcasting. For your situation, you can have RadioBOSS playing as one of the low-priority DJs and have human DJs with higher priority: when they connect, listeners will hear live DJ, when they disconnect, they will hear RadioBOSS. And the transition is automatic and gapless.

If you want to setup everything on your own server, then I'd advice using Icecast server and set up fallback mounts:

/stream -> /live -> /radioboss

Your DJs broadcast to /live
RadioBOSS broadcasts to /radioboss.
Listeners listen to /stream.

Here's how it works: listeners always connect to /stream. If /live is available, they hear /live stream, if not, they hear what's playing on /radioboss. If /live becomes available, they are switched automatically to /live, and when /live is disconnected, they are back at /radioboss. All this is automatic and with no gaps.
 
Hello,

Thanks for coming back to me on this. Is there a way to toggle this behaviour with the priority?

We don't want to change the way our setup works and need to include our 'middle' server for various reasons - but mainly because audio processing is happening on this server, and auto dj + mount points on the server side, there is no audio processing capabilities (we run everything through stereo tool). So, for this reason and others - we need to keep it this way :(

Thanks in advance - I really hope there is a solution
 
The change you ask for is too situation-specific, and we generally avoid doing changes like this, I'm sorry for that. This is for greater good - prevent software bloat :)

The Icecast way I proposed does not require using our service (or any intermediate server) - you can just change your internal Shoutcast server to Icecast and use its fallback capabilities.

For the StereoTool processing - do you use it in RadioBOSS to process the stream?

If you still like to stick with the way you like, I think there may be a solution, as you utilize batch files and API, you can send a command to RadioBOSS to disable and enable the scheduler when DJ connects or disconnects:

/?action=schedule&type=state&set=off (use &set=on to enable it)

When scheduler is disabled with the command above, it will be disabled completely, even "scheduler on" events will not work.

So with scheduler disabled, it will have only stream address in the playlist, and with Repeat Track (or Repeat Playlist) enabled, it will continue playing it (or trying to play) no matter what.

And another note. You can do something to prevent Shoutcast disconencts, first thing, instruct Shoutcast to keep listeners connected even if source (DJ) is disconnected - there's an option for it, I don't remember how it's called, though.
 
Thanks for taking time to think about this and reply

I understand about it being a very specific request, it just suprises me that with such a great but of software something which is currently so simple using our current method can't be achieved in the same way  :-[ Is this not a simple case of putting a check in to say "if repeat track enabled do nothing" ?  ;D

Changing to icecast won't help: the middle server does the audio processing via a virtual soundcard, so currently winamps output (whether it's playing from the auto playlist or live stream (local shoutcast)) and then we use butt software to stream the output of the virtual soundcard to the main streaming server. So the plan was to do the same in radioboss - main soundcard to the virtual input and stream using the output (processed) card using radioboss broadcasting function.

Turning the scheduler off would prevent the playlist from being populated whilst the live DJ is paying and we need to do this so that when they finish/disconnect and the live stream track is removed, it will begin playing what we want it to according to our schedule.

I would be hesitant to change the setting on the shoutcast server and actually investigating this by default it is already on - autodumpusers=0. Checked out the forums and even with this setting disabled the connections will still be dropped (http://forums.winamp.com/showthread.php?t=372261).

Any other ideas?
 
eddr said:
I understand about it being a very specific request, it just suprises me that with such a great but of software something which is currently so simple using our current method can't be achieved in the same way  :-[ Is this not a simple case of putting a check in to say "if repeat track enabled do nothing" ?  ;D
There's no such feature because there's no real use case for it -except for yours, but it appears to be an exception ;)
Putting a new "check" is a bad solution, because it leads to software bloat. We have plenty of requests for adding new configuration options (literally hundreds of them!). But having a small check mark for every minor configuration option... the software will become unusable. That's why every addition has to be justified.

eddr said:
I would be hesitant to change the setting on the shoutcast server and actually investigating this by default it is already on - autodumpusers=0. Checked out the forums and even with this setting disabled the connections will still be dropped (http://forums.winamp.com/showthread.php?t=372261).

Any other ideas?
Yes - this option will work if you also have backup file configured (note that it should have exactly the same format as your stream, or you can simply use silent file, in which case format should not matter).
Code:
 BackupFile can specify a mp3 file that will be streamed to listeners over
; and over again when the source stream disconnects. AutoDumpUsers must be
; 0 to use this feature. When the source stream reconnects, the listeners
; are rejoined into the live broadcast.
; Note that the backup file MUST be the same samplerate/channels as the
; live stream in order for this to work properly. Although bitrate CAN
; vary, you can use '%d' to specify the bitrate in the filename
; (i.e. C:\backup%d.mp3 would be C:\backup32.mp3 if you are casting at 32kbps).
; The default is no BackupFile
; BackupFile=C:\intro%d.mp3

BackupFile=/home/shoutcast/sc_trans_040/mp3/1.mp3

eddr said:
Changing to icecast won't help: the middle server does the audio processing via a virtual soundcard, so currently winamps output (whether it's playing from the auto playlist or live stream (local shoutcast)) and then we use butt software to stream the output of the virtual soundcard to the main streaming server. So the plan was to do the same in radioboss - main soundcard to the virtual input and stream using the output (processed) card using radioboss broadcasting function.
Well, your setup is really complex as it involves too many components in the chain. I advice Icecast way. You can also add processing to it by utilizing one more mount point. For instance, install another RadioBOSS that will use /stream mount point as its source, do the processing, and broadcast to another mount point on Icecast or a different server. Listeners will connect to that final mount (or server).
 
I understand about justification - I work in IT for a software company and work in support, communicating between the customers + developers and it can be difficult to describe use cases for things customers request. I am wondering what else I can do to justify this request :( - In the documentation there are no caveats for the 'repeat track' function (it doesn't say scheduled tracks have higher priority for example). In my mind as a customer, I would say that the repeat track function is not working properly as the track is not being repeated, the repeat is interrupted.

We don't want to really use a backupfile as we don't want the shoutcast server to accept connections if no source is connected when DJ's are not playing or changing over.

And we don't really want to change to Icecast for various reasons but one of which would involve talking to all our DJ's and having them amend their settings, this can be tricky  :-\

Can you think of any other way?

I did think about the fact you can have multiple active playlists - if it was possible to control which one was active by the API, we could have a 'Live' playlist with only the stream in it and the 'normal' auto playlist. Then when a DJ connects, playback is stopped and the Live playlist becomes active and is then played. For this to work, the API would have to support switching the active playlist with reference to them. It would be useful to be able to list the playlists via the API and control them (switch active, delete, add, clear etc). Thoughts on this?
 
eddr said:
In the documentation there are no caveats for the 'repeat track' function (it doesn't say scheduled tracks have higher priority for example). In my mind as a customer, I would say that the repeat track function is not working properly as the track is not being repeated, the repeat is interrupted.
And if Repeat Track has priority, then you could say that scheduler doesn't work, because event didn't start :) When priorities are concerned, there are no right and wrong ways, there are only different ways.

eddr said:
Can you think of any other way?
Perhaps, adding a config option that you can set in the text file, to make it retry the failed stream indefinitely. But this is way too situation specific, so I can't promise anything.

eddr said:
I did think about the fact you can have multiple active playlists - if it was possible to control which one was active by the API, we could have a 'Live' playlist with only the stream in it and the 'normal' auto playlist. Then when a DJ connects, playback is stopped and the Live playlist becomes active and is then played. For this to work, the API would have to support switching the active playlist with reference to them. It would be useful to be able to list the playlists via the API and control them (switch active, delete, add, clear etc). Thoughts on this?
This will not work, because scheduler always works in the active playlist, so when a DJ connects, scheduler will interfere.

Why shoutcast backup solution is not acceptable? It seems a way to go for me (it also reduces the gap you have when DJs are switching or recovering from network failure). From your description, it appears to be some sort of internal server, and you have listeners connecting to some other server.
 
djsoft said:
And if Repeat Track has priority, then you could say that scheduler doesn't work, because event didn't start :) When priorities are concerned, there are no right and wrong ways, there are only different ways.

Hmm yes good point :)

djsoft said:
Perhaps, adding a config option that you can set in the text file, to make it retry the failed stream indefinitely. But this is way too situation specific, so I can't promise anything.
Going back to this, I think this will be the only way - as really, the setting to make it keep retrying is not working at the moment but ONLY if the scheduled tracks have been added to the playlist. If scheduled tracks are not there, it does keep retrying even if other (non scheduled) tracks exist in the playlist.

djsoft said:
This will not work, because scheduler always works in the active playlist, so when a DJ connects, scheduler will interfere.
I know it's a 'big' request but maybe the scheduler should allow: targeting playlist? So you can specify which playlist to target or active playlist

djsoft said:
Why shoutcast backup solution is not acceptable? It seems a way to go for me (it also reduces the gap you have when DJs are switching or recovering from network failure). From your description, it appears to be some sort of internal server, and you have listeners connecting to some other server.
I tried this - it won't work for us as DJ's encode using AAC+ and backupfile (and intro files) must be MP3 - I have not tried an mp3 with the same bitrate but surely a format change (from mp3 -> AAC) will cause a further delay as shoutcast has to restart the stream (We see this if DJ's have the wrong bitrate set).
 
I thought more about it, and I see another option.

You can have two RadioBOSS instances installed. One is to play shoutcast stream with Repeat option enabled. second one is AutoDJ.

Use batch files with API calls to switch between instances - set one instance volume to 0, and another to 100.

Both instances play to a virtual sound card, and RadioCaster is used to send the stream from that virtual sound card to the server.


Still, the main problem here is that your way to switch between DJs is too complex and not typical... That's why it's not really supported in RadioBOSS. This task (switching sources) is better be solved on server side - the Icecast option I proposed earlier. It's easier to set up and you get gapless transition and it's overall more reliable. If you want to stay with Shoutcast protocol, you can use Liquidsoap instead of Icecast, but it's more difficult to get started with Liquidsoap.
 
This option (2 RadioBOSS running) is a bit cumbersome and if possible, we would like to not run 2 instances of RadioBOSS - this would be a very much last resort option for us!

I don't think I understand the Icecast option as we would need all processing (auto + live) to go through the virtual sound card then be sent to the external (main) shoutcast server. RadioBOSS has to be told to listen to the server the DJ's connect into when they are live, and told to switch back to auto after they disconnect (there is a 10 second delay before it switches).

For us this setup isn't complicated at all - it's quite simple and has always worked well  ;D We need to keep the setup this way because the 'switcher' program performs other actions too (it gives us greater control as to when DJ's can connect and other features).

So - the audio stream sent to the main server has to be processed by the middle server always.
 
RadioBOSS doesn't require much resources, so you can safely run two of them. You'll also separate the tasks they are doing - one handles DJ connections and another runs the stream.

We'll consider adding config option to make it reconnect indefinitely in RadioBOSS 5.6 but no promises here.

Actually, thanks to this discussion, we'll think of adding another, more important feature: allow remote DJs connect to RadioBOSS directly.
 
Well i would like to consider it a workaround until the option is implemented in 5.6?  ;D This would make us VERY happy.

With regards to the new feature, would be interested to know more and if you need any testers etc when you start developing it.

Thanks!
 
eddr said:
With regards to the new feature, would be interested to know more and if you need any testers etc when you start developing it.
Public beta test will start once beta version is ready. If you have any feature suggestions, feel free to post them in the Feature Request forum https://www.djsoft.net/smf/index.php/board,2.0.html :)
 
Hello,

I am trying to set this workaround up but wanted to confirm something. You say that both instances of RadioBOSS should point to a virtual sound card but then on the broadcasting options, you can only select 'Audiomix' or one of the inouts. If I select 'Audiomix' is this still going to play the audio from the card from the second instance, even though the first instance isn't playing? Or do I need to select Input 1 and make Input 1 the virtual card?

Thanks!
 
You need to use Input 1 and configure the input (on Inputs tab) to use the virtual sound card.
 
Ok thanks for confirming, have it setup like this and it seems to be working ok. This is another reason why a vu metre should be available for other inputs as we are only seeing the metred level before it goes through stereotool and not the output of the signal after it's processed.

Another drawback of using two instances is that the silence detector can only be configured on one, and the input of the silence detector cannot be configured so would not tell us when there is silence on the live dj instance.

It's not an ideal situation but it works, and we will just have to wait to see if the reconnect issue gets fixed/implemented  ;D
 
eddr said:
Ok thanks for confirming, have it setup like this and it seems to be working ok. This is another reason why a vu metre should be available for other inputs as we are only seeing the metred level before it goes through stereotool and not the output of the signal after it's processed.
StereoTool has its own VU meter for output signal level. You can also install RadioCaster and use it to monitor the sound level of certain input (trial version will be enough for that).

eddr said:
Another drawback of using two instances is that the silence detector can only be configured on one, and the input of the silence detector cannot be configured so would not tell us when there is silence on the live dj instance.
If you insert line input to the playlist and play it, then silence detector will work with it - when input becomes silent, it will perform some action.

eddr said:
It's not an ideal situation but it works, and we will just have to wait to see if the reconnect issue gets fixed/implemented  ;D
I still have doubt if "constant reconnect" will provide any benefit - RadioBOSS is almost 15 years old and it never was requested... Also it may break some existing setups that rely on the current behavior, so changing it will likely cause backward compatibility issues.
Also, switching between DJs/AutoDJ your way is not optimal, the major drawback is 2-3 seconds of silence when the switch occurs - to me, it's totally unacceptable because of that... Given that there are lots of other and better options (I mentioned them earlier), it's unlikely that network stream reconnect will be changed any time soon, I'm sorry.
 
Back
Top