Picture of a lake in Canada

Shiloh Speaker Presentations

November 16, 2019

Recently Shiloh Church started to use Office 365. O365 provides access to the Office suite of applications as well as enabling centralised document storage and identity management.

Thanks to Microsoft’s Non-profit scheme we also have a bunch of Azure credits to use on projects. These credits have come in very useful for the project I am going to describe below.

Audio Visual Team

Shiloh Church is my home church and I volunteer on the Audio Visual Team along with a bunch of other people. I have been running the sound desk at church for 11+ years and regularly help the speakers to get their presentations up and running. This normally takes place just before the service starts, this can be a critical period for the AV operators as its when we:

  • Check over the AV setup,
  • Double check the amount of battery left in our radio mics,
  • Give out the radio mics,
  • Speak to members of the congregation.

Getting any presentations / pictures / videos up and running earlier in the sound check / pre-service practice should make the time before the service starts a bit less frantic. For the speakers it would also be beneficial for their media to be ready for projection ahead of time. It gives them the opportunity to spend more time with the congregation before the service starts and it would be especially convenient for them to upload their media before the day of the service.

With this in mind I set out to put something together to streamline the process.

Presentations

Speakers at church might use one or more of the following:

  • PowerPoint
  • Photos / slideshow
  • Songs
  • Videos

The Solution

I wanted to create a web page that would let speakers upload whatever they wanted to show at church when they are speaking. Speakers often like to use publicly available videos in their talks, so they should be able to give the system a link to them. The system should then download the files that the speaker has selected to the projector machine that is used on a Sunday.

The page speakers see when uploading presentations, images, specifying video URLs etc.

Architecture

Website -> Logic App & Azure Container Instances -> SharePoint library -> Projection machine

The Website:

  • Passes on the uploaded files to Azure blob storage
  • Creates a JSON payload that contains the URLs to the media on blob storage and some metadata about the service.
  • Queues a new message on an Azure storage queue containing the JSON we have just prepared.

The Logic App (Part 1):

  • Picks up the queued message from the storage queue.
  • Parses the JSON content.
  • Grabs media uploaded by the speaker from blob storage
  • Uses the SharePoint integration to create a new folder in SharePoint for that service and adds the media.
  • Creates a README.txt file for the A/V operators to read before the service. (This is populated from notes provided by the speaker on the website.)
  • Starts a container instance, providing the URLs of the videos that speakers would like to show as arguments

The Azure Container Instance (ACI):

  • Pulls down the videos from the pages listed (Using the fantastic Youtube-dl tool)
  • Uploads the video to blob storage.

The Logic App (Part 2)

  • Waits for the ACI instance to finish
  • Copies the videos the ACI created from blob storage into the SharePoint folder we created in part 1.
  • Sends the ACI logs to myself (So I can follow up on any problems)
  • Lets the speaker know what has been successfully processed and saved into the SharePoint library.
  • Removes the queue message from the storage queue.

The Projection Machine (The easy bit)

  • Setup the OneDrive client to sync the SharePoint library containing the service media.
  • When the machine is powered on for the practice OneDrive syncs all the media to the local disk.
  • AV operators follow any instructions provided in the README.txt file and setup the Open LP service ready to go.

Using docker to containerise as much of this seemed like a nice way to deploy the code and ensure that when stuff worked on my machine it would also work in Azure. The website and the video downloading container were all built using docker and stored in an ACR.

Things that tripped me up

I struggled at first to get the logic app to correctly detect when the ACI instance had stopped its processing. The key variable to use here is the container group state field, that one has the good stuff in, there is another variable available which didn’t do the job for me.

Variable to monitor: body(‘Create_container_group’)?[‘properties’]?[‘instanceView’]?[‘state’]

There is a max filesize limit (~100mb) which prevented long videos from being transferred to SharePoint. If the connector to SharePoint supported “chunking” this limit could be avoided (or at least be less of an issue).

ACI Dev life cycle

GitLabs Continuous Integration proved really easy to use and it was great to be able to commit code, have GitLab CI build the images and push them to the Azure Container Registry (ACR). Once the image reached the ACR it would be used by the next run of the Logic App.

Conclusion

The website has been used a couple of times now and since the few bugs have been ironed out its worked really nicely. Myself and the church leadership team still need to encourage some more people to use it, but when it does get used it makes the practice run a bit smoother. Im interested in seeing what other improvements we can make to get more value from the tool.

comments powered by Disqus