Wav <---> Vox Conversion Issues

[CSI]

Running 6.0.3141 Enterprise, 28 Line license. SR 6.0.

 

In the past week, I have had to restart the VG application several times because it the conversion between wav and vox stops working.

 

I've noticed the problem originally because I went to replace a sound file (wav) and it doesn't play. After researching, I have discovered that it does not create the new VOX file.

 

I have also noticed that people leave messages in my IVRs (using the record file module) are leaving VOX files instead of WAV when this problem occurs.

 

I have turned on logging, but the entire file for a days with of logs is far too big. Here is one example I found of a file I just replaced and the vox was not played. The result was the IVR hung up on me for not entering any input.

 

142117.18 20 rv replace end: [D:\sounds\X\133A.wav]

142117.18 20 state [133] Playing (D:\sounds\X\133A.wav)

142117.20 20 tw ConvertWav2Vox D:\sounds\X\133A.wav

142117.23 20 tw wav->vox convert end 944781,,1,0,,

142117.24 20 play start ok, lPlayId=944828

142117.24 20 tw DialogicEvent 132,TDX_DIAL,0,0,0,,,

142117.24 20 event TDX_DIAL, iCode=132 state=1100

142117.24 20 LsPlayMsg EV_UNKNOWN_132,TDX_DIAL

142117.26 20 path {TDX_DIAL} not found

142117.26 20 tw PlayEnd 20 944828

142117.26 20 play end id=944828, (current ID)

142117.26 20 event EV_PLAY_FINISHED, iCode=8001 state=1100

142117.26 20 LsPlayMsg EV_PLAY_FINISHED,EV_PLAY_FINISHED

142117.27 20 path {EV_PLAY_FINISHED} not found

142117.27 20 timer set 10 EV_TIMEOUT_HANGUP

142117.27 20 timer set 10 EV_TIMEOUT_HANGUP

 

 

After restart, here is the same file played:

 

143238.73 8 state [133] Playing (D:\sounds\X\133A.wav)

143238.73 8 tw ConvertWav2Vox D:\sounds\X\133A.wav

143238.90 8 tw wav->vox convert end 626312,D:\sounds\X\133A.vox,1,0,,

143238.91 8 play start ok, lPlayId=626484

 

 

I believe this only started happening after I turned logging on to look for the source of another problem. Could logging be causing this?

[SupportTeam]

This looks like the "zero size .VOX" problem that was fixed a while back.

 

Please update the latest version of VoiceGuide for Dialogic and see if the issue is still occurring.

[CSI]

Upgraded last week to latest version and having same issue.

 

I don't have a log to send you because when I restart VG, it works for a day or so...

[SupportTeam]

Please post the full day's "tw" log which captures the problem at some point and we'll then be able to comment as to what is happening on this system.

[LTympanick]

Not sure if I can shed any light on this but I feel like I ran into what appeared to be the same problem.

 

Not easily reproducible, but from what I can tell, I had altered WAV files that needed to be converted to VOX first and VG was getting hung up to the point of timing out on a script rather than getting to the next step and I'm not sure if this was something to do with wav to vox conversion or something else going on that was causing the script to hang.

 

What allowed me to clear up the problem was a full reboot of my computer. Not enough to just exit and re-run VG or even log out of a session and log back in. Had to do a soft reboot to clear up the problem.

 

Then it appears to be working fine again after the reboot. I have never noticed this problem when the VOX files were already existing, but I'm still skeptical of blaming the wav2vox converter.

 

The 1st two attachments are logs from the app prior to reboot.

 

The 2nd two attachments are logs from the app, post reboot.

 

Please note in the prior to reboot tw.txt the hang up appears seemingly in the 205022.046 - 205034.156 range after which the call is terminated via a hangup on timeout.

 

In the prior to reboot vgm.txt file note around 205023.025 range is where I see the vbscript apparently starting to hang, eventually leading to a hangup on timeout.

 

As you can see, the same problems do not happen in the after_reboot logs, the script goes further.

 

In my case, it happened with logging only set to 1 initially, so I don't think turning on heavy logging itself is the cause of this particular problem.

 

Any insight would be appreciated.

prior_to_reboot_0116tw.txt

prior_to_reboot_0116vgm.txt

after_reboot_0116tw.txt

after_reboot_0116vgm.txt

[SupportTeam]

Traces show hangup on this system was caused by the VBScript running for longer then the Timeout specified in module [initialize System Parameters]. The timeout path pointed to module [Hang up the call], and this path was taken when timeout was reached.

 

205021.94 2 state [initialize System Parameters] Running VB Script...

