FMLE Frequent Disconnects - what to adjust?
Greetings. I am new to the wowza server. We have a user who normally uses our Adobe Flash interactive server for live streaming. Their high speed internet for their building is suspect. In testing on our new wowza server, they had frequent disconnects. I had them stream at the same time to the FMIS server, and had only one disconnect all afternoon. They are streaming with the Flash Media live encoder 3.2
I wonder if there is a timeout for disconnects that can be set, or other parameters that can be adjusted?
1) Searching other threads, it was suggested that the "Ping Timeout" in the application.xml file be increased. Is this the best way to reduce disconnects when users have an iffy connection?
I changed the number from 12000 ms to 20000 and we will test again. Is there any potential performance hit for this?
2) Are there other parameters that can be adjusted to improve this and/or reduce disconnects?
Thanks!
I wonder if there is a timeout for disconnects that can be set, or other parameters that can be adjusted?
1) Searching other threads, it was suggested that the "Ping Timeout" in the application.xml file be increased. Is this the best way to reduce disconnects when users have an iffy connection?
I changed the number from 12000 ms to 20000 and we will test again. Is there any potential performance hit for this?
2) Are there other parameters that can be adjusted to improve this and/or reduce disconnects?
Thanks!
What type of client and protocol? Are you using Flash RTMP client? Are you using RTMP or RTMPT? It sounds like you may be using RTMPT, which is more prone to even small network interruptions that do not affect RTMP
Richard
Richard
What type of client and protocol? Are you using Flash RTMP client? Are you using RTMP or RTMPT? It sounds like you may be using RTMPT, which is more prone to even small network interruptions that do not affect RTMP
Richard
So, they were broadcasting with the adobe Flash Media Live encoder version 3.2 , using an rtmp stream, H.264 video, AAC audio codec. The FMS URL for the encoder looks like this:
rtmp://myserverdomain.com:1935/Application_name
We are using the cast control media control panel as a control panel to manage the wowza server, which created the application within wowza using their default live streaming setup. The system is streaming on port 1935, which is also default cast control.
I'm not too familiar with RTMPT, but I think this is standard rtmp. Any insight?
Thanks
What player are you using? And what protocol in the player? If you are using rtmpt, take out the "t", just use rtmp.
Richard
Richard
What player are you using? And what protocol in the player? If you are using rtmpt, take out the "t", just use rtmp.
Richard
Richard,
Our user has pages that follow the rtmp feed, and another that follows the m3u8 version. To duplicate the problem, we created a test page with the JW player 5.7. When it detects a flash player, it uses this code to rout to the rtmp stream:
'provider': 'rtmp',
'streamer': ' rtmp://mydomain.com:1935/CCOBS7',
'file': 'CCOBS7',
When no flash player is detected, it points to the m3u8 version with html5:
type: 'html5',
config: {'file': ' http://mydomain.com:1935/CCOBS7/CCOBS7/playlist.m3u8',
'provider': 'video'
I don't see any rtmpt here. Am I missing something?
When the problem occurs, all three events are seen: a) The encoder client (FMLE 3.2) shows a disconnect and reconnect b) The flash stream stops
c) The apple stream stops.
As a control, we run the same stream out to our other non-wowza server, (with twice the traceroute latency) and have no disconnects. My problem is that the customer will not accept use of the wowza server because it disconnects every 10 minutes and our other server does not.
Now, I LOVE the wowza server so far, as most users have zero issues with it. It just is exhibiting this behavior with a key user. I am hoping we can adjust away this problem.
My experiment mentioned above, where I changed the Ping timeout from 12000 ms to 20000 ms did not improve this issue. Are there other things I can try?
Thanks
Take Wowza out of the picture and/or use network tools to analyze your network.
For example:
1. "ping -t host-ip > pinglog.txt".
2. Install Wowza at the other location. If it works this would point to a network issue along your route which you can investigate.
3. Try lowering the stream bitrate.
Test using the Wowza examples such as /LiveVideoStreaming/client. Publish a stream with FMLE. Click play in client. Stop FMLE. Start the stream in FMLE again. The stream in the Wowza example player should resume automatically.
You want to identify the network issue, since there's not much that can be done if the network stops sending data.
For example:
1. "ping -t host-ip > pinglog.txt".
2. Install Wowza at the other location. If it works this would point to a network issue along your route which you can investigate.
3. Try lowering the stream bitrate.
Test using the Wowza examples such as /LiveVideoStreaming/client. Publish a stream with FMLE. Click play in client. Stop FMLE. Start the stream in FMLE again. The stream in the Wowza example player should resume automatically.
You want to identify the network issue, since there's not much that can be done if the network stops sending data.
Randall,
You are correct that this was a network issue, not wowza. Your coaching was helpful in identifying the problem. Thanks!
You are correct that this was a network issue, not wowza. Your coaching was helpful in identifying the problem. Thanks!
