I would like to know a bit more about the mechanism by which the audio files are transferred to/ from the DMA to/from the Alerter agent.
When you add an audio file to playback with an alarm, is that file uploaded to the DMA?
Is it then downloaded only when the file is needed to play for an alert?
Are all files transferred from DMA to Alerter upon login?
Are the files zipped and unzipped in the transfer process?
Does Alerter effectively close each wave file after it is played, or is it somehow held in a cache for future playback, such that an unplanned shutdown of Alerter could cause wave file corruption by not properly closing the audio file?
I'm not entirely sure Michael - but I would say that you can simply select a local audio file, and it is not transferred by DataMiner to other client machines, it is simply something you configure on individual client machines.
In that case I learned something new, wasn’t aware it was doing that.
So what I have deduced prior to my question is that when you login with Alerter the first time, an AlerterSettings.zip file is created under the Skyline Dataminer/User/username folder on the DMA to which you connect (and this file is then synchronized to all other agents in the cluster). This zip archive contains an AlerterSettings.xml file, and if you have uploaded audio files, there is also a folder called “Sounds” in the zip archive as well that contains all of the audio files you have added to Alerter. At the same time, a corresponding folder is created on the local user’s system upon which Alerter has been installed under C:UsersusernameAppDataRoamingSkylineDataMinerSLAlerter that is not zipped, and contains an AlerterSettings.xml file, and a “Sounds” folder as well. My question is related to how these folder locations relate to each other, if and how files are transferred back and forth, and how they are used in the operation of Alerter. We recently found that many of 200 audio files loaded to Alerter corrupted and could no longer be played. To fix it we had to copy and replace the files on the client and server with known good versions. I am trying to troubleshoot how that might have been possible. While troubleshooting the audio file issue, we had another problem we discovered that when the Alerter Package was removed and reinstalled with the version included in dataminer 10.1.12, and the Alerter application would not load and connect to a DMA, producing a pop-up windows application error due to a DLL version conflict and subsequent assembly failure related to ICSharpCode.SharpZipLib . That problem was fixed with a workaround to replace the standard ICSharpCode.SharpZipLib.dll deployed in the Alerter package with an updated version now required by the assembly. This DLL issue is being followed up after the holidays by Unit-X. However, the Audio File corruption issue may or may not be related to the mismatched ZIP DLL issue, so in an effort to determine if they could be related, I am trying to find out more about how Alerter syncs files back and forth from client to agent in order to prepare some hypothesis for testing to determine how it might be possible for audio file corruption to occur. As there is a configuration option in Alerter to manually configure the client to not zip messages when communicating with the agent, I am wondering then if it is possible if by default Alerter would zip up any messages or file transfers between agent and client. If it does, then it might be a theory of failure that the zipping of the audio files for transfer between agent and client with an incorrect ZIP DLL version (that doesn’t match the version being used by the agent) might create an incompatibility which results in a corrupted unzipped wave file that cannot be played. It could also be that Alerter may not be “closing” audio files properly after it plays them when a matching alarm is received, such that if there is an unplanned Alerter shutdown, perhaps it could corrupt the wave file if not properly closed.