shoutcast repeats last few seconds for new clients when source is gone

[Mayz]

Hello,

I have a strange problem, i've setup shoutcast to play a backup track when src is gone, what happens in my case is that i have shoutcast playing the last few seconds of what the src sent and doesnt play the backup file, given that the src client was not "disconnected", rather there has been problems with the network!

I've tried various things, reducing AutoDumpSourceTime down to 3 seconds, even changing kernel options such as net.ipv4.tcp_keepalive_time and net.ipv4.tcp_fin_timeout , but still , i script that i have that has player restarting whenever it reaches the endo of stream in order to keep playing even if there was loss of connectivity or player ccrashed fro any reason ...etc. , i get the same audio streamed again and again and not the backup file.

Thank you in advance.

[Mayz]

a little edit, by network problems i mean complete loss of link, by disconnecting the source i mean quitting the streaming client for example.

[dotme]

You're grabbing the last few seconds of audio stored in the buffer of the shoutcast server, I suspect.

If the backup file isn't kicking in (and you're sure you restarted the server after setting a backup file) then check the bit rate/sample rate of the backup file. It should be encoded to match your live stream. Also, make sure you removed the comment tag from the line dealing with the backup file in the config file

Hope this helps

[djSpinnerCee]

The repeating data may also be the player's local buffer -- since it cannot get more data from the DNAS, it is playing what it still has until it can get more from the DNAS (rebuffer).

[Mayz]

Well, the backup file works when there is disconnection, that is, if the link is working fine, and i close winamp or do disconnect, the backup file plays ... :S ... strange

[djSpinnerCee]

That's kinda how it's supposed to work -- if the netwoprk problem is between the listener and DNAS, the listener won't be able to get the backup data or the stream -- realize that the listener will never get the backup data if the source is online to the DNAS. It seems like you think that the DNAS sends both the stream and the backup file whenever a listener connects to the DNAS, this is not the case.

A simple workaround could be to have listeners launch the stream from an .m3u or other playlist type file containing the stream url and a backup .mp3 URL that is hosted in a different "place" from the DNAS so that a network issue to one would cause a fallover to the second.

ie: launch_stream_with_backup.m3u
http://dnas_at.example.com:8000/
http://different_location_at.example2.com/mp3s/backup.mp3

That's all -- what will happen is when the listener loses connectivity to the DNAS, their player should "skip" to the next track in the playlist (backup.mp3), the length of backup.mp3 can be customized to how you want it to work -- ie: it could simply be a 10sec. message that the server is having issues, or a 90min. archived show -- if the listener's player is set to "loop" (also called "repeat all"), it will try to reconnect again to the DNAS after the backup.mp3 has played.

A single DNAS cannot do this on it's own since it only exists in a single location -- one of the advantages of using a cluster-creating relay setup is to provide some redundancy to different hosts in different locations which will do pretty much the same thing -- but realize that network connectivity issues can still mess the whole thing up since relays need reliable connectivity to communicate with each other and the YP.

[Mayz]

Well, in my case i have both the sc server and the client on the same machine, so there should be no connectivity problems between them, the machine that has all the mp3s on it is remote and the problem is when the link between the last two goes down.

As far as i understand from the comments, you are suggesting that the client is the problem and the client is playing whatever it has in the buffer ? i doubt that, because the stream should not stop at all ... it should play the backup ... right ?

[djSpinnerCee]

"i doubt that, because the stream should not stop at all ... it should play the backup ... right ?"

not exactly...

If I understand you correctly... Your source app is playing MP3s that are remote --- if a connectivity issue occurs here, the source app will "idle" (not send anything) with respect to the DNAS -- at this point, and util the SourceIdleTimeout is reached by the DNAS and the source connection is actually disconnected, will the DNAS send the backup file to the listener -- so the time that a listener's player will have to deal with the DNAS buffer, it's own buffer, and its loop setting could be a lot longer than you expect.

Another misunderstanding: Even though the source is connected to the DNAS, the source app. will only send data to the DNAS when it has something to encode. This is an idle source -- connected to the DNAS (online), but idle -- during this time, the DNAS buffer will not change, so a looping player may just repeat it if it is set to do so.

To find out exactly what's goin' on, pay close attention to the DNAS log while the player is repeating stuff -- if the player is reading the buffer, playing it, then disconnecting and reconnecting to read and play it agsin, you will see these reconnect attempts in the DNAS log -- if the player is looping its cached copy of the buffer, it should be doing this after disconnecting from the DNAS, but it could be waiting for the TCP connection to close.

In any event, check your settings on the player (that's trying to listen) -- to play a stream, it should not be set to loop playlists -- for most players this setting is global, so they don't behave differently when the playlist has only one element. Auto skip also has funny implications for a stream when it does have more than one element (URL) in it -- sometimes it will do what you want, and sometimes it wil not.

Also realize that while you may have a particular issue as a listener with your setup, realize that you have absolutely no control over your listeners' settings -- many broadcasters assume SHOUTcast issues, when the issue lies with the listeners and their particular setup.

[Mayz]

Well, at the moment im not at the site where i have the shoutacast server and listener client, but from previous observations, i belive that the client actually reconnects multiple time and disconnect, and thus the buffer is from the sc_serv, and yes, as you said, its probably that sc_serv is not giving up on the src yet, i have set SourceIdleTimeout to as law as 3 seconds, but it takes much much longer for the backupfile to play and during this time my client (mplayer) keeps repeating the same few seconds, i have a custom script that keeps checking on mplayer every second and starts it if it discoveres that it exited, but it seems that the new instants takes from sc_serv buffer, and thats exactly why i tried to play with sysctl tcp timeout stuff, to make sc_serv convinced that it lost connectivity with the source faster (in less than a second, or in a few seconds).