StickyChanges to Webcast buffering times

As of today (1/26/2021) buffering times are changing and will impact your future webcasts. Please review the attached PDF for more information.

Only a 5 minutes post-buffer. That will keep them from going long. <grin>

Not a problem for us currently, but as things creep back to normal, I can see that happening.

With these changes, I think the scheduled length should be broken into 15-minute increments. This will allow us to schedule more important meetings closer to their expected run time, rather than being stuck to 1-hour increments.

For example, a meeting that is expected to run for 1 hour and 15 minutes or even 1-hour and 30 minutes. Currently, our only option is to schedule it for a 2-hour window. With the previous post-buffers, this wouldn't have been much of an issue.

My other concern is with Stake Conferences. A 5-minute post-buffer creates another thing to be aware of and pay very close attention to. If the meeting was not expected to go over but does, that's 1 more thing to have to manage, when I have several other things I'm already managing, by logging into the Webcast dashboard and extending the meeting. That seems to be a bit of a poor decision since I now need to schedule the meeting for a 2-hour window, rather than the usual 1-hour with the 30-minute post-buffer, just because I need an extra 10-15 minutes.

I agree with the idea that the meeting scheduled time should be broken down to 15 minute increments as well. Most every meeting scheduled in our stake has been extended to 75 to 90 minutes because of late starts and long talkers. As it stands we are okay without any overlaps and I think the shorter buffer times will actually help in the long run. It would be nice if it showed the buffer times on the scheduled event maybe in red or something.

There is another problem that we have run into a couple of times and once during our last Stake Conference. The server that was building for the meeting crashed or locked up after it started building and locked up the teradek so that we could not reschedule a new meeting and get it going on time even though we had plenty of time to do so because we were not allowed to end the meeting or disconnect the teradek from the stalled meeting until the time for the meeting was over. We should be allowed to end any meeting any time we want especially in this situation. Just put in 2 or 3 verification windows to be sure it isn't a mistake. Have you ever tried to tell your Stake President just before an all online meeting that he can't have Stake Conference today? It is not a good thing. We finally ran to another building and borrowed their teradek, registered it and scheduled a test meeting as a Backup Stake conference and got started about 15 minutes late and because of that we lost over half of those that tried to log in and couldn't go to the meeting.

nesnahjm wrote:The server that was building for the meeting crashed or locked up after it started building and locked up the teradek so that we could not reschedule a new meeting and get it going on time even though we had plenty of time to do so because we were not allowed to end the meeting or disconnect the teradek from the stalled meeting until the time for the meeting was over.

Unless I'm missing something, I'd think you should be able to reconfigure the Teradek for manually inputting the link and get around the automatic system being locked up.

But I can understand how in the heat of the moment that solution could be overlooked.

In case it helps anyone, I just sent the following message to all of the bishops in our stake...

Bishops,

We received word today that the Church webcasting system has been updated and one of the changes has a direct impact to the Sacrament meeting webcasts in your wards.

The buffer time before and after the event has been dramatically reduced:

• The pre-buffer time (before the meeting) will now be 20 minutes (was 60 minutes)
  The post-buffer time (after the meeting) will now be 5 minutes (was 10 minutes)

Please forward this information to the individuals in your wards who are responsible for the webcasting each week so they are aware.

The biggest thing for you to note is that your webcast will be cut off 5 minutes after your scheduled ending time. If your ward administers the Sacrament at the end of your meeting, this is unlikely be much of a problem for you. However, if your meeting has talks, song and prayer right up to the ending time, there is a greater chance of cutting off the end of the meeting for your remote viewers.

We are only able to schedule events in 1 hour increments, so increasing your event to two hours would be expensive for the Church (the computing resources involved in webcasting are billed by the time in use).

What are your options?

1. Please do all you can to ensure your meetings end on time.

2. If your Sacrament is done first in your meeting, I can schedule your event to start 15 minutes later, which will give you additional time after your meeting's normal ending time.

