Autodumpusers doesn't work

dygufa · 30th September 2013, 03:31

Hi guys,

I have made deploy of the SHOUTcast DNAS 2.0 and SHOUTcast Transcoder, it works fun, but I have an issue in the dj transitions. My file config is:

code:
publicserver=never

logfile=logs/sc_serv.log

w3clog=logs/sc_w3c.log

banfile=control/sc_serv.ban

ripfile=control/sc_serv.rip

portbase=8000

maxuser=500

autodumpusers=0

autodumpsourcetime=60

password=******

adminpassword=******

streamid=1

The problem is: all the clients are desconnected when the server have no source. I tested kicking the transcoder (autodj) and while it's reconnecting all clients have your connections closed.

code:
2013-09-30 02:36:31	I	msg:<***>	Logger startup

2013-09-30 02:36:31	I	msg:<***>	version 2.0.0.29

2013-09-30 02:36:31	D	msg:<***>	

2013-09-30 02:36:31	I	msg:***************************************************************

2013-09-30 02:36:31	I	msg:** SHOUTcast Distributed Network Audio Server (DNAS)

2013-09-30 02:36:31	I	msg:** Copyright (C) 1999-2011 Nullsoft, Inc.  All Rights Reserved.

2013-09-30 02:36:31	I	msg:** Use "sc_serv filename.conf" to specify a config file.

2013-09-30 02:36:31	I	msg:***************************************************************

2013-09-30 02:36:31	I	msg:[SHOUTcast] DNAS/posix(linux x86) v2.0.0.29 (Jul 31 2011) starting up...

2013-09-30 02:36:31	I	msg:[MAIN] PID: 3892

2013-09-30 02:36:31	I	msg:[MAIN] Loaded config from sc_serv_basic.conf

2013-09-30 02:36:31	I	msg:[MAIN] Calculated CPU count is 1

2013-09-30 02:36:31	I	msg:[MAIN] Starting 1 network threads

2013-09-30 02:36:31	I	msg:[MICROSERVER] Listening for connection on port 8000

2013-09-30 02:36:31	I	msg:[MICROSERVER] Listening for connection on port 8001

2013-09-30 02:36:33	E	msg:[DST 177.214.64.10:56521 sid=1] SHOUTcast 1 client connection rejected. Stream not available. Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0

2013-09-30 02:36:33	I	msg:[DST 177.214.64.10:56521 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 0] Agent: `Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0'

2013-09-30 02:36:35	I	msg:[SRC 127.0.0.1:54931] SHOUTcast 2 source connection.

2013-09-30 02:36:35	I	msg:[SRC 127.0.0.1:54931] Password accepted. Stream id is 1

2013-09-30 02:36:35	I	msg:[SRC 127.0.0.1:54931 sid=1] stream configuration complete. [

type=SHOUTcast 2

mimeType=audio/mpeg

maxPayloadSize=16377

avgBitrate=64000

maxBitrate=64000

desiredBufferSize=160

minimumBufferSize=0

icyName=DJ PARTY

icyGenre=Misc

icyURL=http://www.site.net

icyPub=0

]

2013-09-30 02:36:35	I	msg:[SRC 127.0.0.1:54931 sid=1] Got complete metadata message type=3902 [590 bytes] id=1 span=1 content=

<?xml version="1.0" encoding="UTF-8" ?>

<metadata>

<COMM language="por">Zing MP3 - Dinh cao am nhac</COMM>

<TENC>TRANSCast DNAS/posix(linux x86) v2.0.0.54</TENC>

<TIT2>Beauty And The Beat</TIT2>

<TPE1>Justin Bieber,Nicki Minaj</TPE1>

<extension>

	<title seq="1">Justin Bieber,Nicki Minaj - Beauty And The Beat</title>

	<title seq="2">Lykke Li - I Follow Rivers (The Magician Remix)</title>

	<title seq="3">Taylor Swift - Red</title>

	<title seq="4">Alicia Keys - Girl On Fire (Original Version)</title>

	<soon>Lykke Li - I Follow Rivers (The Magician Remix)</soon>

</extension>

</metadata>



2013-09-30 02:36:38	E	msg:[SRC 177.214.64.10:56523] Remote socket closed while waiting for data

2013-09-30 02:36:57	I	msg:[DST 189.25.72.190:1972 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:37:15	I	msg:[DST 177.98.251.237:36411 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

2013-09-30 02:37:28	I	msg:[DST 201.21.61.229:58969 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 02:37:28	E	msg:[DST 201.21.61.229:58969 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 02:37:28	I	msg:[DST 201.21.61.229:58969 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 86140] Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 02:37:38	I	msg:[DST 189.35.124.78:55143 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:37:39	E	msg:[DST 189.25.72.190:1972 sid=1] Socket error while waiting to send data. err=Connection reset by peer(104)

2013-09-30 02:37:39	I	msg:[DST 189.25.72.190:1972 sid=1] SHOUTcast 1 client connection closed (42 seconds) [Bytes: 507904] Agent: `FMODEx/4.38.01'

