A year (and a day) in broadcasting
Hannah Gerrard Field, a Solent BSc (Hons) Broadcast Systems Engineering student on placement with Evertz Microsystems, talks us through a day in the life of a broadcast project engineer.
“Broadcast doesn't get a lot of graduates because it's not a path people tend to leave school thinking about, but I highly recommend it as a career – and Solent Uni is the perfect place to learn what you need.
“It's very interesting, the lecturers are lovely and the units are good fun. There are lots of great uni trips to interesting places, and you can help out at festivals like Glastonbury. Plus of course there are loads and loads of placement opportunities in the industry, from summer work to full years out.”
“Solent taught me a lot of important stuff about the science behind video and audio, as well as broadcast workflows, and some basic networking and coding. These skills were very useful when I took a year out to do my placement. It’s allowed me to learn a wider variety of coding languages, how to use databases and how these integrate with the broadcast industry.”
A day in the life
9am: Arrive at the customer’s site, which in this case is a broadcast centre in London, and set up my workstation for the day, including grabbing a coffee. I deal with any emails that have come through to make sure I’m up to date and have an idea of any urgent work that needs to be started or completed.
Generally, on the full-time placement I was always based in the office until I was requested to go onsite – usually about once a week when the client was in London. However, I once did two weeks on, two weeks off for a few months, travelling to a client’s site in Virginia, USA.
10.15am: Daily meeting with the rest of my team to discuss what needs to be done today and any issues that may have arisen overnight from the client, identifying tasks of high importance and delegating to different members of the team.
No day is ever the same; at the start of a project, it’s all about implementing hardware and software functionality to get the system working to the client’s specification. Later on in the project, we test and look for software bugs that we then have to work out how to fix.
10.45am: Once the meeting is over, I can start my tasks. My main priority today is to write a document to notify the customer of an upgrade we need to do to the playout system – a system which contains a database and a number of playout servers, using a TV schedule to find what programmes will be broadcast at what time and transfer the files onto the appropriate servers – so I can implement that later on.
I then need to debug an issue we are seeing with some of the graphics not working correctly on the playout streams. We couldn’t see a programme play over the video stream, which would mean that if it was live, the user would only see a black screen with no sound.
It turned out that as the file was uploaded into the system, it was being registered with the wrong duration. It was 20 minutes long, but the person uploading the file had entered 15 minutes, meaning that our system couldn’t read the file to play the video.
12pm: As I’m on the customer’s site I’m usually approached by various people who ask for help with the system, want to raise new issues, or even just want to have a friendly chat. If any issues are raised, I log them for the team to see so they can be handled later.
If the issue is very important or causing a lot of problems, I end up ‘firefighting’ to get the system back to a good state.
1pm: Lunch with my colleagues, on expenses. We’re given an hour but rarely take all of it as it’s important to get back to the customer.
2pm: Grab an after-lunch coffee and carry on with my work. I read my emails as they come in throughout the day, and respond as needed; by now I’ve been asked to do a couple more things.
I go into the server room to take a look at some of our hardware, and to find some network details for one of my team members, who is working remotely.
2.30pm: Time to do the planned upgrade on the system and implement the new code. This usually takes about an hour because the system is very large. An upgrade is basically taking one version of the system’s software and installing a newer version, which will often include fixes for some of the bugs we pick up.
It’s done by running a series of commands on each server and testing once the update is installed, by going into the GUI (graphical user interface, such as Windows) and running through all of the different parts to make sure they’re working as required.
I undertake some health checks to make sure that everything is back up and running with the correct software version, so the system can be handed back to the customer to do their own testing on.
3.30pm: Meeting to discuss a brand-new functionality called ‘Automated Continuity’. Continuity is the bit between TV programmes where they say “Up next is…” – this is usually pre-recorded audio over a piece of video, or by someone talking live over the video. What ‘Automated Continuity’ will do is automate this so there is no need for pre-preparation or user interaction.
We’re coming to the end of months of testing and development so we usually end up talking about any identified problems and, occasionally, how well the testing has gone.
4.15pm: Afternoon coffee and snack, then back to work, trying to finish off my tasks.
6pm: Start packing up and head to the train station for the journey home. It’s a bit tedious to get from London to Southampton at rush hour but I wouldn’t change it for anything.