[fixed] Regular issues "Server connection closed" on Icecast

Christian

New member
Hi Dmitry,

    I regularly, let say once every 2 or 3 days, get disconnected from Icecast server.
I am running 2 radios (2 RB) with respectively 6 streams : 2 mp3 (1 Icecast + 1 Shoutcast), 2 AAC+(1 Icecast + 1 Shoutcast), 1ogg Icecast and finally 1 mp3 to Radionomy servers.

I am getting disconnected from the Icecast server regularly but not from Shoutcast server or much less often.
The two radios are not getting disconnected from the Icecast server at the same time.
RB server and Icecast servers are all guest virtual machines on the same host. Shoutcast server is a separate physical server.

Any idear why this happens ? I am loosing 80% of listeners most of them are on Icecast! and it takes hours to get back to normal
I included screenshot. Server 1,2 and 5 are Icecast, 3, 4 and 6 Shoutcast.

Christian
www.clubbingstation.com
 

Attachments

  • rb.png
    rb.png
    4.5 KB · Views: 981
Well, this may be an Icecast issue, as Shoutcast streams work fine.

Try updating to the latest Icecast version - 2.3.3, it was released recently (http://www.icecast.org/). As their news say, many bugs were fixed in that release, probably disconnect issue will be gone.
 
Hi,

  It just happens again! 7 hours interval.
I am running 2.3.2 Linux I will try but just to mention what is strange is only one RB has the issue. On the other RB all streams remain connected to both shoutcast and the Icecast server. Shoutcast are 1.9.8 Linux with of course different instances but the Icecast server is a single instance and support all streams from both RB and stream on port 80.

Could it be liked to high I/O latency on VM and Virtual CPU running at 70%? I got issue with crossfading for instance. There is a 2 seconds delay between crosfade time triggered on tracktool and effective start of next track ie if I wand a 1.5 second of overlap I have to configure 3.5 seconds of crossfading.
Maybe Shoutcast server are less sensitive to short source disconnection that would eventually occurs during those kind of crossfading issues.


Christian
 
Heavily loaded system can explain the disconnects. If crossfades are triggered with a 2 second delay, it's a very serious problem, and you should work it out first. I'm almost sure it will resolve the disconnect problem.

Also, as Shoutcast works, why don't you use only Shoutcast servers?
 
Hi,

  The main reason is that I can have many stream on port 80. I am still using DNAS 1.9.8 and not 2. They where installed before DNAS 2 was released and compatible with RB.
DNAS are configured not to disconect listeners when source disconect. I configured a backup file <fallback-mount> on Icecast that is suppose to be played when source disconect but for some reason it doesn't work.

I thought of that issue last nignt and I think I now why it is hapening now and not in the past months.
I am playing remix version and no "radio edit" version. In order to get someting nice to listen to I used to manually edit all tracks to remove excessive intro and outro. Usually I remove someting like 30 seconds in intro and 30 seconds outro. For a few weeks now I am using "Track Tool" to set Start, Intro, Outro, Mix and End flags. This is great fast and efficient way of editing tracks, much better that manual editing with Audacity. But I now have more and more tracks with Start point not right at the begining of the file. I think this has an impact on RB and increase the delay. I guess RB need more time loading a track with Start flag at 30 seconds from begining of the file than a file that effectively start right at the begining of the file.
This could maybe explain why I am getting the issue now and not in the past. What do you think?

Christian
 
I think you're right. When large "Start" value for a track is set, the track will be loaded a bit slower compared to a track with Start = 0. This could only be noticeable on a slow or a heavily loaded computer.
This behavior will be improved in the next RadioBOSS 4.7.3 update (it's several days away).

Note, that while loading will be faster there's still a chance for disconnects, just with lower probability...
 
Hi Dmitry,

    I found out what the problem was. I am using SugarSync to get some folders in sync across my production server and my computer at home. It appears that SugarSync has significant memory leak. I allocate 512Mo RAM on RB server and SugarSync raised over 800Mo by itself causing intensive SWAP usage and performance d?gradation.

Christian
 
Christian said:
Hi Dmitry,

    I found out what the problem was. I am using SugarSync to get some folders in sync across my production server and my computer at home. It appears that SugarSync has significant memory leak. I allocate 512Mo RAM on RB server and SugarSync raised over 800Mo by itself causing intensive SWAP usage and performance d?gradation.

Christian
Anyway, there were some optimizations done in RB too, so the tracks will launch faster. Especially it's true for tracks with Start values about 30-60 seconds and more.
The release with those optimizations will be available today.
 
Back
Top