For the vast majority of users Myriad Playout just works - it will sit there pulling audio and data from your network server 24 hours a day, 365 days a year and playing out smoothly.
Of course, from time to time a server or other hardware might have have an issue - the server might have a faulty hard drive, the network connection might be damaged, or even a network switch might start failing to flow packets smoothly.
Although extremely rare, it's even possible for Microsoft SQL Server to be having performance issues - though it's worth working through this article as well for more information on some steps to help with those!
Myriad Playout requires 2 things from a network server: Audio files and database information. For the purposes of this article, lets just consider how Myriad itself handles data outage, regardless of whether thats due to a network, file server hardware issue, or a database issue.
Whenever Myriad plays an audio file, it always reads at least 8 to 16 seconds more audio that it needs into an in-memory buffer - so if you were to drag a Media Item into a Media Player, the first 16 seconds will already be in memory the moment you hit play.
This cache is constantly topped up as the media item plays, so your network/server would have to be totally unavailable for more than 16 seconds before you even noticed anything was going wrong - and 16 seconds is a surprisingly long time when you sit there and watch it!
After the audio buffer has been exhausted then Myriad will continue to try and carry on for a short while, just in case the network returns, but will then close the media item and then start the next item playing - if possible!
Future versions of Myriad will improve this resilience even further.
Myriad Playout stores almost all of it's non-audio data in the SQL Database - everything from the title and timing information for Media Items, the Scheduled Log, the Schedule information used to create that, not to mention the user security and auditing information.
In the event of a database connection issue, Myriad is actually built with some pretty huge resilience in it - all critical path SQL calls are wrapped up such that if the SQL server is timing out then it will retry up to 5 times with up to (by default) 20 seconds or so timeout - and that timeout is determined by windows not by Myriad itself - you can actually that by manually editing the SQL connection string.
By critical path, we mean all the calls used to play items from the MediaWall, and also Scheduled Log Playback. Non critical path items include searching user history logs etc. as these do not affect the live playout itself.
If the server is totally unavailable, then eventually Myriad Playout will have to give up - but for myriad to have ultimately had to give up means quite a LONG timeout had happened. Myriad did it's best, but if the server was unavailable, it was unavailable. Great that it came back after a while, but we can only wait so long before its important that we highlight WHY myriad has stopped playing items. Otherwise you could have all sorts of problems brewing and stalling playback and have no idea why!
Making this even better:
In Myriad Playout v5.22 we worked hard on making this even better - without any configuration changes at all, Log Playback now plays every item already visible in the dashboard, even if the SQL Server is totally unavailable. It will even keep a list of all the items played in memory, so that when the SQL Server does return it can update the "played" times and mark the blue ticks.
Myriad will even show a caption on the Dashboard to alert you that the SQL Server is not available, and as soon as it's back up and running Myriad Playout will seamlessly reconnect and carry on.
However, we knew we could do even more than that, so there v5.22 adds a new option in Station Settings "Additional number of log Items ahead to cache" that lets you extend that number of items - so for example, entering "15" will mean Myriad reads an additional 15 items on top of what it shown in the Dashboard, meaning that Myriad can play for even longer with the SQL Server being totally unavailable.