How to do network auto-recovery from Expression Encoder 4?

If you use Expression Encoder 4 for live smooth streaming, you probably have already hit this situation a few times. Say you’ve set up your live encoder to push to a remote publishing point on an IIS Media server and everything is running fine. All of a sudden, somehow the network connection between your encoding facility and the remote IIS ingest servers gets broken. Because today Expression Encoder 4 does not support network auto-recovery, even if the network gets back to normal, Expression Encoder will still show the error message while the remote publishing point keeps waiting for failover streams. The end result is that the live streaming has to stop. And the only way to fix that problem would be to restart everything (encoders, servers and clients) which also means the clients would lose access to all the DVR data that belongs to the previous session.

Ok, so how do we fix this? Of course the obvious solution would be to enable network auto-recovery feature in future Expression Encoder releases. But before that happens, there is actually a simple workaround that you can try today. All it takes is to insert another IIS server into the picture. If you had a chance to read one of my previous blogs here, you probably already know that live smooth streaming publishing point can be configured to push to other publishing points downstream (see the “Push Output” section). While doing that, it is also capable of handling network conditions with auto-reconnect which is what you would want between your encoder box and the remote IIS server in this case.

The diagram below shows how this solution works. First you install and configure another local IIS Media server that’s either on the same machine as the encoder or in the same LAN (so that the connection between the encoder and this IIS box should never be an issue). Then you configure the local IIS server to push to your remote IIS servers. IIS Media server’s publishing point supports simultaneously pushing to multiple remote publishing points (and do auto-recovery for each of them) so you could optionally have a primary and backup remote server for load balance for failover (as the diagram shows below). Now with this setup, if anything happens with your WAN that’s connecting your encoding facility and the remote IIS servers, the local IIS server can handle all the network auto-recovery for you.




Here is how you can set it up:

1. Install IIS Media Services and Expression Encoder 4 on the same machine or co-located two machines in the same LAN.

2. On your local IIS Media server, create a “push” publishing point which in turn pushes to your remote publishing points. The example below shows how to let it push to two publishing points. Enable the “Start publishing point automatically …..” option to let it auto-start. In most cases, you probably don’t need this server to do any archiving or serving any client requests, so you could disable those two options and never need to worry about whether you have enough disk space for archiving/DVR buffer.




3. In your Expression Encoder, configure the live session to push to the local IIS publishing point. You could just use “localhost” as the machine name if the publishing point runs on the same machine.

4. Once you start the live encoding, the local publishing point will automatically get started which in turn relays the streams to the remote publishing points. You should be good to go!

By using a local IIS server, if you’re running IIS Media Services 4, you also get the additional benefit of being able to view detailed fragment information right on the publishing point UI. Plus it also shows the connection detail for your remote publishing points. See my blog here for details.


  • Hi, nice article. I have a setup just like this, but I still frequently have a problem. My remote IIS servers pull a connection from a local server at the site where the encoding occurs. During streaming all works well. However, when I end the encoding session, I reset the publishing points on both the local and remote server to begin a new streaming session later. The publishing point on the local server resets fine, and goes into an idle state awaiting the encoder to start a new session. The remote server however almost immediately goes into an error state. It is as if does not understand that the local server is a waiting state and attempts to stream. When a live stream begins at the encoder, the local server functions properly, but the remote server remains in an error state. No matter what I have tried, there is no way I can find to hold the remote server's publishing point in a idle or starting status, it always, usually within a few seconds, changes to an error status. My current solution is to manually restart the publishing point at the start of each new encoding session. But this is a real annoyance.

  • Do you have auto start enabled on the remote pull publishing point? If that's the case, the problem might be that there are still clients requesting from the remote publishing point after the reset. Because it's configured as auto-start, it would immediately try to start after a successful reset. However because your local publishing point is not streaming at that time, the auto-start will fail. In this setup, you can probably use push from your local publishing point to remote publishing point to have a streamlined workflow.

  • Windows server 2008 r2

    Expression Encoder pro 4

    I want to know that , can i control isml file from expression encoder pro 4 using expression encoder pro SDK. I am not interested in the isml file configuration . Any help in this regard is highly appreciated.

    Thanks in advance.

  • Hi,
    Installing IIS Media Services and Expression Encoder 4 on the same machine,
    It's basically putting an ingest server into the same box with the encoder (EE4). Does an ingest server (turn off archiving & accept client request) would be a burden that much to this box? Or is it advisable to have a different lower end machine just acting as an ingest server?

    Secondly, how do you configure the ingest server to accept/sync two incoming encoders (primary & secondary encoder)?


  • The ingest server uses very little system resources. It's better to have the ingest server on the same box so that it uses localhost loopback to receive the encoder stream which removes any possibility of network failure between the two.

    It's the encoders' responsibility to synchronize the timestamp generation between the two encoder instances. Expression Encoder does not support this. Most of the hardware based encoders that support smooth streaming have this functionality. The ingest server by default can handle multiple encoder streams for failover/redundancy as long as the encoders support it.

  • If there is a network failure between the local IIS and a remote IIS while live streaming will the data that was streamed during the network failure be transmitted once the network is restored?

Comments have been disabled for this content.