The Stability of MediaShout 7

One of the things we hear over and over—regardless of the presentation software named—is the concern for stability. The last thing you want is for your presentation to crash in the middle of your service unexpectedly. Unless you are a billion-dollar conglomerate who not only creates the presentation software, but also the OS it runs on (i.e. Microsoft and Apple), you are walking a fine line between powerful, feature-filled software and creating stable software. In fact, there is mathematical proof that increasing the number of features linearly will increase the potential for instability exponentially.

Additionally, while programs built on the Apple ecosystem (MacOS, iOS, etc.) have a finite number of OS and hardware combinations (which Apple does on purpose), Windows and Android OS can exist on an almost infinite number of hardware and operating system combinations, with no real confirmation of whether a certain hardware combination will work with software designed for the OS. That makes the development of high-end software more difficult for Windows not because of the software or OS, but because of the end-users’ ability to have such a wide range of possible hardware combinations. To handle all possible configurations is very difficult.

When creating MediaShout 7, we decided to make stability our top priority. We fought against the mindset that instability is inevitable simply because the OS and hardware are out of our control. Instead, we looked at every aspect of our software to try and make it the most stable software for presenting available.

Here are six things we did to make MediaShout 7 the software that you can trust.

New language, New strategy

For almost 20 years, MediaShout software was built in C++, a powerful—but very complicated—programming language. With MediaShout 7, we built everything in the newer C# language using .NET framework, which means that every element had to be recreated from scratch. What does this mean for you? It means that there is no longer reused code from multiple previous versions that cause unexpected behaviors with a newer OS or hardware. With newer tools designed for newer technology, there is less coding required to do the same tasks. When you have less code, the chances of having errors or issues are reduced. In addition, the code for individual features is now modular, making improvements easier and having less risk of breaking something else. Furthermore, we have shifted the way we do development from being very ‘large-release’ focused to more of a proactive and reactive development to immediate needs as they arise, with the ability to adjust development resources quickly and easily to address immediate issues (also called “agile”).

Native 64-bit

Making MediaShout 7 a 64-bit program eliminated a small group of users who are still running 32-bit Windows systems, but it opens up a whole new world of processing tools and features to improve stability. In fact, almost all Windows 10 computers are now 64-bit, so creating a 64-bit program to utilize these tools makes sense. This allows MediaShout to utilize more RAM as well as distribute processes across multiple CPU cores and threads, making the processing load much easier on the system and allowing us to separate resource-intensive elements into different processes (i.e. the Control Screen and Main Display outputs are now separate processes).

Stability before Release

One of the biggest mistakes a lot of software companies make is to load their software up with a ton of features without fully realizing the impact that can have on stability. As mentioned earlier, the more features you have, the more potential for issues with stability. From day one of development on MediaShout 7, we made the decision that ANY feature added would be checked for stability before being released. We put all current (and upcoming) features through the paces to make sure that they work as expected—and even handle unexpected uses. We additionally make sure that a feature being added doesn’t negatively affect another part of the code that already exists. Although we have not yet implemented all of the features that are planned for MediaShout 7, you can rest assured that any feature added will be thoroughly tested to try and eliminate any unexpected behaviors when using it.

Application Log

Our development team also implemented a simple log file that records unexpected issues which occur while the program is in use. The issues may not have any impact on performance or use, but it is helpful for us to know if something does go wrong in the background. Additionally, if that rare crash does occur, we can look at that log and determine almost immediately where the problem resides. Using a combination of this log and the development team’s direct involvement, we can address almost any issue quickly and have fixes released in a short time.

Better Communication, Less Isolation

Unlike previous MediaShout versions (and even other programs), our Development Team is no longer isolated from the Customer Support Team. Our support team has direct contact with our developers and can post issues, improvements, and feature requests in an internal forum. These posts can then be commented on, reacted to, and updated by our developers, customer support team, and even beta users as they test and try things out. This removes any bottleneck or vacuum that can occur when all communication has to pass through a narrow channel of one or two individuals. This allows our team to address issues faster and gives transparency to our Beta users about the status of ideas and issues. This also allows developers to be part of our Customer Support process, even joining in on remote support sessions to see issues on individual computers. Gone are the days of workarounds to avoid pitfalls. Instead, we are addressing each and every concern that is brought to the table to make MediaShout reliable for every single user.

Plug-in Architecture

One of the best things that we did with MediaShout 7 was separate some functions into Plug-Ins. By doing so, we essentially have created ‘silos’ in the code for each individual major function so that we can have a solid core program and then address the various functions separately as needed. This is similar to fixing a failed speaker at church by replacing only the actual broken speaker instead of replacing the entire sound system. These plug-ins allow us to keep elements separated for code purposes, but they also make the program more stable by not trying to do too much at one time within the core program.

So, can you really expect stability?

Our team has taken great strides to make MediaShout 7 the most stable, most powerful, and easiest-to-use church presentation software. By making these fundamental changes, we are not only creating a better product but also providing better support to our users and helping them better serve their congregations and ministries. Give MediaShout 7’s stability a run for its money.

If you find an issue, we want to know about it and fix it—period. But we are confident that you will find MediaShout 7 to be the most stable and reliable church presentation software on the market. And for a message as important as the Gospel story, this matters to us just as much as it matters to you.