Changes to Webcast buffering times

[dbaresrc]

Something to consider for buildings with tight schedules and using a single Teradek, just schedule one long meeting for the building for the day. (i.e. 'Stake Center Wards Sacrament Meeting' instead of '1st Ward Sacrament Meeting' followed by '2nd Ward Sacrament Meeting')

The other issue is that it makes it harder for the wards to see who attended their ward online. With separate meetings those stats are split out.

That's how we run our buildings. One long meeting that all wards in the buidling "share." Yes figuring out attendance is more difficult but at the end of the day, I send a copy of all teh names to the EQP (he's handling it rather than a clerk, don't know why) and he figures it out.

[dbaresrc]

I can see the overlap policy being an issue with Terradek buildings but what about those using zoom integration? For example, in a building there is a request to broadcast two events, one from 9:00 to 10:00 the other from 10:15 to 11:15. The 9 to 10 is not an issue. However, scheduling the second event for the building fails because the second events' real start time (with the pre-buffer) is 9:55 which overlaps with the first event.

However what if meeting #1 is scheduled to occur in Bldg_1 while meeting #2 is scheduled to occur in Bldg_2? The webcast system *should* see them as two separate events from two different locations, thus there is no buffer overlap, right? Obviously this assumes there's nothing in the scheduler for Bldg_2.

[bartj]

You can continue to have meetings overlap if desired by assigning a different registered encoder or by selecting encoder type "Other". The overlap issue is specific to events using the same registered encoder. Overlap wasn't as big of an issue when the RTMP information changed for every event, but will be when static RTMP encoder URLs are deployed.

Any event can be extended as soon as the event has started in the portal by clicking "Full Stats" and then clicking "Extend" in the right-hand corner of the screen. The buffer changes provide for 30 minutes between sacrament meetings and an hour between other meetings, which is a common requirement in buildings with multiple meetings.

[russellhltn]

The buffer changes provide for 30 minutes between sacrament meetings and an hour between other meetings, which is a common requirement in buildings with multiple meetings.

Agreed. I guess the question is how common a shorter interval is in other buildings. I'm guessing it might be common at the various BYU campuses, but I'm not sure as it would be common elsewhere.

[shawndowler]

As of yesterday's email, we are switching to using Zoom Webinars for all of our sacrament meetings, so I don't expect to be touching the Webcast much anymore if at all going forward. I feel like maybe there are two factions working in parallel and final decisions haven't been made yet on what's going to happen with general policies.

Are Zoom accounts being used worldwide, or is that only for some regions?

[russellhltn]

so I don't expect to be touching the Webcast much anymore if at all going forward.

I'm not sure if you handle stake conferences, but Zoom's limit of 500 connections is likely to be a deal killer for that. Webcast was originally intended for stake conferences. It will likely continue unless the church can cut a deal with Zoom for a larger webinar limit.

[brad_p]

Ugh, this makes the broadcast system worse for us.

We need that 1 hour early broadcast to find and fix problems. We have yet to have a week without a problem with the church's broadcast system (significant buffering issues, events mysteriously not timed correctly on the church's end, bad certificate errors, and sometimes laptop issues on the chapel end). That hour is very helpful, and sometimes we fix issues with only minutes to spare. 20 minutes is definitely not enough.

We also have only 2 people responsible for starting broadcasts for 7 wards, and sometimes we're both out at buildings helping to fix issues, and so we rely on that extra 15 minute post buffer. It gets tricky for us to be available to click on the extend button.

I've gone in and changed our meetings to start 45 minutes earlier and extended the length of the meetings to 2 hours. That should cover it.

[lajackson]

That should cover it.

Yes, but only until you read yesterday's email (or see this post). Our wards are going to have to step up and designate technical specialists, that I am perfectly willing to train, or they will no longer be webcasting sacrament meetings.

[kaaloa]

For stake conferences, I would like to have an hour pre-buffer and at least 10 minutes post-buffer.

Unless a different stake is sharing the building (and equipment), I'm not sure why such a short post-buffer is being used for stake conference. I know the event can be extended, and at least for stake conference, you're going to have your "A" team in action.

I work in TV production and if there is anything I know, its that things go wrong all the time. Our crew call is 5 hours before Air precisely for the fact that things go wrong and needs to be fixed before air.

With that said, church broadcasts (anything other than general conference and other high level broadcasts) are typically low budget productions put together with mismatched gear. This leads to constant problems on many levels. We just did our stake conference last week which turned out pretty good. Chuck Criddle was our tech and he did a great job making sure our visiting authority (Elder Tim Dyches) had all his tech needs taken care of. At the end of our training meetings the day before, I discussed with Elder Dyches what would be happening the next day and how it would be run. I was up and running an hour before which was my plan, Elder Dyches came on about 20 mins. before, and we started on time and ended about 10 mins late.

That was a good example. My worst event was during one of the first broadcasted regional conferences about 4-5 years ago. In short, the church's server couldn't handle the load of every stake center in the west and it crashed. I didn't know that it crashed so I was literally running in the chapel trying to get it going to no avail. The bad thing was that I connected to the server and was receiving the broadcast prior to start time and then it disconnected which sent me on a wild goose chase. After that day, I wanted an answer why I failed about a thousand people expecting to watch the broadcast portion. Called Salt Lake, kept getting transferred "up the ladder" till I could talk to someone not reading typical responses.

I vowed to never let that experience repeat itself as long as I was the STS and it never has. I just have a few requests.

1. Please make the post buffer around 15 mins. Our sacrament often times goes over 5 mins, but very rarely goes 15 mins.
2. Please allow a smaller scheduling increment. 1 hour increments are very inconvenient especially since we can no longer overlap even the buffer period.

Moku

[kaaloa]

Something to consider for buildings with tight schedules and using a single Teradek, just schedule one long meeting for the building for the day. (i.e. 'Stake Center Wards Sacrament Meeting' instead of '1st Ward Sacrament Meeting' followed by '2nd Ward Sacrament Meeting')

Since the broadcast switches to the Mormon Tabernacle Choir video while the encoder is disconnected, the wards can start/stop the encoder when passing the Sacrament and between meetings, and restart the encoder. Members just need to remember the time their particular ward meets and tune in near that time, and they will see their ward at that time.

Not the most ideal as anyone who forgets their weekly meeting time and just checks the Stake portal will see the single event with a long time window, but it fixes needing two encoders for a single building due to the overlap limits, and allows multiple wards in the same building with tight meeting schedules. Right now our wards are staying under 45 minutes with Sacrament at the end (stake rules currently allow one speaker each Sunday except for testimony meeting), but as restrictions ease I can see the 3 wards sharing the Stake building running closer to overrunning each other relative to broadcast buffer time, and needing to convert the Stake Center to a single long event so that the Wards can still be flexible with end times.

Our wards schedule individual meetings specifically for the stats. I send each bishop screenshots of the connections and they use that for attendance purposes. Having 1 long meeting won't give the individual wards accurate stats.