Old 16th April 2018, 06:59   #1
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
sc_serv crashing, can't see why

My stream has run for a few years with few problems. However, sc_serv has been crashing lately, that is to say, the process terminates. No smoking gun in the log files. Sometimes crashes 2x per day, but then sometimes it goes a week without crashing

Here's my setup

Dedicated machine, not virtual
i3-2130 3.4 GHz, 8 GB ram
DNAS Version: 2.5.1.724
Platform: posix(linux x86) [Ubuntu 14.04.5 LTS fully up to date]

I have open files (ulimit -n, ulimit -Hn, & ulimit -sn) all set to 100000

here's sc_serv.conf

password=[password redacted]
adminpassword=[password redacted]
portbase=8000
logfile=/home/noir/apps/shoutcast/logs/sc_serv.log
w3clog=/home/noir/apps/shoutcast/logssc_w3c.log
banfile=/home/noir/apps/shoutcast/logs/sc_serv.ban
ripfile=/home/noir/apps/shoutcast/logs/sc_serv.rip
maxuser=2000
streamid_1=1
streampath_1=/noir
streammaxuser_1=1750
streampassword=[password redacted]
;streamadminpassword=[password redacted]
streamid_2=2
streampath_2=/insomnia
streammaxuser_2=250
disableicy=0
streamauthhash_1=[authhash redacted]
streamauthhash_2=[authhash redacted]


The ONLY things I see in the sc_serv logs are things like these