2013-09-30 02:37:47	I	msg:[DST 201.21.61.229:59021 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 02:37:47	E	msg:[DST 201.21.61.229:59021 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 02:37:47	I	msg:[DST 201.21.61.229:59021 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 56940] Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 02:37:51	I	msg:[DST 201.27.102.18:59757 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:37:54	I	msg:[DST 189.114.71.158:50634 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:38:01	E	msg:[SRC 177.98.251.237:36417] Remote socket closed while waiting for data

2013-09-30 02:38:10	I	msg:[DST 179.104.27.128:60485 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:38:46	I	msg:[DST 187.41.18.93:49689 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1211.0 Safari/537.1

2013-09-30 02:38:47	E	msg:[DST 187.41.18.93:49689 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 02:38:47	I	msg:[DST 187.41.18.93:49689 sid=1] SHOUTcast 1 client connection closed (1 seconds) [Bytes: 70560] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1211.0 Safari/537.1'

2013-09-30 02:38:50	I	msg:[DST 187.28.55.162:52566 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:38:56	I	msg:[DST 187.41.18.93:49729 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:38:57	E	msg:[DST 177.98.251.237:36411 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 02:38:57	I	msg:[DST 177.98.251.237:36411 sid=1] SHOUTcast 1 client connection closed (102 seconds) [Bytes: 1073422] Agent: `Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36'

2013-09-30 02:39:04	I	msg:[DST 187.41.18.93:49737 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1211.0 Safari/537.1

2013-09-30 02:39:10	E	msg:[DST 187.41.18.93:49737 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 02:39:10	I	msg:[DST 187.41.18.93:49737 sid=1] SHOUTcast 1 client connection closed (6 seconds) [Bytes: 303785] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1211.0 Safari/537.1'

2013-09-30 02:39:10	E	msg:[DST 187.28.55.162:52566 sid=1] Socket error while waiting to send data. err=Connection reset by peer(104)

2013-09-30 02:39:10	I	msg:[DST 187.28.55.162:52566 sid=1] SHOUTcast 1 client connection closed (20 seconds) [Bytes: 385024] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:22	I	msg:[DST 179.198.83.224:53358 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:39:25	I	msg:[DST 177.98.251.237:36485 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

2013-09-30 02:39:30	I	msg:[DST 187.7.216.43:50452 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:39:34	I	msg:[DST 179.198.83.224:53358 sid=1] SHOUTcast 1 client connection closed (12 seconds) [Bytes: 198472] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 189.35.124.78:55143 sid=1] SHOUTcast 1 client connection closed (116 seconds) [Bytes: 1107281] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 201.27.102.18:59757 sid=1] SHOUTcast 1 client connection closed (103 seconds) [Bytes: 1083707] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 187.41.18.93:49729 sid=1] SHOUTcast 1 client connection closed (38 seconds) [Bytes: 454921] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 189.114.71.158:50634 sid=1] SHOUTcast 1 client connection closed (100 seconds) [Bytes: 952332] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 179.104.27.128:60485 sid=1] SHOUTcast 1 client connection closed (84 seconds) [Bytes: 832035] Agent: `FMODEx/4.38.01'

2013-09-30 02:39:34	I	msg:[DST 177.98.251.237:36485 sid=1] SHOUTcast 1 client connection closed (9 seconds) [Bytes: 336362] Agent: `Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36'

2013-09-30 02:39:34	I	msg:[DST 187.7.216.43:50452 sid=1] SHOUTcast 1 client connection closed (4 seconds) [Bytes: 290438] Agent: `FMODEx/4.38.01'

2013-09-30 02:40:00	I	msg:[SRC 127.0.0.1:54935] SHOUTcast 2 source connection.

2013-09-30 02:40:00	I	msg:[SRC 127.0.0.1:54935] Password accepted. Stream id is 1

2013-09-30 02:40:00	I	msg:[SRC 127.0.0.1:54935 sid=1] stream configuration complete. [

type=SHOUTcast 2

mimeType=audio/mpeg

maxPayloadSize=16377

avgBitrate=64000

maxBitrate=64000

desiredBufferSize=160

minimumBufferSize=0

icyName=DJ PARTY

icyGenre=Misc

icyURL=http://www.site.net

icyPub=0

]

2013-09-30 02:40:00	I	msg:[SRC 127.0.0.1:54935 sid=1] Got complete metadata message type=3902 [590 bytes] id=1 span=1 content=

<?xml version="1.0" encoding="UTF-8" ?>

<metadata>

<COMM language="por">Zing MP3 - Dinh cao am nhac</COMM>

<TENC>TRANSCast DNAS/posix(linux x86) v2.0.0.54</TENC>

<TIT2>Beauty And The Beat</TIT2>

<TPE1>Justin Bieber,Nicki Minaj</TPE1>

<extension>

	<title seq="1">Justin Bieber,Nicki Minaj - Beauty And The Beat</title>

	<title seq="2">Lykke Li - I Follow Rivers (The Magician Remix)</title>

	<title seq="3">Taylor Swift - Red</title>

	<title seq="4">Alicia Keys - Girl On Fire (Original Version)</title>

	<soon>Lykke Li - I Follow Rivers (The Magician Remix)</soon>

</extension>

</metadata>



2013-09-30 02:40:21	I	msg:[DST 177.98.251.237:36533 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

2013-09-30 02:40:21	I	msg:[DST 187.39.215.177:62014 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 02:40:23	I	msg:[DST 189.92.110.236:56173 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

2013-09-30 02:40:48	I	msg:[DST 187.122.224.120:61902 sid=1] SHOUTcast 1 client connection accepted. FMODEx/4.38.01

First, I didn't make the playlist(lol), second: look on 2013-09-30 02:39:34, 6 connections are closed in that moment.

I need a BackupFile parameter? I no think so.

DrO · 30th September 2013, 10:19

probably a DNAS bug though it is not guaranteed that clients will stay connected if there's no data for them to play irrespective of that option - it just allows the DNAS to keep the connection open but if the client wants to close it then they can.

a backup may help just to keep giving them some sort of audio but that causes a number of other issues of its own.

though if you're trying to keep clients when there's no source irrespective of what has caused it then no matter what you will see client connections drop when it goes dead as there's little point for most of them to stay on what is a dead stream.

dygufa · 30th September 2013, 16:06

Hi DrO,

the client connections are "controlled" by me, I'm using jwplayer (html5/flash) and I don't have this issue when the server is running the old shoutcast version. I have implemented the backup file but I couldn't see this to work, the connections are closed before it to be called:

code:
2013-09-30 15:58:29	I	msg:[DST 201.9.172.250:4811 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 15:58:56	I	msg:[SRC 127.0.0.1:55971 sid=1] Got complete metadata message type=3902 [371 bytes] id=1 span=1 content=

<?xml version="1.0" encoding="UTF-8" ?>

<metadata>

<TIT2>Strike - Ceu Completo</TIT2>

<extension>

	<title seq="1">Strike - Ceu Completo</title>

	<title seq="2">The Wanted - Chasing The Sun</title>

	<title seq="4">Eva Simons - I Dont Like You</title>

	<soon>The Wanted - Chasing The Sun</soon>

</extension>

</metadata>



2013-09-30 15:59:20	I	msg:[DST 187.65.160.79:55460 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 16:00:43	I	msg:[SRC 201.9.172.250:4822 sid=1] SHOUTcast 1 source connection.

2013-09-30 16:00:43	E	msg:[SRC 201.9.172.250:4822 sid=1] Could not create stream, a source is probably already connected.

2013-09-30 16:00:46	E	msg:[DST 187.65.160.79:55460 sid=1] Socket error while waiting to send data. err=Broken pipe(32)

2013-09-30 16:00:46	I	msg:[DST 187.65.160.79:55460 sid=1] SHOUTcast 1 client connection closed (86 seconds) [Bytes: 940851] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:04	E	msg:[SRC 201.8.153.199:52366] Remote socket closed while waiting for data

2013-09-30 16:01:14	I	msg:[DST 201.8.153.199:52379 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

2013-09-30 16:01:20	E	msg:[DST 177.1.15.208:12272 sid=1] Socket error while waiting to send data. err=Connection reset by peer(104)

2013-09-30 16:01:20	I	msg:[DST 177.1.15.208:12272 sid=1] SHOUTcast 1 client connection closed (1583 seconds) [Bytes: 12868489] Agent: `FMODEx/4.38.01'

2013-09-30 16:01:25	I	msg:[SRC 201.9.172.250:4823 sid=1] SHOUTcast 1 source connection.

2013-09-30 16:01:25	E	msg:[SRC 201.9.172.250:4823 sid=1] Could not create stream, a source is probably already connected.

2013-09-30 16:01:29	I	msg:[DST 177.70.72.34:3975 sid=1] SHOUTcast 1 client connection closed (446 seconds) [Bytes: 3808645] Agent: `Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:29	I	msg:[DST 201.8.153.199:52379 sid=1] SHOUTcast 1 client connection closed (15 seconds) [Bytes: 376267] Agent: `Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36'

2013-09-30 16:01:29	I	msg:[DST 179.98.212.212:55427 sid=1] SHOUTcast 1 client connection closed (2687 seconds) [Bytes: 21661540] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:29	I	msg:[DST 187.110.92.141:57109 sid=1] SHOUTcast 1 client connection closed (2210 seconds) [Bytes: 17855193] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:29	I	msg:[DST 201.9.172.250:4811 sid=1] SHOUTcast 1 client connection closed (180 seconds) [Bytes: 1695892] Agent: `Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:29	I	msg:[DST 177.71.82.109:51458 sid=1] SHOUTcast 1 client connection closed (382 seconds) [Bytes: 3235690] Agent: `FMODEx/4.38.01'

2013-09-30 16:01:29	I	msg:[DST 177.107.104.162:49668 sid=1] SHOUTcast 1 client connection closed (2123 seconds) [Bytes: 17164259] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:29	E	msg:[DST 177.107.104.162:52889 sid=1] SHOUTcast 1 client connection rejected. Stream not available. Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

2013-09-30 16:01:29	I	msg:[DST 177.107.104.162:52889 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 0] Agent: `Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36'

2013-09-30 16:01:32	I	msg:[SRC 201.9.172.250:4824 sid=1] SHOUTcast 1 source connection.

2013-09-30 16:01:32	I	msg:-1246725128 loadFromFilebackup file /home/shoutcast/sc/backupfile.mp3 loaded. 201772 bytes.

2013-09-30 16:01:55	I	msg:[SRC 127.0.0.1:56018] SHOUTcast 2 source connection.

2013-09-30 16:01:55	I	msg:[SRC 127.0.0.1:56018] Password accepted. Stream id is 1

2013-09-30 16:01:55	I	msg:-1246725128 loadFromFilebackup file /home/shoutcast/sc/backupfile.mp3 loaded. 201772 bytes.

2013-09-30 16:01:55	I	msg:[SRC 127.0.0.1:56018 sid=1] stream configuration complete. [

type=SHOUTcast 2

mimeType=audio/mpeg

maxPayloadSize=16377

avgBitrate=64000

maxBitrate=64000

desiredBufferSize=160

minimumBufferSize=0

icyName=DJ PARTY

icyGenre=Misc

icyURL=http://www.site.net

icyPub=0

]

2013-09-30 16:01:55	I	msg:[SRC 127.0.0.1:56018 sid=1] Got complete metadata message type=3902 [371 bytes] id=1 span=1 content=

<?xml version="1.0" encoding="UTF-8" ?>

<metadata>

<TIT2>Strike - Ceu Completo</TIT2>

<extension>

	<title seq="1">Strike - Ceu Completo</title>

	<title seq="2">The Wanted - Chasing The Sun</title>

	<title seq="3">Mc Lon - Novinha Vem Que Tem</title>

	<title seq="4">Eva Simons - I Dont Like You</title>

	<soon>The Wanted - Chasing The Sun</soon>

</extension>

</metadata>



2013-09-30 16:02:05	I	msg:[DST 201.8.153.199:52410 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

2013-09-30 16:02:06	I	msg:[DST 201.9.172.250:4834 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

Look on 2013-09-30 16:01:29 and 2013-09-30 16:01:55.

DrO · 30th September 2013, 16:14

as i said, it's probably then a bug in the DNAS but to reiterate, autodumpusers has never been guaranteed to keep connections alive (and if anything, it doing that is a bug in itself). though i've not looked at things closely as i'm on a phone at the moment and tbh just dropping it in a forum post makes it pretty difficult to read such logs properly.

dygufa · 30th September 2013, 19:05

Thank you, DrO.

How I cannot do anything about the "bug", so, the solution that I found was make a downgrade to 1.9.8 version, this worked, the connections aren't anymore closed.

Thank you again for your attention.

ebeats · 23rd November 2015, 02:58

Sorry to bump an old thread but this is still a problem in 2015 with the latest dnas v2. Whenever I kick the source, the listeners winamp will stop immeditately and not try to buffer or wait for the connection to return. Using dnas 1.9.8 this is not a problem at all. Is there any way to make v2 function the same as v1 in regards to kicking the source?

djSpinnerCee · 23rd November 2015, 04:33

how many clients have you tried this with? i only ask because what happens when the dnas kills a listener connection has as much to do with client response as server action. the v2 server presents a "different" stream than the v1 dnas in that the v2 simply appears to be an audio file, so browsers and players will do what they usually do with respect to any file served up via http.

ebeats · 23rd November 2015, 20:40

DNAS v1 - connect to stream with winamp. music plays. kick source. winamp goes in to a state of "buffering" waiting for the connection to come back. If it comes back in 30 seconds, then the stream resumes without having to hit play again.

DNAS v2 - connect to stream with winamp. music plays. kick source. winamp stops immedidately and does not ever go in to a state of buffering waiting for the connection to come back.

Is there a design change or flaw that made v2 not have the same behavior as v1? Switching back to dnas 1.9.8 makes the work as expected but I'd rather get modernized and run v2.

neralex · 24th November 2015, 06:08

Quote:

Originally Posted by DrO

as i said, it's probably then a bug in the DNAS but to reiterate, autodumpusers has never been guaranteed to keep connections alive (and if anything, it doing that is a bug in itself).

That is the reason. Set a backupfile in the v2 config-file which is starting when a source dropped.

Desavil · 10th December 2016, 17:53

I and my customers also see this problem in the SHOUTcast v2.
autodumpusers option is ignored

Please fix it.
In SHOUTcast 1.9.8 everything works well.

neralex · 11th December 2016, 00:02

Desavil, read my quote. Think about it shortly, read the manual to compare it and you should understand why 'autodumpusers' was not created to keep connections alive if a source has dropped. No source - no data for streaming. Silence on a stream makes no sense. For this case the DNAS has the backupfile param or you have to setup a source-manager.

Desavil · 11th December 2016, 09:42

Quote:

Originally Posted by neralex

Desavil, read my quote. Think about it shortly, read the manual to compare it and you should understand why 'autodumpusers' was not created to keep connections alive if a source has dropped. No source - no data for streaming. Silence on a stream makes no sense. For this case the DNAS has the backupfile param or you have to setup a source-manager.

Why it works well in SHOUTcast v1?

This works well on SHOUTcast 2 if the source itself disconnects. If I use the kick source function it causes this problem.
The backup file does not work too well. If DJ connect immediately after the next DJ, the stream stops when I use backup file.

This is a big problem for SHOUTcast hosting providers. Where clients use different bitrates.

neralex · 12th December 2016, 05:04

From a technical point: scroll up and read DrO's posts!

From my point: Setup an source manager / transcoder. Your DJs can stream with different bitrates on the transcoder, which is connected on sc_serv. The transoder will encode each source to a defined bitrate. Create a 24/7 playlist in the source-manger, which will start, if no live-dj is connected and all is fine.

Desavil · 12th December 2016, 13:01

Quote:

Originally Posted by neralex

From a technical point: scroll up and read DrO's posts!

From my point: Setup an source manager / transcoder. Your DJs can stream with different bitrates on the transcoder, which is connected on sc_serv. The transoder will encode each source to a defined bitrate. Create a 24/7 playlist in the source-manger, which will start, if no live-dj is connected and all is fine.

To my own use - good.
I am a SHOUTcast service provider (hosting) and it is not so easy for my customers.

Dro clearly wrote "probably a DNAS bug" and "it's probably then a bug in the DNAS".

denis9408 · 15th January 2017, 16:29

I have the same problem.
All the clients are desconnected when the server have no source.

How long we have to wait for a fixed this bug?

djSpinnerCee · 16th January 2017, 12:09

maybe not a bug - when there's no source the dnas does not send any data - the tcp connections made by listeners will eventually time out and be closed.

denis9408 · 16th January 2017, 19:57

No. It is not normal.
I do not use sc_trans.
When you change the dj, disconnects all listeners.

In shoutcast v1 this problem was not there.

djSpinnerCee · 16th January 2017, 20:51

all i can say is times are changing -- there is so much media being delivered by internet streams -- the tcp stack and applications that depend on it are becoming very bandwidth efficient:

players buffer -- they fill their buffer and add to it as they use the buffered data. if it stops, they're gonna wait for more, but not forever. it's actually more efficient to drop the connection and re-buffer the stream, since the buffer is empty anyway, because why has the stream stopped? in your dnas log, you should see these reconnection attempts, but until there is a new source, they will be denied access. from a dnas stats standpoint - listeners on a stream with no source are, in a way, undefined.

denis9408 · 22nd January 2017, 21:31

The problem (disconnected all listeners) occurs when using the "kick source".

Very please add an option in the shoutcast 2 that allows you to enable or disable the ejection of the listeners during the use of "kick source".

30th September 2013, 10:19	#2
DrO Join Date: Sep 2003 Posts: 27,873	probably a DNAS bug though it is not guaranteed that clients will stay connected if there's no data for them to play irrespective of that option - it just allows the DNAS to keep the connection open but if the client wants to close it then they can. a backup may help just to keep giving them some sort of audio but that causes a number of other issues of its own. though if you're trying to keep clients when there's no source irrespective of what has caused it then no matter what you will see client connections drop when it goes dead as there's little point for most of them to stay on what is a dead stream. WACUP Project <‖> "Winamp Ramblings" - Indie Winamp Dev Blog

30th September 2013, 16:14	#4
DrO Join Date: Sep 2003 Posts: 27,873	as i said, it's probably then a bug in the DNAS but to reiterate, autodumpusers has never been guaranteed to keep connections alive (and if anything, it doing that is a bug in itself). though i've not looked at things closely as i'm on a phone at the moment and tbh just dropping it in a forum post makes it pretty difficult to read such logs properly. WACUP Project <‖> "Winamp Ramblings" - Indie Winamp Dev Blog

23rd November 2015, 04:33	#7
djSpinnerCee Forum King Join Date: Aug 2004 Location: Hollis, Queens/The Bronx, NYC Posts: 3,555	how many clients have you tried this with? i only ask because what happens when the dnas kills a listener connection has as much to do with client response as server action. the v2 server presents a "different" stream than the v1 dnas in that the v2 simply appears to be an audio file, so browsers and players will do what they usually do with respect to any file served up via http. /* v2 HTML5 / Player test pages DigitalMixNYC, DigitalMixNYCbx \| DNAS Status: Now Playing js codes (scaststatus_X.php) \| PortForward.com \| Upload/Download Speed Test \| No-IP.com: Free Dynamic DNS \| In the YP \| dnasDir */

16th January 2017, 12:09	#16
djSpinnerCee Forum King Join Date: Aug 2004 Location: Hollis, Queens/The Bronx, NYC Posts: 3,555	maybe not a bug - when there's no source the dnas does not send any data - the tcp connections made by listeners will eventually time out and be closed. /* v2 HTML5 / Player test pages DigitalMixNYC, DigitalMixNYCbx \| DNAS Status: Now Playing js codes (scaststatus_X.php) \| PortForward.com \| Upload/Download Speed Test \| No-IP.com: Free Dynamic DNS \| In the YP \| dnasDir */

16th January 2017, 20:51	#18
djSpinnerCee Forum King Join Date: Aug 2004 Location: Hollis, Queens/The Bronx, NYC Posts: 3,555	all i can say is times are changing -- there is so much media being delivered by internet streams -- the tcp stack and applications that depend on it are becoming very bandwidth efficient: players buffer -- they fill their buffer and add to it as they use the buffered data. if it stops, they're gonna wait for more, but not forever. it's actually more efficient to drop the connection and re-buffer the stream, since the buffer is empty anyway, because why has the stream stopped? in your dnas log, you should see these reconnection attempts, but until there is a new source, they will be denied access. from a dnas stats standpoint - listeners on a stream with no source are, in a way, undefined. /* v2 HTML5 / Player test pages DigitalMixNYC, DigitalMixNYCbx \| DNAS Status: Now Playing js codes (scaststatus_X.php) \| PortForward.com \| Upload/Download Speed Test \| No-IP.com: Free Dynamic DNS \| In the YP \| dnasDir */

30th September 2013, 19:05	#5
dygufa Junior Member Join Date: Sep 2013 Posts: 3	Thank you, DrO. How I cannot do anything about the "bug", so, the solution that I found was make a downgrade to 1.9.8 version, this worked, the connections aren't anymore closed. Thank you again for your attention.

23rd November 2015, 02:58	#6
ebeats Junior Member Join Date: Nov 2015 Posts: 4	Sorry to bump an old thread but this is still a problem in 2015 with the latest dnas v2. Whenever I kick the source, the listeners winamp will stop immeditately and not try to buffer or wait for the connection to return. Using dnas 1.9.8 this is not a problem at all. Is there any way to make v2 function the same as v1 in regards to kicking the source?

23rd November 2015, 20:40	#8
ebeats Junior Member Join Date: Nov 2015 Posts: 4	DNAS v1 - connect to stream with winamp. music plays. kick source. winamp goes in to a state of "buffering" waiting for the connection to come back. If it comes back in 30 seconds, then the stream resumes without having to hit play again. DNAS v2 - connect to stream with winamp. music plays. kick source. winamp stops immedidately and does not ever go in to a state of buffering waiting for the connection to come back. Is there a design change or flaw that made v2 not have the same behavior as v1? Switching back to dnas 1.9.8 makes the work as expected but I'd rather get modernized and run v2.

10th December 2016, 17:53	#10
Desavil Junior Member Join Date: Nov 2016 Posts: 27	I and my customers also see this problem in the SHOUTcast v2. autodumpusers option is ignored Please fix it. In SHOUTcast 1.9.8 everything works well.

11th December 2016, 00:02	#11
neralex Major Dude Join Date: Mar 2011 Posts: 576	Desavil, read my quote. Think about it shortly, read the manual to compare it and you should understand why 'autodumpusers' was not created to keep connections alive if a source has dropped. No source - no data for streaming. Silence on a stream makes no sense. For this case the DNAS has the backupfile param or you have to setup a source-manager.

12th December 2016, 05:04	#13
neralex Major Dude Join Date: Mar 2011 Posts: 576	From a technical point: scroll up and read DrO's posts! From my point: Setup an source manager / transcoder. Your DJs can stream with different bitrates on the transcoder, which is connected on sc_serv. The transoder will encode each source to a defined bitrate. Create a 24/7 playlist in the source-manger, which will start, if no live-dj is connected and all is fine.

15th January 2017, 16:29	#15
denis9408 Junior Member Join Date: Jan 2017 Posts: 3	I have the same problem. All the clients are desconnected when the server have no source. How long we have to wait for a fixed this bug?

16th January 2017, 19:57	#17
denis9408 Junior Member Join Date: Jan 2017 Posts: 3	No. It is not normal. I do not use sc_trans. When you change the dj, disconnects all listeners. In shoutcast v1 this problem was not there.

22nd January 2017, 21:31	#19
denis9408 Junior Member Join Date: Jan 2017 Posts: 3	The problem (disconnected all listeners) occurs when using the "kick source". Very please add an option in the shoutcast 2 that allows you to enable or disable the ejection of the listeners during the use of "kick source".

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode