Auto DJ keeps butting in on live shows and live stream sounds like a fast casette tape

Hi there,

I have a problem. When Presenters are doing live shows, the Auto DJ keeps butting in and disrupting the live shows. Also, the live stream sounds like a fast casette tape. Does anyone else have this problem? I don't know whether the error is with Shoutcast or with the company we go through that enables us to stream on Shoutcast. I have contacted them, but they say it is a buffering issue and has now been resolved. The live shows were going out on 128kbps and we were advised to turn it down to 64 as that should solve the problem. But, it hasn't done. I'm at a loss to now know what to do and have had to take the live Presenters off air as the live shows aren't broadcastable.

We stream our own show with Auto DJ not running. However that means manually stopping Auto DJ and re-booting the server, and then likewise after the show finishes. However, the other Presenters quite understandably don't want to fiddle around like that on someone else's server. So they stream their shows with Auto DJ enabled. However I've been advised that that shouldn't mean that the Auto DJ will butt into live shows, when someone is connected.

The only other thing I can think of is to change from the company we go through, that provides Shoutcast. But, I do not know whether that is where the fault is lying, or whether the fault is with Shoutcast.

Please can someone advise.
Thank you.
Rebecca Pickles.


Level 1 Support
Staff member
Hi Rebecca,

Welcome to the forums. :)

Yes your hosting company is right in that this is probably a buffering issue to be honest. Your AutoDJ stream is likely cutting in because your live source is occasionally dropping its connection to their server. This is supposed to happen as the AutoDJ acts as a back up stream to the live stream and also so there is no gaps of silence in between live shows etc.

