Alright everyone, calm down.
Last weekend there were unexpected license issues that caused some servers to not be able to spin up. Of course since these licenses were for third party software, it took some time for this to be corrected.
craiggsmith wrote:
A few questions:
Why do we provide our contact info if they aren't going to use it to tell us there is a problem?
Why do we even have to specify a server?
Should we set up two events on two different servers just in case? Will it even let us do this?
The reason why contact information is wanted so support can contact the STS if there are problems. However, this has not been utilized very efficiently. We are taking steps to correct this and make it better both for our support engineers and STS. These will be added on our next release this coming month.
Since all this is using the cloud, there are data centers that are used. You specify the server so that you can receive the closest center to your location to minimize any congestion and jumps.
You should definately not set up two events. This would cause 2 servers to spin up, one which would not be used. When a server is spent up, it costs money. Not using a server is wasting the widow's mite.
A server is spun up 4 hours before the start time of the event. The first 2 hours are for support to catch any errors that the servers may have. (As I said before, this weekend there were third party license issues that took time to resolve.) The last 2 hours are for the STS to test there setup and location and correct any issues that are found there.
If you are having trouble troubleshooting, here is what I would do and have done in the past with my stake conferences in my stake.
1. Make sure that the laptops used are up to date and has at the very least 2 cores. Four cores are recommended.
2. Test the upload bandwidth at your broadcasting site. Test again and again. Get a good feel on what your internet upload is. Watch to see if there are any drops in the Internet and take note on how far they dropped. With all that, set your encoder to half of what your top upload speed is. In doing so you will minimize the risk of your Internet bandwidth to drop at the encoding bitrate. NOTE**** If you encoding site goes down or has problems then your receiving sites have no chance and will fail.)
3. Test the download speed at all your receiving sites. If there are sites that have low speed, disable the adaptive piece of the client player and set it to play at a low speed. This will cause to player to play only at that speed.
If you perform these above steps, you will decrease any issues with your events.
TEST, TEST, and TEST again. Know your system inside and out.
Schedule your event well into the future. Give yourself time to troubleshoot and test.
If you schedule your event on the day of the event and haven't tested anything, you are asking for problems. If you schedule an event to start with the next hour, you are short fusing the system. While this does work, it can cause problems.
There are instructions out on the tech system site. I realize they are out of date. We are working on revisions currently. But for the most part, if followed they will help.
If you have questions, ask. Contact me, I'll be glad to help and answer any questions you have about the system, the VidiU, how to read and interpret the graphs, etc. I have posted many tricks, tips, and help on this forum. Search it.
Lastly, do not think that we are not aware of problems that occur or that we don't care what is going on. We are working to make the system simpler, easier to use and more effective. This is only the 2nd year of this system's existence, so there are going to be going pains. Most of us eat our own work, meaning we are using the system for our own events. I am in fact the STS of my stake. I use the very system that I work on.