A Sunday Tech Survival Guide article

There is a particular sort of optimism that flourishes on Sunday mornings.

Someone has found the perfect illustration video for the sermon.  It has been dropped into the presentation, it played beautifully when tested at home, and the presentation computer is connected to the internet.  What could possibly go wrong?

Quite a lot, actually.

For simplicity, I’ll use PowerPoint here as shorthand for whatever presentation system your church uses.  The same basic issue can arise with PowerPoint, ProPresenter, Google Slides, browser-based presentation tools, or anything else that mixes locally stored material with content fetched from the internet.

The important question isn’t simply, “Is the video in the presentation?”

It is: where is the video actually coming from when somebody presses Play?

Local isn’t the same as linked

Putting video into a presentation is generally good practice.  It keeps your service material together and makes life much easier for whoever is operating the slides.

But there is an important difference between a video file stored locally on the presentation computer and a presentation that launches or retrieves a cloud-hosted video when you need it.

With a local file, the presentation computer already has everything it needs.  Press Play, and the video comes from its own storage.

With cloud-hosted video, the computer must reach out across the internet, find the content, start downloading it, buffer enough to begin playback, and then keep retrieving data fast enough for the video to continue smoothly.

Meanwhile, another computer (or, heaven help us, the same computer) may already be using that same internet connection to send your livestream out to viewers.

That is where things can become … interesting.

Broadband goes both ways

Most broadband plans have limits in both directions.

A plan described as 500/100 Mbps, for example, generally means up to about 500 Mbps downstream – data coming from the internet to you – and 100 Mbps upstream – data going from you to the internet.

Watching cloud-hosted video mostly needs downstream capacity.

Livestreaming mostly needs upstream capacity.

They are not necessarily one shared bucket.  How download and upload traffic interact depends on the technology and service design.  Fibre, fixed wireless and cellular connections can behave differently when both directions are heavily loaded.

Whatever the technology, the computers, router, Wi-Fi and internet service all have limits.  Livestreaming is particularly unforgiving because it needs the connection working well for the whole service.

An email can take another few seconds to send and nobody notices.  A webpage can hesitate briefly and we sigh at it.  A livestream has to keep delivering audio and video continuously.  If it cannot, the people watching from home may see reduced quality, buffering, frozen pictures, missing audio, or a stream that disappears entirely.

So, adding an unnecessary cloud download halfway through worship is not always wise.

Your presentation may already be using the internet

There is another wrinkle.

Even if you are not deliberately playing a cloud-hosted video, your presentation software itself may be using the network.

Google Slides is an obvious example.  Browser-based tools depend on connectivity, while locally installed applications may still fetch linked resources, fonts, images or synchronised content.

Cloud presentation systems are not bad.  But you should know which parts still need the internet – and how that use may affect your livestream.

The fewer surprises you leave for Sunday morning, the better.

What the network is being asked to do

A simplified version of the risky arrangement looks something like this:

There may be plenty of capacity and it may work perfectly.

Or it may not.

Now compare that with:

The second design removes an unnecessary live dependency.

The video can still appear seamlessly in the presentation.  It simply does not need the internet at the precise moment the congregation expects it to play.

That leads to a useful Sunday-tech rule:

If you can make Sunday media local before Sunday,
make it local before Sunday.

Where licensing and permissions allow, download illustration videos beforehand.  Store images and other service media locally.  Make sure your presentation still works if the internet has an inconvenient moment.

But our broadband is really fast

Excellent.  Fast broadband certainly helps.

But “fast” is not a useful diagnostic measurement.

If your livestream is struggling, run a broadband speed test before calling your tech person.

I generally use Speedtest by Ookla at speedtest.net.

If your streaming computer normally uses Ethernet – and for a fixed streaming setup, it generally should – test over Ethernet.  If you are specifically investigating a Wi-Fi problem, test that separately.

Run the test several times and record the:

• download speed;
• upload speed;
• latency or ping;
• date and approximate time;
• connection method – Ethernet or Wi-Fi; and
• location in the building.

Three broadly similar results are much more useful than:

“The internet was a bit slow on Sunday.”

That sentence is technically classified as a cry for help, not diagnostic data.

For the full process, see the accompanying d|c|t knowledge-base guide.

What should the connection be doing?

There is one more piece of information your tech person needs.

A speed test tells us what the connection is delivering.

We also need to know what it is supposed to deliver.

When you send the results to your tech person, tell them who supplies the connection, what broadband plan you are on if you know it, and what download and upload speeds that plan is meant to provide.

If you are paying for 500/100 and consistently receiving 80/12, we have a rather different conversation.

And if performance is excellent at the router but miserable from somewhere else in the building over Wi-Fi, congratulations: the broadband provider may be innocent.  We have found somewhere else to investigate.

Finding out exactly what broadband service the church is paying for can, admittedly, turn into an archaeological expedition involving old invoices, forgotten account logins and a former treasurer.

That may need its own knowledge-base article.

Remove the dependencies you don’t need

Good church technology is not always about buying faster computers, bigger broadband plans or shinier equipment.

Quite often, it is about designing systems so fewer things have to work perfectly at the same time.

Did we mention that Livestreaming genuinely needs the internet to be firing on all cylinders for the whole service?  The illustration video you chose on Thursday probably does not!

Make Sunday media local where you can.  Know what still depends on the cloud.  Test your connection and know what service you’re paying for.

Every dependency you can remove before Sunday is one less thing that can fail during the service.

Illustrations created using AI image-generation tools for d|c|t.