The evolution of a Website into a radio automation back-end.

Hello and welcome to the evolution of a website into a radio automation backend. Where I will tell you how my first Bitjango project has evolved over more than a decade. I am Ernesto Rico Schmidt. Rico is not my middle name and I am an electric engineer target software developer. I was born in Bolivia where I am currently living after spending half of my life in Ratz in Austria. I've been using Linux and free software for almost 30 years now I have programmed in almost in all sorts of programming languages since I was studying in Graz.

I discovered Python around 2003 and started with Django around 2008. Currently I work with Django and Go. I work as a remote software developer for Radio Helsinki in Graz, one of the 14 free radios in Austria. I did three attempts, it took me more than a year, but I translated Doc Hellman's Python 3 model of the week into Spanish. Free radio started in Austria as in other places all over the world as pirate radios, broadcasting without a license until 1997

when a new regional radio law was passed ending the state broadcast in Monopoly. Now they are recognized as non-commercial radios and receive some funding from the state or their cities. A free radio has a fundamental difference from commercial ones. It's a non-profit and community-driven As such, it serves very diverse communities that don't have access to commercial broadcasting radios. Radio Helsinki started to broadcast in 1999 for a month during the art festival known as Starish Herbst. In 2000, Radio Helsinki

obtained their first license to broadcast 24 hours. Back then, almost every show was live. Now about 80% of the shows are either pre-recorded or re-broadcast from other free radios. This is part of the program for Radio Helsinki from February to May 2023. It's difficult to see and distinguish, but the font colors signal different types of show and the different color bars signal the rhythms they follow. This is the first challenge that commercial radio broadcasting software faces The initial goal of the project PV for program Febaltum or program

management tridehelsynky was to display the shows and the schedule. in a daily and weekly overviews and to integrate them into the website. This led to a mixed solution. In 2011 the website from Ryan Helsinki was powered by Plone and included all the program data from the backend This sounded way cooler to me back then and was something I was really proud of. Please forget for a minute that REST was already a thing at the time. Yarn or yet another Rhino Miniature was originally developed at Radio Fabric in Salzburg, one of the the other Austrias

Red Radius. It's an open source, but I have to admit I have never seen the repository, any source or even a Rhythmie Currently Yarn is used at six free radios in Austria despite the development of the software being abandoned in 2014. YARM is a Java Monolith application that has one fundamental flow. It doesn't offer any remote interface. That has led to some radio stations to ask their hosts to upload the pre-recorded tools, then to have the program managers download them and schedule them. This is the second challenge that commercial ready broadcasting software faces.

At Radio Helsinki we use Rivendell, another open source radio management solution to automate almost everything in the program. We have developed a simple interface for the host to upload and schedule their shows remotely. After you think we have about 120 shows that are prerecorded or rebroadcast Currently the main limitation is that we are when we are broadcasting some live event or from a live stream, From a remote location, we need somebody to be present in the studio all the time to start and monitor the stream

This situation led some of the free radios in Austria to start thinking about the joint project to tackle all these requirements that are more or less common to all free radios. by developing a new open source software suite. Then in 2017 the project Aura started based on Radio Hess Increase contributions and other radio contributions. From the beginning the project was envisioned with a distributed architecture in order to avoid the limitations that YARM has. The different components of Aura

sorry The different components of Aura communicate over their HTTP APIs. The whole suite is made up of modular components which could be exchanged with other components. Every component provides a well-documented API. At the moment only the engine is developed with an API first approach. The other ones, the steering and tank, the APIs are generated out of the code base. At the core of Aura

is steering, the Django application that is the source of truth for the program. Steering stores the information about the program and offers a REST API to manage this information. It is intended to provide the information to drive the broadcast and to provide the data to be displayed on the radios website. Steering also acts as an open ID connect provider for the other components. Tank stores the playlist and the media for the playout for the shows including metadata if it's available

A playlist can contain a combination of media files and other sources like Line In or streams The engine is the main playout component. It's in charge of playing the media and switching between the sources or studios according to the playlists stored in the tank. The engine provides a public and internal APIs to and uses the liquid SOP language for the playout. The engine also includes silence detection and optionally records the output. The dashboard provides the user interface to steering and tank.

It currently allows the managers to create, update and delete shows and schedules. It also allows the hosts of the shows to manage their and organize their media and playlists. It will allow it will offer different set of features and permissions depending on roles and privileges that can be configured individually by each radio station. And finally Play is a library of web components that can be integrated into the radio station's website to display the program. including what's currently playing

The program is modeled using shows, schedules, and time slots. The show part is obvious It includes the name, the description, the host or hosts, and all the taxonomy like the category, the type or the language of the show. The scale describes the rhythm of the repetitions for the show according to the recurrence rules. The schedule is used to generate the time slots. The time slot represents a specific time that's assigned for a show in the playout. Recurrence rules govern how a show repeats, in which written how often or how long it repeats.

