This is an unusual posting about infrequent abberent behaviour in an opaque sub-component of the mAirList playout client. I’m hoping that we might collectively gather sufficient diagnostic data to allow @Torben to provide advice or take corrective action. Come back to it if you’re pressed for time.
Either the BASS library or the mAirList codebase maintains a cache that allows the waveform of a previously-seen media item to be drawn without resampling the entire file. The cache is stored in the file peakdata.db which, on our playout clients, is stored in the top-level mAirList instalation directory.
From time to time, one or more entries in that cache become damaged or corrupted. I am certain that the corruption I have observed is unrelated to failures of either file or disk system.
The corrupted entries cause an implausible waveform to be rendered. In all cases that I’ve seen, the waveform implies that the media file is damaged.
I have had anecdotal reports from studio operators that playback of the associated media is impaired although I have not been able to reproduce this in a lab. I can say with absolute certainty that shutting down the playout client and removing the cache file will resolve the issue. mAirList will simply recreate the file and progressively rebuild the cache.
Yesterday I had the rare opportunity to observe this happening on a production system. I’ve captured the cache file and moved it to the lab. The before and after screenshots below tell the story.
The only difference in the setup that captured the above screenies is the peakdata.db file. The top image was captured on a freshly-launched mAirList. The media in question rendered correctly. That instance of mAirList was shut down. The peakdata.db file was replaced with the corrupt one. A fresh instance of mAirList was launched and the same media item was dragged to the player. The bottom image was captured. The media rendered correctly.
Has anyone else observed the behaviour I’ve described? Do you have any insights into the likely cause? Have you observed any repeated coincidental activities that might shed light on the trigger?
I’ve posted this under the General category of the English forum to cast a wide net. It seems unlikely that the behaviour is specific to the user interface language of the running software. I’ve observed the abberent behaviour with multiple versions of v5 and v6 software over several years. The occurrences are infrequent (as in 1 occurrence after many months of 24x7 operation) and we have devised a workaround that minimises the operational impact.
I’m keen to learn what other users have experienced. It might also be helpful to hear from people who have been using mAirList for a long time (more than 2 years) who have never seen this.
Thanks for your time.
Cameron