[timestamp] ERROR SRC 108.68.181.216:3805 sid=1] SHOUTcast 1 source connection denied for user (Îú °ÈMMS  NSPlayer/7.0.0.1956; {33715801-BAB3-9D85-24E9-03B90328270A}; Host). Bad password: 198.245.61.123Îú °`MMS 


[timestamp] ERROR [SRC 139.162.79.87:46156 sid=1] SHOUTcast 1 source connection denied. Bad password: œ+<M


Looks like someone trying to connect as source but being rejected b/c they don't have the password, and they are trying to connect some oddball port

These happen about once a minute, or maybe once every other minute, different IPs

These are coming from about 10 ~ 15 different IP addresses, most in the US, some in Canada, a sprinkling from Europe and Japan

The logs do NOT indicate that one of these occurs at the instant of the crash. There is **NO** log entry made when sc_serv crashes, so I do not know if the crashes are related to these or not.

Looks like someone trying to connect as source but being rejected. Bunch of strange non-ASCII characters in the log string that come out here on this thread as  . Are these some kind of probe? Or some kind of attack?

Any thoughts anyone? Why is 2.5.1.724 crashing where before it seemed very stable.

##############################
Please note I have tried DNAS v 2.5.5.733 some time ago, and it just crashes. My stream is 48k and 2.5.5.733 seems unable to deal with that. I've posted here about that elsewhere. So, because I can't get 2.5.5.733 to work, I am using 2.5.1.724 which has worked fine for a long time.
milosz is offline   Reply With Quote
Old 16th April 2018, 18:24   #2
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 552
I had seen simular rejected connections with non-ASCII chars. I noticed that while sc_serv (2.5.5.733) was not more able to read and write write into the existing log-file. The only way to solve it was to start a manually log-rotate or an complete restart of the daemon. But in my case sc_serv is not crashed but the encoding of the affected log-file was damaged, maybe based on the non-readable chars. Not sure but maybe this creates an interrupt on your version of sc_serv. Last year I used the same version of sc_serv as x64 version on debian 7/8 but I never noticed an issue like that. The only point, on which I noticed an complete kill of the whole process was, when the source was gone completely or the source is streaming silence longer than 30 seconds.

Did you tried the x64 version?
neralex is offline   Reply With Quote
Old 16th April 2018, 20:58   #3
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
Where to get x64 versions?

Where can I download the X64 version of sc_serv version 2.5.1.724?

I assume there is also a 64 bit version of sc_trans as well?
milosz is offline   Reply With Quote
Old 17th April 2018, 10:14   #4
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 552
PM sent.

Please note: sc_trans is gone. There is no official download anymore since SHOUTcast was moved from AOL to RN (4 years ago). The development of sc_trans was stopped before it was released with a stable build. That means it was a BETA build with many many bugs. I recommend liquidsoap instead. Much better than sc_trans, maybe the best solution on linux but it comes along with a steep learning curve.
neralex is offline   Reply With Quote
Old 17th April 2018, 10:49   #5
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
Never has any problems with sc_trans

I've never had any issues with sc_trans, never bitten by any bugs there. Very easy to use.

I looked at liquid soap. Seems overly complex to me.
milosz is offline   Reply With Quote
Old 17th April 2018, 11:11   #6
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 552
Quote:
Originally Posted by milosz View Post
I looked at liquid soap. Seems overly complex to me.
I used sc_trans more than 4 years. But my life is easier since I'm using liquidsoap. The playlist management is much better, no calendar.xml, no extra playlist-files, no separate dj-files, files in an folder can be used as playlist incl. auto-reload after moving/renaming files without restarts etc...I don't miss sc_trans.
neralex is offline   Reply With Quote
Old 17th April 2018, 11:20   #7
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
Hmmm if you stop the stream, does liquidsoap 'pick up where it left off?' That's my only beef with sc_trans- I have a static playlist, over 1400 entries, just loops endlessly. But if I have to re-start sc_trans it goes back to the start of the playlist - I'd rather be able to start with the last file played.
milosz is offline   Reply With Quote
Old 17th April 2018, 11:48   #8
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 552
What do you mean with "stream" - the liquidsoap-service itself or an live-dj, who is streaming "over" the playlist-management? If you mean the service itself, how it should this work, when you restarted it - an restart stays an restart? If an live-dj stops his live-stream, then the 24/7 playlist is jumping to the next track in the playlist and starts the playback.
neralex is offline   Reply With Quote
Old 17th April 2018, 22:07   #9
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
Ummm....

Let me explain how I use my shoutcast for my 'station.'

On my server I have ~2,000 MP3 files stored, each one is an old time radio detective show of one sort or another - Dragnet, Johnny Dollar, Philip Marlowe, etc- or an ID or other canned announcement.

The playlist is just that - a list of these episodes with the order somewhat randomized, such that a 1949 Dragnet episode will play, followed by a 1949 Philip Marlowe, then a 1949 Sam Spade, then a 1950 Johnny Dollar, a 'station ID', etc etc.

sc_trans plays the files on this playlist of ~1500 entries proceeding along from first entry to the last, then starts over.

There is no DJ, no interruption, no change of playlist. It just runs, without intervention of any kind unless something stops.

So, let's say that all is well, file in the playlist at position #652 is playing to 742 listeners but then the server itself - the operating system- crashes dues to some kind of AC power problem at the datacenter.

So now, when power returns and Ubunu is running again sc_trans and sc_serv have to be restarted (I haven't automated this-)

When sc_trans restarts it will look at it's sc_trans_conf file and start the playlist at file #1, then #2, etc.

But since sc_trans was at file # 652 when things went sideways, going back to file# 1 is not ideal. It would be better if the playlist 'picked up where it left off' and played file #653, then #654 etc when restarted.
milosz is offline   Reply With Quote
Old 18th April 2018, 04:43   #10
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 552
Quote:
Originally Posted by milosz View Post
...going back to file# 1 is not ideal. It would be better if the playlist 'picked up where it left off' and played file #653, then #654 etc when restarted.
I understand waht do you mean but let me ask it again and please take your time to think about it - how should it work, when you restart the system or the service? Each application and as well the OS itself is starting from scratch. All informations in RAM and cache are gone.
neralex is offline   Reply With Quote
Old 18th April 2018, 10:28   #11
milosz
Senior Member
 
Join Date: Apr 2006
Location: chicago
Posts: 112
Yes, well, it would need to be keeping track in a disk file, wouldn't it. Write the track number to the file when it incremented in the playlist to a new file. Not all that complex.
milosz is offline   Reply With Quote
Old 9th May 2018, 10:32   #12
james06henry
Banned
 
Join Date: May 2018
Posts: 3
Very RIght, In case of this I will surely be the part of the things like this only-
Online Templates 2018 | Monthly
james06henry is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > SHOUTcast > SHOUTcast Technical Support

Tags
sc_serv crash 2.5.1.724

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump