Announcement

Collapse
No announcement yet.

Disconnection/Looping issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disconnection/Looping issues

    Okay, this is really driving me around the bend.

    I run a limited number of Shoutcast streams off of a dedicated box hosted by fdcservers.net. 65 56ks and 50 24ks.

    Every so often (and it's been happening a lot, tonight) the 56k, which is picking up a relay from another box, will lose its connection and got into a loop. Trying to reconnect to it fails. I have to kill the process and restart the server, every single time.

    I run the 24k relay transcoder off my own machine to transcode 56k into 24k, and I am using the latest DSP plugin. This, also, will disconnect and refuse to reconnect, with the listeners hearing a short loop of whatever was playing when it disconnected. Again, I have to go into the shell, completely kill, then restart the server.

    Anyone else ever have a problem like this?

    Mother Earth

  • #2
    Guess most obvious question first - what do the server log files say, if anything?
    Megarock Radio - St. Louis Since 1998!
    Don't click this link!
    Corporate Radio Sucks! No suits, all rock!

    Comment


    • #3
      Just that it lost connection, in fact, in some cases, it behaves as though it still DOES have connection, but it's stuck in an endless loop.

      This has only been a problem within the last two weeks or so.

      Mother Earth

      Comment


      • #4
        1. Have you tried going to the admin panel, kicking the connection and attempting to reconnect the stream?

        2. Have you done traceroutes and sustained ping tests to see if there is any connection related issues or loss of connection to anything else on the server?

        3. Are listeners lost from the server at the same time?
        Megarock Radio - St. Louis Since 1998!
        Don't click this link!
        Corporate Radio Sucks! No suits, all rock!

        Comment


        • #5
          Originally posted by MegaRock
          1. Have you tried going to the admin panel, kicking the connection and attempting to reconnect the stream?


          Yes we've tried this, nothing short of a complete kill and restart will work.

          2. Have you done traceroutes and sustained ping tests to see if there is any connection related issues or loss of connection to anything else on the server?
          Yes we have and no there aren't any apparent problems.

          3. Are listeners lost from the server at the same time?
          It's hard to tell if they're lost or if they sign off because of the looping. I've gotten mixed results in the log; people disconnecting, people being disconnected, people trying to connect and not being able to.

          Mother Earth

          Comment


          • #6
            Might want to upload a new copy of the executable and fully reboot the server to see if that clears it up. If not, then you might also want to look at the actual servers system messages file to see if the box itself is catching any errors.

            Definately sounds like it's freezing up though, but I havent picked up on anything yet that is giving me any idea of where.
            Megarock Radio - St. Louis Since 1998!
            Don't click this link!
            Corporate Radio Sucks! No suits, all rock!

            Comment


            • #7
              Alright, I've tried that. I'll let you know what happens.

              Comment


              • #8
                I got the same issue... I host a relay server and when/if the shoutcast server looses its source it sort of goes into an endless loop.

                The log looks like this when a client listens to the looped stream.

                <08/13/[email protected]:04:01> [dest: 192.168.0.100] connection closed (32 seconds) (UID: 3913)[L: 0]{Bytes: 256000}(P: 0)
                <08/13/[email protected]:04:12> [dest: 192.168.0.100] starting stream (UID: 3914)[L: 1]{A: RMA/1.0.(compatible;.RealMedia)}(P: 0)
                <08/13/[email protected]:04:12> [dest: 192.168.0.100] connection closed (0 seconds) (UID: 3914)[L: 0]{Bytes: 12852}(P: 0)
                <08/13/[email protected]:04:12> [dest: 192.168.0.100] starting stream (UID: 3915)[L: 1]{A: RMA/1.0 (compatible; RealMedia)}(P: 0)
                <08/13/[email protected]:04:44> [dest: 192.168.0.100] connection closed (32 seconds) (UID: 3915)[L: 0]{Bytes: 256000}(P: 0)
                <08/13/[email protected]:04:53> [dest: 192.168.0.100] starting stream (UID: 3917)[L: 1]{A: RMA/1.0.(compatible;.RealMedia)}(P: 0)
                <08/13/[email protected]:04:53> [dest: 192.168.0.100] connection closed (0 seconds) (UID: 3917)[L: 0]{Bytes: 12852}(P: 0)
                <08/13/[email protected]:04:53> [dest: 192.168.0.100] starting stream (UID: 3918)[L: 1]{A: RMA/1.0 (compatible; RealMedia)}(P: 0)
                <08/13/[email protected]:05:25> [dest: 192.168.0.100] connection closed (32 seconds) (UID: 3918)[L: 0]{Bytes: 256000}(P: 0)
                <08/13/[email protected]:05:34> [dest: 192.168.0.100] starting stream (UID: 3919)[L: 1]{A: RMA/1.0.(compatible;.RealMedia)}(P: 0)
                <08/13/[email protected]:05:34> [dest: 192.168.0.100] connection closed (0 seconds) (UID: 3919)[L: 0]{Bytes: 12852}(P: 0)
                <08/13/[email protected]:05:34> [dest: 192.168.0.100] starting stream (UID: 3920)[L: 1]{A: RMA/1.0 (compatible; RealMedia)}(P: 0)
                <08/13/[email protected]:06:06> [dest: 192.168.0.100] connection closed (33 seconds) (UID: 3920)[L: 0]{Bytes: 256000}(P: 0)
                <08/13/[email protected]:06:14> [dest: 192.168.0.100] starting stream (UID: 3921)[L: 1]{A: RMA/1.0.(compatible;.RealMedia)}(P: 0)
                <08/13/[email protected]:06:14> [dest: 192.168.0.100] connection closed (0 seconds) (UID: 3921)[L: 0]{Bytes: 12852}(P: 0)
                <08/13/[email protected]:06:15> [dest: 192.168.0.100] starting stream (UID: 3922)[L: 1]{A: RMA/1.0 (compatible; RealMedia)}(P: 0)

                I use v1.9.8 on a Debian GNU/Linux server. I can assure you that there are no bandwidth issues.

                As described above, the only solution is to start and stop the service (I usually reboot the computer since it requires less commands in the console )

                It simply seems that the shoutcast server is not realizing that the source is missing and only plays what is in the buffer - with no attempts to renew the connection.

                I have no idea how to solve it. Any ideas?

                Comment


                • #9
                  I have the same problem (or at least the same symptoms). But I don't have realy server. In my case WinAmp can not connect to the server, but everybody else can, just to listen a short loop (probably what's left in the buffer).

                  And of course, when this happens, both computers act normal, no system errors, no network problems, etc.

                  Mine is Version 1.9.8/win32.

                  Comment


                  • #10
                    I solved it by installing icecast2 instead.

                    Comment


                    • #11
                      Originally posted by oscargunnarsson
                      I solved it by installing icecast2 instead.
                      Yeah, and the best cure from headache is decapitation. It's always easy to just quit.

                      Comment

                      Working...
                      X