...

205034.16 2 Terminating process (timeout reached).

We can see that in the trace before the reboot the VBScript never logs this line:

 

"Successful connection to HotLineSystem database on server HOTLINE4"

 

whereas after reboot this line is written into the vgm log, so looks like the actual problem here is that the VBscript you are using could not connect to your "HotLineSystem database on server HOTLINE4" - and the way it reacted to it was by timing out and hanging up the call...

[CSI]

An update on the original issue. I have not seen this problem again since rebooting two weeks ago.

 

If I encounter the problem again, I will post but I will for now assume everything is working as it should.

 

thanks

[fluffybunny]

I dont know if this helps but I also had the WAV > VOX conversion problem. I would restart voiceguide and it would work fine for a day or so then the problem would come back. So, I switched logging on to send some traces in and since I did this the problem has gone away. (I switched logging on about 4 weeks ago and its been fine ever since).

 

I've not switched logging off again to test if this has an effect as it is a live system and I'm reluctant to cause my customer further problems, so I've just left logging on.

 

Could it be a timing issue perhaps? Anyway, no need for a response from my perpective, but I thought this info might help you chaps find out if anything is going on here.

[LTympanick]

This is me again and I have noticed what appear to be wav2vox conversion issues again with the latest Voice Guide for Dialogic v6.0.3310. However it's not clear whether it's wav2vox that is the problem, or if it is the record module.

 

I now agree with fluffybunny that this wav2vox conversion issues happens when logging is turned off. If I turn ktTel logging on, none of these 0 lenght vox problems happen. So it definitely appears to be a timing issue that is mitigated when logging is turned on.

 

Here's the sequence.

 

Logging is off:

 

I run my app and record a new annoucement. I know already something is wrong because it doesn't say "Announcement saved" when I finish recording by pressing the # key, like it's supposed to emanating from my post record vbscript that plays that message while also doing other stuff. (See attached module code snippet).

 

I then go back and attempt to listen to the announcement I just recorded. Nothing is played because wav2vox attempts to convert the file but for whatever reason it doesn't, and the result is a 0 length vox file. (See attached filewindow.gif)

 

At this point, if I wish to delete the ANNOUNCE.WAV file, I can't. I must exit VG first in order to do so. So at this point, wav2vox is tying it up because of it's failure to convert.

 

Now set ktTel logging to 10:

 

As soon as I turn tw logging on, I go through the same sequence and I record my new announcement. I hear my Announcement saved.wav file played just fine and everything is hunky dory (until I attempt to hang up the call which caused VG Multi to crash & burn....that's not good but let's solve the first problem first).

 

The tw log file is also attached.

 

I'm just about ready to purchase my 23 line license because I've solved all my issues with getting in sync with the phone company. Now I just need to have more confidence in VG before going live.

codesnippet.txt

0520tw.txt

[SupportTeam]

Please update your system to the ktTel and VgMulti attached.

 

This new version does not create VOX intermediate files any more.

 

According to our testing this new version should resolve the issue you have encountered.

 

To update:

 

Run these command from Command Prompt in the Windows' System32 directory to unregister ktTel.ocx:

 

regsvr32 - u ktTel.ocx

 

Then copy new ktTel.ocx into Windows' System32 directory (remove or overwrite previous OCX's from system entirely, do not just rename it)

 

Then run this command from Command Prompt in the Windows' System32 directory to register the new ktTel.ocx:

 

regsvr32 ktTel.ocx

 

Then copy the new vgMulti.exe into VG's directory (overwriting existing).

 

 

 

In additon of resolving the issue the attached version differs from v6.0.3310 in following ways:

 

 

NEW : $RV_STATUSDISPLAYED added.

NEW : Unlimited Length Result Variables can now be loaded into the Dialer's OutDialQueue database.

CHG : VOX intermediate files are no longer created at all.

CHG : EV_TIMEOUT_MAKECALL_NORESPONSE on outgoing calls set to 10 seconds more then Dialogic's Call Progress timeout.

This is to ensure Dialogic's Call Progress timeout always occurs first.

FIX : Rings reported by the telephony card immediately after hangup are ignored as such events are usually caused by

impedance mismatches between line and telephony card, and not a genuine incoming call.

FIX : Result Variables can now contain the "}" character.

FIX : Escalation calls are now dialed immediately when "RETRY" is specified for Answering Machine script and the retry counter is 0.

FIX : DialoutProcessFailedDial error which was preventing immediate escalation fixed.

FIX : Record Pause/Resume can now use the same DTMF key.

VGD_3320_patch.zip