Skip navigation
Currently Being Moderated

Getting lots of "NetStream.Play.InsufficientBW" when there's plenty of Bandwidth

Feb 8, 2010 12:29 AM

Hi All,

 

We've upgraded our production servers to 3.5.3 on Windows 2008, and now I'm seeing a lot of "NetStream.Play.InsufficientBW" statuses in our client app's log.  The server is streaming a very low bandwidth live video/audio stream, and the client has more than plenty of bandwidth to play it.  The stream doesn't exhibit any audio drops or skipped frames, and there are no message drops on the server side.  We have had clients complaining of random disconnects.  Does anyone know why I might be getting this message?  If anyone from Adobe could help with this, I'd greatly appreciate it.  Thank you.

 

Best,

-Costin

 
Replies
  • Currently Being Moderated
    Feb 8, 2010 2:15 AM   in reply to twelfth312

    Hi,

    Check whether your server is loaded so much and not able to send the data to the clients at the right rate. This can also lead to "Netstream.Play.InsufficientBW" message at the client side.

     

    Regards,

    Janaki L

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2010 2:31 AM   in reply to twelfth312

    We had experience the same think.

    Server was dedicated, 1 client , 350 kpbs stream and still the insufficientBW spam on client side.

    ns.bufferTime = 3; solved that.

    Ok we used 3 sec for a live recorded stream. If you are going with a live stream perhaps you need much less.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2010 9:39 AM   in reply to twelfth312

    There's a known issue in FMS 3.5.3 that we're investigating that causes this.  For now you can work around the issue by disabling FMS Live Message Queueing until the patch released.  You can do so in your Application.xml - change the following config setting

     

    Application/StreamManager/Live/Queue

     

    change the enabled setting to "false"

     

    Note that this workaround will increase your CPU usage somewhat, but restore proper buffering operations.  As mentioned before, we're aware of the issue and working on a fix right now.

     

    Asa

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2010 10:00 AM   in reply to twelfth312

    Hmm, that workaround is pretty definitive to the issue I"m speaking of, so perhaps it's different.  I've got to get on top of that one for the time being, as it's an issue we need me to resolve right away.  So, I can offer to come back to this with you shortly to resolve, or try and guide you through some steps to confirm over the next few days.  LMK what's preferred?

     

    Asa

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2010 7:49 PM   in reply to twelfth312

    For frequent disconnect... Can you look up your access.log file for the status code that it has logged for those disconnected clients? To do so, you can go to $Root\Flash Media Server\logs\access.log. Search for the 'disconnect' events and its corresponding 'x-status' field. This can give us more hint to dig in theis issue.

     

    Regards,

    Janaki L

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 11, 2010 10:37 PM   in reply to twelfth312

    Hi,

    I looked at the status codes which you have mentioned. Thanks for the detailed information on the platforms in which you were running.

    Could you provide us some more information to debug this issue at our end?

    1. How much is the server loaded?

    2. Can you reproduce this consistently?

    3. What kind of stream those clients were playing. flv, mp4 or raw? on what bitrates?

    4. Can you share your application which we can try in our local server?

     

    Regards,

    Janaki L

    (Adobe Systems Inc)

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points