Old 20th February 2015, 16:26   #1
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
V2 server issues

Howdy folks, wondering if anybody else is having the same problem I am...

Have been internet broadcasting for over 9 years now, until this past month using a service that had the Shoutcast V1 servers. I now have been switched to the V2 servers to hopefully get some ad revenue coming in.

My station is 24/7, I have 22 different "Hosts" that will come in on their respective timeslots and host their 1 to 3 hour shows.
Until I switched to the V2 server I have never experienced a drop in listeners when a host "Kicks" the streaming computer (mine running SAM broadcaster) as I have always kept the setting "Disconnect Listeners When The Source Disconnects" to "NO"

Now that I am on the V2 server the ONLY way I can keep my listeners online when a new host comes on is if a smooth handoff is made from one dropping and the other starting their encoders right away. If a host uses the "Kick Source" link all of my listeners are dumped, and when you're running a Bluegrass station it's hard to get them back half the time.

Is this issue occurring with anybody else?

It appears that the "Kick All" subroutine in the server software is crossed with the "Kick Source"

"I'm no programmer but I did stay at a Holiday Inn Express last night!"
OldManInWva is offline   Reply With Quote
Old 20th February 2015, 23:43   #2
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
Additional info

I guess I should have also noted that I am using the 3 Feb 2015 build of the SHOUTcast Server v2.4.3.216/posix(linux x64).
OldManInWva is offline   Reply With Quote
Old 21st February 2015, 10:51   #3
dopelabs
Major Dude
 
dopelabs's Avatar
 
Join Date: Oct 2006
Location: Silicon Valley
Posts: 531
Send a message via AIM to dopelabs
do you have

autodumpusers=0

in the config?
dopelabs is offline   Reply With Quote
Old 21st February 2015, 11:12   #4
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
I do not have access of the config file, the stream provider uses Centovacast... which thru it's promps modifies the config.

There is a setting with a yes or no answer to "Disconnect listeners if source disconnects:"

And I have "NO" selected

Never had a problem with this before under the V1 servers for the past 9 years.
OldManInWva is offline   Reply With Quote
Old 21st February 2015, 11:53   #5
dopelabs
Major Dude
 
dopelabs's Avatar
 
Join Date: Oct 2006
Location: Silicon Valley
Posts: 531
Send a message via AIM to dopelabs
if you have the config set to specifically not disconnect listeners when the source drops, and its doing so, i would start with a support ticket or bug report to your stream provider. i am using SHOUTcast Server v2.4.2.167/posix(linux x64) and everything is working as expected.

are you sure they are getting dropped by sc_serv and not just disconnecting because of the crude interruption you create when kicking source? all listeners and not just a few, every time? what does the logfile look like when this series of events happens?
dopelabs is offline   Reply With Quote
Old 21st February 2015, 23:35   #6
DrO
 
Join Date: Sep 2003
Posts: 27,873
for note, this is already being dealt with via the CDN responsible for the hosting (and is ideally where such things should be reported through so they can report it and provide more specific details about things, especially when non-public beta builds are involved).

however, kicking a source is meant to disconnect listeners as kicking a source or stopping a source relay are the same action (just with different wording to make it more specific to what is feeding the stream at the time). so what is being seen is the intended behaviour and if it is not doing it with earlier 2.x releases then that is a bug with those builds.

to my knowledge, the 1.x DNAS was meant to do the same thing. if there's a difference then something went wrong with the initial 2.x implementations. however, the only possible solution is to introduce an additional mode to the intended behaviour (maintained as the default) so you either remove the source and drop all listeners or remove the source and leave them connected (subject to timeouts on the DNAS and also on the listener handling).

as setting the auto dump options to zero is still not guaranteed to keep the listener connection as most will timeout and drop the connection of their own accord when they don't receive any stream data (as is going to happen if no source is connected and so no audio is being provided).

