Hi,
after our CDN packed up (SimpleCDN) we decided to go for a dedicated server and host our livestream on there.
However neither me nor my friend, who owns the server, know much about Wowza media servers (except for the fact that our previous stream was hosted on one).
So we set up the livestream as per the guidelines found here https://www.wowza.com/docs/how-to-set-up-live-streaming-using-an-rtmp-based-encoder and all seemed to be working fine.
BTW I’m pushing from FMLE 3.1 and we have Wowza Flash Media Server 2.1.2 installed.
The specs for the server are:
IBM Blade
Intel Xeon 2.33GHz
2GB DDR
Win Server 2008
70GB HDD
The problem we are facing now is that the livestream is delayed immensely!
Sometimes by up to ten minutes whereas our old server would give us delays of max 15 seconds.
I know there are settings on the player side which can be changed but I tried two different players and both gave me the delayed result.
For some odd reason we noticed that it doesn’t drop any frames but just buffers everything. It’s like the server is having difficulties capturing the stream from the encoder and wants to make sure it grabs everything.
On FMLE I’ve been getting these funny notifications for which I couldn’t find an explanation:
Fri Dec 17 2010 13:33:15 : Primary - More than 50 % of the specified threshold values (Max buffer size 512000 KB or Max buffer duration 3600 sec) of RTMP buffer reached. Current network conditions are unfavorable to publish data at the specified bitrate. RTMP buffer will be flushed and streams will be re-published when the threshold value is reached.
Fri Dec 17 2010 15:32:06 : Primary - More than 70 % of the specified threshold values (Max buffer size 512000 KB or Max buffer duration 3600 sec) of RTMP buffer reached. Current network conditions are unfavorable to publish data at the specified bitrate. RTMP buffer will be flushed and streams will be re-published when the threshold value is reached.
Fri Dec 17 2010 17:11:26 : Primary - More than 90 % of the specified threshold values (Max buffer size 512000 KB or Max buffer duration 3600 sec) of RTMP buffer reached. Current network conditions are unfavorable to publish data at the specified bitrate. RTMP buffer will be flushed and streams will be re-published when the threshold value is reached.
Fri Dec 17 2010 18:00:46 : Primary - RTMP buffer exceeded the specified threshold values (Max buffer size 512000 KB or Max buffer duration 3600 sec). Flushing the RTMP buffer and re-publishing the streams.
Fri Dec 17 2010 18:00:51 : Primary - Network Status: NetConnection.Connect.Closed status
Our server is running on a 100mbit line and we’ve been notified that our max strain on there was 30mbit.
If anyone knows what the problem is can you please help us out!!
Thanks
It looks like FMLE has problems with the uplink, from what I see in the FMLE logs you show. That is probably the problem, not enough up bandwidth where the encoder is connected.
100mbs network access is not much. Check the Wowza partners page:
http://wowza.com/partners.html
Richard
I would suggest a new full explanation of your issue.
Richard
Thanks for the update. Take a look at the Wowza partners page.
https://www.wowza.com/partners.html
Richard
Several of those listed partners provide hosting of that type, and are prepared for customers who will be streaming.
Richard
I’m getting the same exact issue running 2 live streams in one night. We were able to do this on our old server, and on the new one (which is MUCH more powerful) we are having bad audio/video synch and the abovementioned “threshhold” issue.
On one livestream, the audio/video goes out of synch approx 1 1/2 hours into the event.
On the second livestream, we received the threshold errors at 50%, 70% and 90%, then FMLE had problems publishing.
We have been using Wowza since 2008, and using FMLE with our issues for the most part all of that time.
The major change in the production chain has been the server upgrade, details below…
any suggestions?
Server: Dedicated
Processor: Intel Xeon E5520 Nehalem 2.26GHz
Port Speed: 100 Gb Uplink
8 Gbs of RAM
1Mb uplink onsite for internet
thanks, Richard. I actually did get an answer, which I am posting here, and then I will be posting a new question asking for recommendations. 
It turns out that the dedicated server does not have the network capabilities to handle live streaming. It may be an issue on the server itself, or the hosting provider.
So that was most likely why we were receiving the continued FMLE error messages about “threshold errors at 50%, 70% etc.”
off to ask for a recommendation about a good dedicated server provider.
I did, but my boss prefers a dedicated server, not a third-party CDN. Any suggestions on a server hosting company so we can run our own version of Wowza that we paid for?
If you have a look in your content/ folder while you are streaming to the server do you see any files created ?
Shamrock
it sounds more like the location of the dedicated server, or its capacity to the Internet, not the capacity into the local provider may be an issue.
The delay is more curious as 10 minutes is not buffered on the server so it sounds like it is writing a file or something else that clients are picking up.
One thing to try, and this has worked recently for an installation I did which had a similar, although not exactly the same issue and solved it (why I am still at a loss to explain).
The Application.xml in the conf/ folder change the StreamType from default to live
This may help the delay issue, but not the bandwidth issue.
Shamrock
Hi,
we were using the same line for the previous CDN. Our uplink is 1mbps and we are only using half of that for the livestream (504kbps) so I fail to see the problem from the uplinking side.
From monitoring we’ve found out, and I’ve mentioned this before I believe?, that we didn’t peak above 30mbps so 100mbps line should be enough for us.
I might try to downgrade the livestream and see if that will affect the stream in anyway.
Thanks
No new files are being created in the contents folder.
I find it peculiar that on VLC it stutters immenseley and the audio is heavily distorted (due to buffering probably?).
Could it be that we only have one server and as such it cannot maintain the load?
We’ve already changed this setting initially as per the settings on the instructions page.
I’m very much inclined into suspecting the capacity problems. Especially as from the encoding side nothing has changed nor from the player itself.
Logics would simply point me to the server in this case.
It needs more researching