It sounds to us like you may have some packet loss on your own network (or the DJ's own networks) that is causing these occasional drop outs when you stream live. It's not a Shoutcast issue!

We would have thought dropping this down to 64kbps from 128kbps would help improve this though. You shouldn't need to keep disconnecting the AutoDJ for whenever you stream live either, this was one of the main improvements of Shoutcast v2 that you no longer have to manually do this each time like you did with v1.

We cannot comment in this situation on the quality of your current providers servers (Who do you host with out of interest?). But if you are looking for a new host then please feel free to give our own server hosting a try if you like. You can sign up for a free 7 day trial account with us here:
Hi again,

Thank you for your reply. I appreciate it. You mentioned something that I wasn't aware of. Shoutcast v2 means you no longer have to manually start and stop auto DJ each time a live presenter goes on air. We are on Shoutcast v1.

When we do our own morning show we don't have a problem with the auto dj butting in. That is because we manually stop the auto dj, reboot the server and stream from a different port number. As understandably other presenters don't want the fiddle of logging in to the server to stop the auto dj and reboot the server, and then go through the routine again when their show has finished, they are on the encoders which mean they broadcast their shows whilst the auto dj is still enabled. (If I could manually stop auto dj and reboot the server for all presenters then I would, but unfortunately I am unable to do that throughout the day as I also have another job).

Regarding the possibility that the broadband maybe causing the problem, I am unsure because the other presenters broadcast from their own studios and they connect direct to the streaming company, so they are by-passing our broadband and our studio.

So, is there a possibility that this issue is being caused due to us being on Shoutcast v1 and not v2? You asked which company we are with. It's Geckohost.

Thanks again.


Level 1 Support
Staff member
No problem at all, you're welcome.

Oh right! Are you 100% sure you are still running v1 as it is not at all possible for the AutoDJ stream to be active when a live stream is running. You have to manually disconnect the AutoDJ source in order to even be able to connect a live source in v1. From what you say you must be on Shoutcast v2.

No the issue here is not with Shoutcast or even the version of it that you are running on. Any buffering issues or the live stream dropping its connection (where the AutoDJ comes back in) is most likely down to your DJ's internet connections at their studios. There could be several reasons as to why they occasionally drop their connection such as packet loss from their internet provider, running other bandwidth hungry programs whilst trying to stream, streaming over wifi rather than ethernet and more! On the other hand the issue could be with your providers servers instead or an unfortunate combination of both.

We cannot comment on Geckohosts servers as we have never used them ourselves and it's not our place to do so. But sometimes you'll find with some of these hosting companies who provide cheap Shoutcast hosting is that they often use very cheap servers and then really over sell them which therefore does not always provide the best performance.

Thank you again for your reply. On the plus side I am learning a lot more about how streaming operates! Regarding whether it is v1 or v2, from your explanation it does sound as though I am on v2. In the encoder settings it's set to Shoutcast v1, but the log in to centova cast does say Shoutcast version 2.

I've also had a reply from the company I'm with and it fits in with your theory of packet loss. The reply is below:

"I can confirm there are a few issues with the buffering:
2018/07/03 03:51:04 [clock.wallclock_main:2] We must catchup 1.03 seconds!
2018/07/03 03:51:05 [clock.wallclock_main:2] We must catchup 1.31 seconds!
2018/07/03 03:51:06 [clock.wallclock_main:2] We must catchup 1.59 seconds!
2018/07/03 03:51:07 [clock.wallclock_main:2] We must catchup 2.00 seconds!
2018/07/03 03:51:08 [clock.wallclock_main:2] We must catchup 2.52 seconds!
2018/07/03 03:51:09 [clock.wallclock_main:2] We must catchup 2.91 seconds!
2018/07/03 03:51:10 [clock.wallclock_main:2] We must catchup 3.32 seconds!
2018/07/03 03:51:11 [clock.wallclock_main:2] We must catchup 3.89 seconds!
2018/07/03 03:51:12 [clock.wallclock_main:2] We must catchup 4.30 seconds!
2018/07/03 03:51:13 [clock.wallclock_main:2] We must catchup 4.84 seconds!
2018/07/03 03:51:14 [clock.wallclock_main:2] We must catchup 5.25 seconds!
2018/07/03 03:51:15 [clock.wallclock_main:2] We must catchup 5.64 seconds!
2018/07/03 03:51:16 [clock.wallclock_main:2] We must catchup 6.01 seconds!
2018/07/03 03:51:17 [clock.wallclock_main:2] We must catchup 6.45 seconds!
2018/07/03 03:51:18 [clock.wallclock_main:2] We must catchup 6.91 seconds!
2018/07/03 03:51:19 [clock.wallclock_main:2] We must catchup 7.27 seconds!
2018/07/03 03:51:21 [clock.wallclock_main:2] We must catchup 7.58 seconds!
2018/07/03 03:51:22 [clock.wallclock_main:2] We must catchup 7.76 seconds!
2018/07/03 03:51:23 [clock.wallclock_main:2] We must catchup 8.17 seconds!
2018/07/03 03:51:24 [clock.wallclock_main:2] We must catchup 8.61 seconds!
2018/07/03 03:51:25 [clock.wallclock_main:2] We must catchup 8.99 seconds!
2018/07/03 03:51:26 [clock.wallclock_main:2] We must catchup 9.39 seconds!
2018/07/03 03:51:27 [clock.wallclock_main:2] We must catchup 9.76 seconds!
2018/07/03 03:51:28 [clock.wallclock_main:2] We must catchup 10.06 seconds!

We have informed the datacentre as they hold full control and there isn't much else we can do.

We've restarted your server and I've been listening for a little while and it seems to be working okay".

We played a show through the desk this morning on the encoder settings that we give to other Presenters. It did sound better, but the auto dj was still butting in every now and then. So, watch this space! Unfortunately, but understandably, it doesn't go down well with other presenters on the station, even though the fault doesn't lie at my end. We've had one presenter leave us this morning, but one doesn't give up and we do plod on!

Thanks again.


Level 1 Support
Staff member
Some live encoder software still requires you to use the v1 protocol for v2 servers. So don't worry, you are not the first person that has been confused by this.

We hope that you are able to resolve this one way or another anyway. And as we said previously, if you are ever looking for a new host then please feel free to give our own server hosting a try. You can sign up for a free 7 day trial account with us here:

All the best! :)

Yes, we were looking at that this morning. We noticed your free trial only allows 5 listeners. However, we were looking at your £18 package that holds 1000+ listeners.


Level 1 Support
Staff member
Yes the free trial only provides 5 listeners as it is just for testing purposes.

You can sign up the monthly £18 (500GB) plan straight away if you want or just upgrade the free trial account at anytime to that plan when you have finished testing the services.