If you have questions or concerns about this change, please feel free to reach out to me and we can see how we can help you.

I understand why they did it, but I now have two new problems. I have to delete and reschedule every meeting for this coming Sunday. And my typical Sabbath Day just went to ... well, I won't say it here.

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

For sacrament meetings, I have not yet been able to map out a schedule that will work without a ton of manual intervention every week. I do not believe my going in position should be to tell the stake presidency that they need to reschedule every sacrament meeting in our stake.

lajackson wrote: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.

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.

jmalyn wrote: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.

jonesrk wrote:

jmalyn wrote: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.

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.

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.

bartj wrote: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.

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?

shawndowler wrote: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.

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.

bradpeterson@gmail.com wrote: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.

russellhltn wrote:

lajackson wrote: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

jmalyn wrote: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.

russellhltn wrote:

shawndowler wrote: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.

I have to agree with you on this. Our stake conference last week had about 550 connections. To me, if we had used zoom and reached the 500 connection limit, then that meant that everyone who tried to connect after that 500th connection couldn't. That would have been the last time I used zoom for stake conference. That is simple unacceptable.

(While I'm setting up for today...)

Ward A - Sacrament First, OBS on a laptop. I'd scheduled the webcast for 9:15, so if we run long (8-9) there's 15 minutes built-in that I don't have to fret over. 2nd ward in the same building is doing zoom instead, so no scheduling conflict. This building is not a stake center and doesn't have a teradeck. It still takes about 20~30 minutes to re-run cables and boot up PC/apps, but if I stick to the known sequence it's pretty consistent.

Stake center events - Teradeck and Camera management still leaves a lot to be desired, so this leaves a fair amount of pre-prep. There's always additional anomolies, but this can probably be dealt with by putting a test event right before the conference.

Nearly all of our wards are using Zoom instead (decided on their own), so we're not immediately impacted, and there's a scheduled gap of an hour between wards already.

Con los cambios que ha tenido, no me permite programar una reunion sacramental, me da error aparentemente por la ubicacion actual, y solo tengo opciones de USA, que debo hacer en este caso podrian ayuderme por favor

jonesrk wrote:

jmalyn wrote: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.

We also do one long broadcast for all 3 wards via a Mevo camera (45 min in between the start of the sacrament and the next meeting.) We have members enter their name when viewing as: WARD - LAST NAME - TOTAL VIEWERS (i.e. A3 - Smith - 5) . Then when we view the broadcast site stats, it is much easier to count each ward's viewers (vs connections). Obviously there are those who don't follow this format, but they are few.

lajackson wrote:

bradpeterson@gmail.com wrote: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.

Ya, it's going to cause problems with certain Teredek situations. Fortunately, we're going to be ok. I don't want to sound cynical, but we've found the more we avoid the church's process, the safer we are.

For us, we're set with our hardware. We use a a camcorder, HDMI to USB converter, OBS on a laptop, various mics, YouTube, and FreeConferenceCall (for 10 digit phone call ins). We don't use Zoom because it's not really designed as a video/audio mixer for webcasts like OBS is. We use MyWebCast is a backup only because of constant problems. We don't use Teredeks because our regional FM office won't let us buy any.

For each ward an assistant just needs to know how to move a camera around and click on pre-set OBS feeds. We take care of the rest.

PLEASE, PLEASE,PLEASE, UNDO THIS CHANGE!!!!!!!!!!!!
HQ shot us in the foot with this change.
I appreciate your efforts to make our lives simpler by trying to institute Static RTMP. But really, the dynamic RTMP used before was not an issue. The user just clicked on the first meeting in the active queue.
This change has made our lives much harder, our options less flexible, and has guaranteed that the church will pay MORE for server time because you have made it impractical to terminate a server between meetings and spin up a new one for the next meeting. Provisioned Server cost is the same whether broadcasting or not.

Your explanatory PDF says:
"ACTION REQUIRED: This change is in advance of the release of the static RTMP update. Static
RTMP cannot support overlapping events."

1. I would rather have overlapping events , as before, than to have Static RTMP addresses.
2. In an attempt to same RTMP server cost, you have encouraged one LONG event with much wasted time between meetings, which will increase the server expense.
3. Shortened pre-post buffers translates to artificially starting server too early and running it too later to allow for testing, possible meeting over-runs, and post meeting testing in cases where there were difficulties.
4. We previously had no problem terminating a server five or ten minutes after a meeting if the remainder of streaming and post buffer was not needed. Now, we are forced to an artificially long "Uni-Brow" meeting, costing the church more money and preventing the ability to tailor server "up-times" to fit our needs.

Why not just let us control the scheduled buffer times?

I got an "Action Required" email letting me know that two of my meetings have overlapping times. A ward sacrament that runs from 1pm to 2pm (so including the buffer, looking at 12:40pm to 2:05pm) and a "combined ward conference 2nd hour" that is set to run from 2:30pm to 3:30pm (which because this one falls into the "Other" category it is given a 45 minute pre-buffer, which makes the total run time scheduled to be 1:45pm to 3:05).

To resolve the issue, I just changed the second meetings "broadcast type" to "ward sacrament" since that only has a 20 minute prebuffer, which lets me keep the posted meeting times so as not to confuse any of our less than technically savvy members viewing from home who would otherwise be confused by not entirely accurate stream runtimes or by multiple events being smashed into one and thus having to have a confusing stream title (the ward sacrament meeting is a Spanish branch, their stream title is in Spanish).

With this new deployment, will weekly recurring meetings now retain the same Event Code as well? Or will they continue to change week to week? If so, are there plans to make these static on a recurring basis? Having to communicate different codes to the congregation weekly just adds confusion for our members.

Thanks

Help we are using the Mevo camera system and all has been going perfect for 3 months. Now with these changes ads I tried to schedule my meetings the system said my meetings were overlapping even if they are in different buildings.
I can schedule each building to avoid conflicts but why does the system not differentiate between buildings. My email is pitchkev@gmail.com if anyone has a solution.

pitchkev wrote:the system said my meetings were overlapping even if they are in different buildings.

What the system is concerned about is overlapping schedules for encoders. Make sure your events are not using the same encoder.

I see the spot in scheduling to add an encoder but i dont know how to change my encoder.

pitchkev wrote:I see the spot in scheduling to add an encoder but i dont know how to change my encoder.

In the scheduling, you can select the encoder (encoder URL). In the main page, in the upper right corner, there's a "Encoder URLs" button that allows you to set up encoders.

However, I don't know if that works with the Mevo. The main thing is to make sure the scheduled events are not selecting the same "named" encoder.

For some reason, I'm only seeing "default" selection - not anything that is clearly labeled as "none".

You might try creating a dummy encoder so you have encoder selection options.

I was able to create separate URL's for each ward and the conflicts are gone.

kaaloa wrote:

russellhltn wrote:

shawndowler wrote: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.

I have to agree with you on this. Our stake conference last week had about 550 connections. To me, if we had used zoom and reached the 500 connection limit, then that meant that everyone who tried to connect after that 500th connection couldn't. That would have been the last time I used zoom for stake conference. That is simple unacceptable.

We did our last Stake Conference with Zoom webinar and had it streaming to the church webcast service. We had a visiting general authority and it worked well.
This allowed us to have those needing Spanish translation to be on zoom webinar and select the second audio channel for Spanish, while those not needing Spanish connected to the church webcast service. We had 685 connections on the church webcast service.
This worked really well. only thing I didn't care for was that the zoom to church webcast connection puts the zoom logo in the bottom right of the screen, but that is tolerable .

With the new updates I've now noticed that when I create a shortcut on members android phones from the URL below it creates a default shortcut to a default URL. It gives an error of "Were sorry that URL is not recognized" and asks for event code and you cannot go anywhere else. Previously I could navigate to this URL:

http://mywebcast.churchofjesuschrist.or ... bertastake

I could then add a shortcut to the android desktop and it would keep this url, this takes them to the recuring list of events in their stake and they simply select the ward they want to watch. Could this be fixed?

P.S. the URL is still active and works you just have to get there via a more lengthy process.

Apple iOS is the same.

A word of warning. I thought we had a 15 minute post roll with stake conference. The Church webcast system cut us off around seven minutes today, right in the middle of one of the finest closing prayers I have heard at a stake conference in years. My phone lit up from quite a number of the nearly 800 members who were still connected.
Granted, it was my fault that I was so busy trying to manage the Zoom webinar that I forgot to extend the webcast time. But hey, even sacrament meetings get a 10 minute post roll. [Edit for future reference: it is 5 minutes not 10.]

Lesson learned: Extend the meeting so that it ends within the regular broadcast time. Do not count on any promised extra minutes.

lajackson wrote:A word of warning. I thought we had a 15 minute post roll with stake conference. The Church webcast system cut us off around seven minutes today, right in the middle of one of the finest closing prayers I have heard at a stake conference in years. My phone lit up from quite a number of the nearly 800 members who were still connected.

At least it didn't end right after "we'll now turn the time over to Elder ____ for some closing remarks."

lajackson wrote:A word of warning. I thought we had a 15 minute post roll with stake conference. The Church webcast system cut us off around seven minutes today

Same thing happened to us a couple of weeks ago with one of our stake conference sessions. In our case the meeting had just ended, about seven minutes after the scheduled end time. I was just about stop streaming in OBS, when it got cut off from the server side.

lajackson wrote:A word of warning. I thought we had a 15 minute post roll with stake conference.

And I thought wrong. I was going through some notes this morning, The post roll is five (5) minutes for both stake conferences and sacrament meeting. I have not been able to find the original notice (it is here at the Forum somewhere). The only difference is the pre-roll times.

Live Event Buffer Times:
Sacrament 20 min pre and 5 min post
Stake Conf 45 min pre and 5 min post

So the moral of the story is:
Check your notes more often or otherwise find out for certain.
If you are not singing at 5 til the end, you had better extend.

lajackson wrote:I have not been able to find the original notice (it is here at the Forum somewhere).

It's an attachment to the first post in this thread.

I'd like to preface my complaint with that I know there is documentation and notifications regarding the changes to the pre-post event buffers.

Yesterday I ran a live stream for a funeral service. I set up the event with 30 minutes lead time before the actual event start time of 11am. I set it for 1 hour completely forgetting that all post-event buffers were shortened for all meetings. I ended up losing track of time until OBS Studio displayed a disconnect error and by then it was too late to add any time to the event.

There used to be a pre/post event buffer timeline displayed during event setup. I feel with the variable buffer times the pre/post buffer timeline should be brought back or the times should be displayed during the event setup.

Having to rely on a PDF for such important variable information is, IMO, poor design, especially considering this information used to be displayed during event setup.

Jacobdaviddean wrote: I'd like to preface my complaint with that I know there is documentation and notifications regarding the changes to the pre-post event buffers.

And it is really hard to find, although I know there is a post with a pdf attachment with the information somewhere here at the Forum. (Or I could read back two posts and know exactly where to find it. I always read back two posts in every thread before I post -- haha).

I think the times used to be at the Webcast Portal under the Successful Webcast Checklist link. That page no longer works (404 error).

For convenience, from my own notes without any guarantee at all:

Sacrament Meeting: 20 min pre-buffer / 5 min post buffer
Stake Conference: 45 min pre-buffer / 5 min post buffer

(I think the stake conference post buffer ought to be at least twice as long, but who am I to say about these things.)