They are a wrap around the duties rule object. Currently Aura supports a total of 31 recurrence rules. including once daily weekly b-weekly four-weekly monthly b-monthly three-monthly and four-monthly Radio Helsinki supports and uses B-weekly, weekly, B-weekly and four-weekly recurrences. Radio Orange in Vienna supports weekly, B-weekly and monthly recurrence. Initially we had support for what we called b-weekly every

odd numbered and p-weekly every even -numbered recurrences. But it turns out this is a very odd recurrence rule because every approximately seven years the year has 53 weeks. The next time will be in 2026. The first day is a Thursday and the last day is also a Thursday. This results in the first week of 2027 being outnumbered after last week of 2026 being also outnumbered. That means if you have a show scheduled on odd numbered weeks, you will get a bi-weekly show scheduled two weeks in a row. And if you have a

show scheduled on even numbered weeks you will get a no be weekly show schedule for two weeks in a row The detection and solution of time-lots collisions was a major headache with the original Django project. that manage it or or better try it to manage everything in the admin interface. It was not part I was not part of the Aura project back then but luckily Ingola indecor studied the collisions that can arise and contributed the detection and solution of time slot collisions. Let's take a look at them.

The first one is the single collision that fully overlaps. Here we have a projected time slot and an existing time slot that fully overlap. In this case, there are two possible solutions. We can keep the existing time slot and discard the projected one. This solution is what we call in the API their theirs. The other solution for this case is what we call ours. We delete the existing time slot and create the projected one. These two solutions are always possible whenever a collision occurs

The next type of collision is a single collision that partially overlaps. Here we have a projected time slot and existing time slot that are partially overlap. In this case, the projected time slot starts before the existing one has ended. In this case we are we have four possible solutions for this collision. The first We keep the existing time slot, created a new truncated time slot that starts at the end of the existing time slot. We call this solution Dirse Start. The second possible solution, we create the projected time slot and change the existing time slot to end

at the start of our projected one. We call this hours start. The third possible solution is to keep the existing time slot create a truncated timeshot that ends at the start of the existing one. We call this DERS end. And the fourth solution is we create the projected timestat and change the existing timestat to start at the end of the projected one. We call this one hours hours end. All the previous solutions

are also available in this case. And finally we have the simplest collision, single collision. Whereas a supraset, that means that one the pro in case this case the projected time slot is the supraset of the existing one. In this case, we have one solution. We keep the existing time slot and create two new time slots around the existing one. We call this Dirce Boat And we have a subset here. The projected time slot is a subset of the existing one.

And there is one solution for this case. We create the projected time slot, split the existing one in two. What in two around the projected one Now let's see this in action. I want to show you how the collision resolution works with a simple example here I have created a show and here is the JSON file that describes it And I have the station file describing a new scale that I want to create. It's from Monday

29th from 1505 to 1535 and it's only once When I create this with the post requests The response returns are 201 created with the new schedule that is on the 29th from 1505 to 1535. If I try to create this scale once again It will obviously collide with the previous one. Now I get

a 409 conflict The draws mean that the projected diaglot collides with this one This collision has a hash and two possible solutions If there were multiple collisions I will get them all in this list of objects and each one will have a hash ID a hash and possible solutions in this case

All I need to do is provide the solution in the solutions dictionary the hash as key and ours house as value in order to replace this Now I see they have a 201 created. It creates a A new schedule on the 29 from 1505 to 1535 And I can see that a time slot is created for this time

This is all possible thanks to people that has contributed in the past and the team that is currently working on Aura. The team currently is Margarete Majova-Lishka. She is the product owner for Aura. Christian Boynna is the lead developer of the tank. David Dlatnik is the lead developer for the engine. Konrad Morfeld is the lead developer for the dashboard. Ole Binder is the lead developer for the engine recorder. I am currently the lead developer for the steering I want to close with a quote from Marcelo Bielsa.

Marcelo Bielsa is a former football player, manager, and coach from Argentina. He has coached the national teams from Argentina and Chile and will coach the team from Uruguay into the next World Cup. The possible is already done, the impossible we're doing it for miracles we need time. At aura we are currently working on the second alpha release for Aura 1. 0 We're finishing the APIs and squashing jump bugs. We expect to release the first beta in the first quarter of 2024. We should deploy Aura at Radio Ranch in Vienna and at Radio Helsing in

Graz after that, maybe around the summer. If you are interested in the project, would like to check out what Aura currently offers, maybe give it a try or contribute, don't hesitate to reach out. You can visit our website and reach me over Mastodon. Thank you very much for your time and your attention. I want to thank the organizers of this year's Django Com Europe for this opportunity and I hope to be part of a Chango Common Europe in person in the future. Yeah, your website and you can reach me over. The photo of the vintage

radio was by Maximilian Hoffer from Unsplash. Thank you very much.