|
|
|
|
#1 |
|
Junior Member
Join Date: Jul 2014
Posts: 5
|
1700 listeners - Segmentation fault
code: SHOUTcast DNAS 2.2.1 (Build 109) Since 1700 listeners shoutcast server shuts down. error message: Segmentation fault How can I solve this problem. In addition, this no problem SHOUTcast v1. SHOUTcast v2 problem Thank you. |
|
|
|
|
|
#2 |
|
Join Date: Sep 2003
Posts: 27,873
|
first thing, there is no need to post and also pm people the same issue.
it is a clearly noted known issue in the DNAS release thread. it is hoped that changes in the next DNAS release will resolve this long standing v2.x DNAS issue. |
|
|
|
|
|
#3 |
|
Senior Member
Join Date: Feb 2011
Posts: 377
|
im surprised you were able to get 1700 with 2.2.1
Once I get around 400 it crapped out on me. But the quick fix would be to set your limits to 300 and then launch a bunch of 2.2.1 relays and have them all use the same authhash. Hope that helps. |
|
|
|
|
|
#4 |
|
Join Date: Sep 2003
Posts: 27,873
|
i've already replied to the user's pm that was made in response to my reply in this thread and i'm sure they can wait a few days for a fix to something that's been present since 2010. so it may ot be necessary to have to run multple v2.x DNAS, though it's still a valid option if it's a matter of life and death (which no stream really can be described as being).
~1700 was generally the stable limit i could push a v2.x DNAS to for what i test with. as i've tried to explain to people, as soon as you're above ~330 concurrent listeners then you're into the unknown and anything from OS build to the OS and what it's running on (real or VM) can cause the mass of variations. hopefully the soon to be released maintenance build will resolve the issue (along with a number of other things including YP connectivity issues) once and for all. as so far i've been able to run things stable at ~2500 concurrent listeners for ~12hr test stinks thanks to the patch from our other SC dev. |
|
|
|
|
|
#5 |
|
Senior Member
Join Date: Feb 2011
Posts: 377
|
THats awesome to hear.
Before when my max limit was 5000 and not 300 my stream would get around 400-500+ and then randomly crap on me. Ever since I set the limits to 300 and then setup multiple relays I havent been able to get my numbers above 400 (main stream + relays). Coincidence? Not sure but it sucks :P |
|
|
|
|
|
#6 |
|
Join Date: Sep 2003
Posts: 27,873
|
i doubt it has much to do with changing to relays since as long as they're correctly clustered and are doing the fall over correctly from the original stream url then that can be ruled out.
with removing things off the old shoutcast.com site (the old site player and metadata puller aspect), average listener numbers have seemed to drop for a proportion of stations overall so it might be due to that or any number of things (though killing those two things has removed some of the skew that v1.x DNAS get, but for a v2.x based setup, it could just be less people are legitimately trying to play your stream). |
|
|
|
|
|
#7 |
|
Junior Member
Join Date: May 2015
Posts: 1
|
My shoutcast only allows 1015 ouvitnes is limited, someone could help me how to solve it to release more listeners in shotucast
|
|
|
|
|
|
#8 |
|
Join Date: Sep 2003
Posts: 27,873
|
what do you mean by "ouvitnes" ? but in general, if you're using linux, you (or your hosting provider) need to increase ulimit -n to a greater value than the default of 1024.
|
|
|
|
|
|
#9 |
|
Senior Member
Join Date: Feb 2011
Posts: 377
|
since this got bumped up. I thought I would post my ulimt -a. Its a bit different than the OP's settings. Can anyone give me any insite as to if I need to edit any of these settings I have?
ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63896 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 10240 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63896 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited |
|
|
|
![]() |
|
|||||||
| Thread Tools | Search this Thread |
| Display Modes | |
|
|