if anything, the better option would be to ensure the DNAS install is setup with a backup file (even if it's only a second of silence) which can then be used by the DNAS to keep sending something to the listeners in-order to keep the connection alive. alas, the backup file handling in the 2.x DNAS as-is doesn't reliably transition back to the stream (that is being fixed for the next beta build sent to applicable CDNs - as is the case in this specific instance) which will then allow that to work in a more sane manner.

and my final comment, it's much better to have some sort of auto-DJ which can handle the different DJ connections and in-turn provide fallback stream data than force kicking the source from the DNAS as that will break things for a lot of listeners due to incomplete stream data (more so for those using Flash / HTML5 audio players which do not cope that well with incomplete audio frames as happens when a source is kicked / drops).
DrO is offline   Reply With Quote
Old 22nd February 2015, 00:39   #7
dopelabs
Major Dude
 
dopelabs's Avatar
 
Join Date: Oct 2006
Location: Silicon Valley
Posts: 531
Send a message via AIM to dopelabs
ill also add that you can pretty much avoid this by using automation to switch between live and archived content.
dopelabs is offline   Reply With Quote
Old 22nd February 2015, 00:40   #8
DrO
 
Join Date: Sep 2003
Posts: 27,873
which is what I said in my final comment in my reply.
DrO is offline   Reply With Quote
Old 22nd February 2015, 09:27   #9
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
DrO... If "Kicking" the source was meant to drop the listeners, then why is there "2" links on the admin page for the server? One for kicking the "Source" and then the next, which applies to the listeners which says "Kick All". when clicked, disconnect all listeners.

In the past nine years, while using V1 (and under 3 different providers) I have NEVER dropped more than just a few (3 to 10) listeners on a stream that had 200 at the time.

And in this case EVERY listener is dropped from the stream.

In all the cases I use a 15 second auto-reconnect setting on my encoders of SAM. so there is never more than 15 seconds of non-connection on the server.

I was playing with a public build V2 server before switching to this advert one, tried the Fallback file, it would not come on. And yes, it's made with the same attributes as the original stream. My fallback file is 1 hour long, in case I have a power outage, is this too big of a file??

I will try it on this server build and see if it works, I would think that if the option was available on my configuration page (my provider uses Centova) that it would be turned on for use.

What it all boils down to for me is, a new build of a server should act in the same fashion as an older one, just have more or enhanced features. Something like switching the sources, when never was an issue in the V1 builds I used before, one would hope would not be an issue in the latest build.

The auto DJ feature can't hold a candle to the software I use (Sam Broadcaster Pro) and with 22 DJ's, and 5 pre-recorded syndicated shows running, it's easier to operate from my computer and connect to a stream, and when it's time for the hosts to start their show, they just break in and go.

Not trying to be a pest about this, it's just that for 9 years it worked one way just great, kept the listeners connected and now it's not, sooooo... whether the V1 was not working as advertised or not I need to know what I'm working with here.
OldManInWva is offline   Reply With Quote
Old 22nd February 2015, 19:26   #10
DrO
 
Join Date: Sep 2003
Posts: 27,873
kick all is not the same as kick source. the 2.x DNAS works in the manner that it's been doing since it was released and based on my experience with 1.x DNAS, it's doing the same.

in either case, i've explained things as I can and anything else needing to be will be progressed through your host (as has to be done when you're using a pre-release build of the DNAS).

and the Centova interface doesn't expose everything the 2.x DNAS can do and there's also some incompatibilities with the pre-release build and Centova at the moment (which they have been notified about...).
DrO is offline   Reply With Quote
Old 22nd February 2015, 20:12   #11
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
Thanks for your time...

.. I know what you're saying, and I've thought that about Centova and this particular build.

One other note that you may not be aware of.. I did run a 5 second dead air Fallback file on both the advert build and an earlier version of the V2 server..
Can't get any fallback file to run on the Advert version... Once again, could be the centova interface.
Works fine on the older V2 server.

Again, Thanks for your time...

Roger
OldManInWva is offline   Reply With Quote
Old 22nd February 2015, 20:18   #12
DrO
 
Join Date: Sep 2003
Posts: 27,873
the fallback file issue is known to not work 100% in the build (did mention it in my first reply) and something that will be fixed for the next pre-release build (as we're having to break some areas in-order to get them all working properly in relation to stability issues).
DrO is offline   Reply With Quote
Old 24th February 2015, 22:53   #13
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
As a workaround for my original posted issue, I have reverted back to my original V1 servers and am using the mountpoints configs on the V2 servers for each of my streams to relay from the V1 servers.
This.. along with fallback files ( which I found seem to only work when there is an intro file uploaded on the same server ) keep most the listeners intact when a source change is made on the V1 server.

Thanks for all the help and ideas..
OldManInWva is offline   Reply With Quote
Old 24th February 2015, 23:17   #14
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by OldManInWva View Post
This.. along with fallback files ( which I found seem to only work when there is an intro file uploaded on the same server )
please explain and is this on the 2.x DNAS or the 1.x DNAS ?
DrO is offline   Reply With Quote
Old 27th February 2015, 09:41   #15
OldManInWva
Junior Member
 
Join Date: Feb 2015
Posts: 8
Intro file

Several month back I had tried using a fallback file on the V1 DNAS server (
SHOUTcast Server Version 1.9.8/Linux) and never could get the file to respond when dropping the source.
After moving to the V2 I had also tried the same file and never could get it to work (Fallback)

After deciding to go back to the V1 and relaying to the V2 I decided to add an Intro file to the V2 and after that the Fallback file started working..

It was a 5 sec dead air and I had tested it using Winamp and watched the time connected timer click away.

Took the Intro file out and tried the dropping the source connection again and it would drop the stream (Most of the time)

I did not experiment with it more as I was trying to get my station back up and stable.

All I know is that in the past 2-3 days I have hardly dropped any listener connection, I keep an iTunes player running on one of my computers and it's been a non-stop connection on my station since.

R
OldManInWva is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Shoutcast > Shoutcast For Business & Monetization

Tags
kick source, shoutcast v2

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