Do you have a stable setup? If so, please list your specs..

[drivehell]

This might be a longshot, because I'm not sure if any experienced broadcasters frequent this forum anymore but..

I'm trying to find the most stable environments for hosting sc_serv.

If you have a stable setup, please list the following:

• shoutCAST version
• OS
• current uptime
• hosted on VPS or dedicated?

[neralex]

There is nothing long - the answer has 5 letters: Linux.

In gerneral it makes no huge difference if you are using Windows or Linux. Uptime is a question how often you have to reboot the box and its based on the internet connection.

[drivehell]

Originally Posted by neralex

There is nothing long - the answer has 5 letters: Linux.

In gerneral it makes no huge difference if you are using Windows or Linux. Uptime is a question how often you have to reboot the box and its based on the internet connection.

Our main relay is on Linux.. daily it has issues.. running latest version of sc_serv.. I have read that 2.4.7 is the last stable one. Trying to confirm this.

[keijo]

Here are my specs.

SHOUTcast Server v2.5.1.724/posix(linux x64)
OS: CentOS 7 x64
Daemon Uptime: 1 week or so, doesn't "tilt"
hosted on VPS or dedicated? VPS within a dedi(cated)

Stream Uptime: about 5 days

All its burden is to take care of the DNAS. It serves 2 streams: AAC+ 48kbps, MP3 64kbps.
Currently holding around 24 stable listeners with peaks up to 50
One (normally unneeded) manual reboot per week for cleaning up.

So far no issues et al with anything, runs smoothly. But I don't load the VPS with anything else.

Hope it helps.

Regards,
Keijo!

[NatSurvivorsNW]

Here are my specs.

SHOUTcast Server v2.4.0.147/posix(linux x64)
OS: CentOS 7 x64
Daemon Uptime: 12 days so far
hosted on VPS

Stream Uptime: about 12 days no issues at all.

The VPS also runs my Joomla CMS, CometChat all fine.

Regards
Stephen

[dopelabs]

any linux distro should serve you proper... shoutcast DNAS will even run stable on a $35 raspberry pi...

heres some stats from one of my servers that has been up for a while.. this one happens to be running on a VPS. other servers i have are dedicated but have been rebooted relatively recently for one reason or another...

Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

SHOUTcast Server v2.4.7.256/posix(linux x64)
Uptime: 36 weeks 2 days 10 hours 31 minutes 55 seconds


if your host is having any type stability issues with a shoutcast server, its time to find a new host. feel free to hit me up =]

[drivehell]

Originally Posted by dopelabs

any linux distro should serve you proper... shoutcast DNAS will even run stable on a $35 raspberry pi...

heres some stats from one of my servers that has been up for a while.. this one happens to be running on a VPS. other servers i have are dedicated but have been rebooted relatively recently for one reason or another...

Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

SHOUTcast Server v2.4.7.256/posix(linux x64)
Uptime: 36 weeks 2 days 10 hours 31 minutes 55 seconds


if your host is having any type stability issues with a shoutcast server, its time to find a new host. feel free to hit me up =]

Thanks for the offer.. but I have lots of places to test, so I ruled out it being a problem with the hosts. The problem is that sc_serv would just hang randomly 1-2x a day or week and I started looking for a copy of 2.4.7.

I think it was the sc_serv version we were using - 2.5.1.724 and I got it stabilized (as far as I know) by changing some config settings; however I still read about someone having issues with listeners dropping after the server hit a certain cap... That could very well still be a problem, but I have not looked that closely.

[dopelabs]

did they say at what listener count they started experiencing problems? i can try and repro using whatever version DNAS with a load testing script i wrote...

[andrewsymond]

dwsswee

[drivehell]

Originally Posted by dopelabs

did they say at what listener count they started experiencing problems? i can try and repro using whatever version DNAS with a load testing script i wrote...

Here's the original post.

Originally Posted by WizardX

Somehow since we implemented the 2.5.1 we encounter that we have less simultaneous users and drops when a specific range is reached. No errors in the logfiles. Any suggestions?

but then he also said this..

Originally Posted by WizardX

I found out why we had these buffer issues. We we're using streambackupurl which was offline. When we brought the backup stream online or when we commented out the command from the config all problems we're gone all of a sudden.

[dopelabs]

well that doesnt really explain much. that could easily be any number of reasons still... whats the max user set in the config, whats the max ustream capabilities of that host. ive seen patterns like that before when a server starts to have more listeners than what the upstream can handle, thus buffering , thus the tuneouts, once a bunch of people tune out, theres enough bandwidth again, so the count will start to rise again, and up and down it goes.. and with only a single window of a few hours to go by, you cant make any assumptions until you have a history of say a week with that happening on a regular bases...

i can show you even more drastic changes in listener numbers... one of my stations is included in a multiplayer video game. when a player turns the stream on in hte game, anyone also playing within earshot also hears it. and the way they implemented that is to bascially have all the other players clients tune into the stream when they enter the earshot range. when theres lots of players, ive seen 100's tune in almost all at once, then half would leave in one go, then another 60 would tune in. sometimes if the players are stationary other people will hang out in the same area as to hear the music they can be connected for hours, then the guy playing the stream disconnects and all of the sudden i can go from 300 to 40 all at once.


but hey, if anyone else tries removing the streambackupurl. and it solves the problem, then the shoutcast devs can know where to start at least. can anyone else confirm?

[drivehell]

Originally Posted by dopelabs

that could easily be any number of reasons still... whats the max user set in the config, whats the max ustream capabilities of that host. ive seen patterns like that before when a server starts to have more listeners than what the upstream can handle, thus buffering , thus the tuneout...

I think we can rule out all of the above since they say the problem started after they upgraded sc_serv. I am trusting the OP's word though, because it appears to me they are a long-time experienced streamer who noticed these issues suddenly after a long period of solid streaming.

P.S. Have you upgraded any of your relays to 2.5.5?

[dopelabs]

yes i have been running an instance and have put a load of 500 listeners on it and i havent noticed any problems

[MegaRock]

Mine are all on Linux and self managed which isn't terribly hard to do. Mix of VPS and dedicated boxes and one main server which is private for distributing to the relays which sits on a cloud for redundancy. While most have been rebooted recently for other reasons I do have one AAC stream that's been running interruption free for months without issue. VPS are metered so those are set for limited use, several others are 3 - 33 tb monthly which is plenty. I have one sitting on a VPS I paid $8.00 for a year service.... they are right SC should run stable on just about any Linux system.