I am new to Centova (previously was on Live365 for 8 years). I have a new station up and running and have been sorting out how our live DJs will connect. But first here is our setup:

Main stream is run live through SAM Broadcaster 24/7 from my pc at home. We have about 15 DJs from around the world who will connect and do their shows. No autoDJ will be used.

Ideally I would like for my pc to be picked up by out Shoutcast server by default, but when any other source connects, the new source will take priority and the main stream will only connect when there are no other streams fighting it.

I'm new to mount points as well and don't quite understand them yet. We did some live tests a week ago and we noticed that when a DJ connects their source it fights with my SAM for control and my SAM ends up kicking them off and taking over after a couple seconds.

I have worked around this by setting up port forwarding to allow RDP externally on my radio pc and simply instructing all our DJs to remote to my SAM pc and stop SAM before their shows.

Surely there has to be a way to allow the DJs to auto connect and for SAM to sit as a "fallback" source.

Can anyone help?

You can do this with Icecast by setting up multiple mountpoints as fallback and directing your listeners to the default /stream mountpoint.

You can do this with Icecast by setting up multiple mountpoints as fallback and directing your listeners to the default /stream mountpoint.

But we cannot do this with ShoutCast V2?

I do not support Shoutcast V2 on our system so I do not know.

You can do this with Icecast by setting up multiple mountpoints as fallback and directing your listeners to the default /stream mountpoint.

But we cannot do this with ShoutCast V2?

No, I'm afraid Shoutcast v2 doesn't support fallback mount-points unfortunately.

EDIT:

The only way to do something similar would be to use autoDJ instead of your PC for the main programming.

the best option is to use some form of autodj. but there is the 'backupurl' and 'streambackupurl' options (present since v2.2) which allows the DNAS to pull from an url if the source disconnects (i.e. it's basically acting as a stream relay when the original stream source disconnects).

there's also the 'backupfile' and 'streambackupfile' options so a local file can be used if all else fails (though the most recent v2.4x DNAS should be used to ensure the stream will keep working in that case unlike with older v2.x and v1.x DNAS - for v1.x it just dumps the file as-is which most web players cannot cope with).

however I don't remember if I ever changed it so it'd use that if there was no source when the DNAS started or if it's only used when you've first had a direct source (or a main relay connection) active and that then drops.

As a workaround I am trying to script the entire process, although the sheer amount of scripts, and trigger times makes me pull my hair out.

Currently I have 4 PAL scripts in SAM for station ID insertions, promos, etc. one for x:00, x:15, x:30, x:45, so every 15 minutes. I have added a condition into each script:

WHILE NOT FileExists ('stop.txt') DO

Then basically if the file stop.txt exists at the root of C:\ then it stops the PAL, if the stop.txt does not exists it continues as normal.

I set up scheduled tasks in windows to create a blank stop.txt at C:\ about 10 minutes before the start time of each of my live DJ shows, so that when the scripts execute during the show it sees the stop file and turns off, preventing the piling up of ID/PSAs in the queue.

Then I have another task the deletes the stop.txt file 14 minutes before the show ends.

After that I have 4 different events in the SAM event scheduler to Start each PAL again. And each of those events has 9 different trigger times (12 minutes before the end of each show)

So with that the intended result is this:

Show scheduled for 5pm-6pm

4:48 - stop.txt gets created
5:00 - PAL attempts to run, sees stop.txt, turns PAL off
5:00 - show begins
5:46 - stop.txt gets deleted
5:48 - SAM starts PAL again, PAL doesnt see stop.txt and continues
6:00 - show ends, automation back to normal

My next step will be scheduling the starting/stopping of the encoder possibly 10 seconds before and after each scheduled show start time.