Cannot Record A New Message

[rverones]

We have a brand new Windows server setup with the Dialogic D120JCT card with an 8 line enterprise edition of Voiceguide.

 

Setup was great, worked well out of the gate.

 

We have setup a script, that upon press 1 2 3 or 4, it simply plays the mailbox#.wav file that is recorded by the dispatcher.

 

That seems to work well. 7 lines are filled all day long of people listening to say, 1.wav. It takes them back to the main menu when they are done listening (2 sec timeout) and they can listen to 2.wav and so on.

 

We have ran into a snag, where once the recording is finished for 1.wav and only 1.wav, the dispatcher cannot call into the system later on and record over the file. When they go through the prompts that allows them to change their greeting, it hangs up.

 

However, this is not the case for the other 3 mailboxes. They can, for example, login to mailbox 2, record a new greeting, press 3 to save it, and go back to the start without hanging up, try voicemailbox 1 and it will hang up.

 

I have to sign into the system, stop the service (right click the IVR icon in the tray and press stop), delete 1.wav from c:\program files\voiceguide\data\VmWelc, then start the IVR again and then they can successfully record the message.

 

1.wav is 1438 KB. the other greetings are approx half of that size, but have had no issues recording them over and over.

 

I removed the mailbox, and re-created it. It does the same thing.

 

What are we missing in the config or configline xml files that might fix this. We have not done any customizing to these files as of yet except for the script changes for each line in the config.xml file.

[SupportTeam]

Could you please post a copy of VoiceGuide's Trace Logs which captures the problem, this will allow us to see what happened.

 

Debug Trace files are created in VG's \log\ subdirectory.

 

When posting traces/scripts please .ZIP them up and post them as attachments.

 

Please indicate the time that we should be looking at when the problem ocurred.

[rverones]

I hope I have attached the correct files. I attached one with both log files and one is the sysinfo file I ran this AM.

 

Time of the end of the last call on line 8 was at 8:53:10.

1116_0003_vgEngine.zip

its_sysinfo.zip

[rverones]

The last message I just posted may be incorrect. The customer may not have made an attempt to record the message as he did not get through the entire menu.

 

I will have him try this again later.

[rverones]

Okay, this should be the file.

 

I watched the line status monitor while he dialed in. As soon as he hits 2 to record a new greeting, he gets disconnected.

 

The disconnect occured at 12:49. I wasn't sure while you needed, so here are 4 of them that occured on or at that time.

1116_1249_vgEngine.zip

[rverones]

Wondering if someone can respond to this letting us know that they are looking at the files and will have more questions or answers for us ASAP. The product is in production and we need to know if we have to take it out of production and put in the really old product.

[SupportTeam]

Trace shows:

 

124910.559 560 14 file delete fail [The process cannot access the file because it is being used by another process.

] [C:\Program Files\VoiceGuide\data\VmWelc\1.wav]

 

 

Another port was playing back this same file at that time, but this should not affect file being overwritten, as VoiceGuide does not lock the file while playing them back (static files are fully read in before start of play).

 

Are you sure no other app has this file opened?

 

Are you able to delete/rename that file manually?

 

 

 

124849.169   560   6 fn    PlayStart(iLineId=6, sFileList=,C:\Program Files\VoiceGuide\data\VmWelc\1.wav, sXMLOptions=)
124849.169   560   6       PlayStart(hLine=6, strSoundFile=,C:\Program Files\VoiceGuide\data\VmWelc\1.wav, iPlayId=306734(0x4ae2e), iParam1=0, iParam2=0, zsParam1=, zsParam2=, keys-notused)
...
124849.169   560           wav: format=7, channels=1, hz=8000, bytes/sec=8000, bytes/sample=1, bits/sample=8, DataBlockSize=835906  C:\Program Files\VoiceGuide\data\VmWelc\1.wav
...
124849.169   560   6       play(6, 0x9390670, tpt=0x0, xpb=0xf258c4c) => 0, hli=0F254FC0
...
124913.575  4904   6 r     PlayEnd 306734

[rverones]

No, the only way to delete the file is to stop the IVR service, then manually delete it. Nothing else uses that file.

 

Its a brand new server with 1 purpose. No other software is loaded or running aside from normal windows services.

 

If I stop the IVR service, delete the file, start it, they can record a new audio file.

[rverones]

Okay, another point I should consider. The file itself is usually approx 1MB. There are 7 lines going at once listening to this 1.wav file while the dispatcher is attempting to dial in on line 8 (seperate phone number). He gets into the system to record a new greeting (work information people phone in to hear) and gets disconnected as soon as he hits 2 (record).

 

At the time, yes, other ports are opened and listening to this greeting (1.wav).

 

Question is, shouldn't those people on the other 7 lines get disconnected?

 

I noted that while the dispatcher is recording the greeting for 2.wav (not used nearly as much by callers), the file goes from 640KB to 0KB (the file is deleted) and is built up again.

 

If this is the case, and if 1.wav is to be recorded while people are listening to that file, and it is supposed to be deleted, shouldn't they be the ones being disconnected?

 

You mentioned that the 1.wav file (static file) is fully read prior to the start of play. Is there a temp or .tmp file that I can search for that shows that this is the case and its working as intended? Maybe it is in the middle of your product copying/reading the file when they are trying to record it.

[rverones]

Also noted, sometimes, they record the greeting and when callers call in to hear the new greeting, those users keep getting sent back to the main menu as the 1.wav file did not save correctly.

[rverones]

Now we have another problem.

 

They re-recorded the file, and this time, when they go to listen to it, it keeps sending them back to the main menu.

 

When I attempt to open 1.wav, Windows Media player suggests its the wrong codec and cannot open it.

Using Sound Recorder (Windows program) is claims it is not a valid WAVE file.

 

We have to find a solution to this or we have to change products.

[rverones]

I did some further testing to this.

 

I created a 5th mailbox, and saved a 2 min greeting (that saved correctly after pressing 3 to save) as 5.wav

 

While listening to the greeting on 1 phone, I was able to succesfully record a new greeting and save it. I watched the file get deleted by the system and start from 1KB and is approx 713KB.

 

However, while having 2 phones listening to the greeting at the same time (lines 2 and 4 on the line status showed 5.wav being used), I was not able to record a new greeting and was disconnected when I pressed 2 to record a new greeting.

 

Is there an issue with more than 1 person listening to this greeting and locking the file in this way?

 

I am going to upgrade the system from 7.1.1 to 7.2 (noted this was available on the website) and retest this.

[rverones]

Okay, VG7.2 was installed.

 

We have come to the conclusion as follows:

 

1. We have some issues recording messages. Actually, no conclusion here. Sometimes they save correctly, sometimes they don't and become corrupted .wav files. We need a solution to this.

 

2. We know that after a succesful recording, all 7 lines can listen to the greeting without issue, at the same time, as intended.

 

3. We know, that after 1 person listens to the greeting, we can re-record or delete the file without it suggesting it is locked.

 

4. We know, that after 2 people listen to the greeting, at the same time, we can no longer re-record the greeting, and just get disconnected. We also cannot delete the file until VG is stopped.

 

We can only conclude there is an issue in one of the config type files that needs to be addressed, or there is an issue with the product being used in this way.

 

Any suggestions?

[rverones]

The customer is replacing the unit with their old one until this is resolved. They are not happy unfortunately and is causing major business interruption.

[SupportTeam]

We have some issues recording messages. Actually, no conclusion here. Sometimes they save correctly, sometimes they don't and become corrupted .wav files

Can you post a copy of the .WAV file which is considered corrupted? Along with ktTel trace capturing time when this file as recorded.

Please .ZIP up files before posing them.

 

Can you also tell us more about the system setup.

 

Which version of Windows i used on this system?

What other software is installed on this system?

 

If you think this is some sort of a filesystem based problem then you could try having the data files sores as a BLOB in database. This is the approach used when multiple systems need to play/re-record the same prompt.

(see: http://www.voiceguide.com/vghelp/source/html/moddbquery.htm section "Working with BLOBs")

[rverones]

I have attached a file that I saved that was not able to be opened.

 

Windows 2003 Server R2 Standard Edition

Service Pack 2

Running on an HP ML 150 G6 server with 2GB Memory, 1x2GHz Xeon CPU

Brand new out of the box server

Dialogic D120JCT board, using 8/12 lines

OS is running as a BDC in a 2 server domain.

 

There are no other apps running on the server

 

Example of how system is used:

 

Dispatcher calls into line 8 (diff phone number than lines 1-7 which are overlines), presses 1, then 1#, password#, 3, then 2 to record. This is where the issue comes up where they either record a file that becomes a corrupted .wav file, or it cannot record at all and they get disconnected.

 

Everyone else, calls into Line 1-7 (same # on an overline), listen to the greeting, press 1 for the information and listen to the 2 min# message. they can disconnect, hangup, or wait until the end of the message. the timeout takes them back to the main menu where they can listen to 2, 3 or 4 (diff mailboxes).

 

We are using the mailbox greeting as the .wav file for everyone else to dial into and hear.

 

If you are suggesting that the file is in fact being locked (unfortunately, i do not see any .tmp or .loc files) due to the usage like this, we shouldn't have to database this. Their old IVR system actually did all of the above correctly without issue.

 

Their old IVR unit is approx 14 years old and never had any file locking issues. However, if the only way of doing this is via making a database out of it, its not capable of doing what we were given the impression it would do.

Copy of 1.zip

[rverones]

Here is the KtTel file and more.

[SupportTeam]

ktTel was not attached. Can you please try re-posting it?

[rverones]

Sorry, thought it attached. Then had to wait for the moderator

1117_ktTel.zip

[rverones]

PS, server is online, but not connected to any phone lines at this time due to the issues. As soon as you have a possible solution, I would like to test it ASAP. Tx.

[rverones]

Any further updates or ideas as to what we are running into?

[SupportTeam]

At this stage we have not been able to reproduce this problem on our test systems.

 

The version installed on your system is not the most current version. We would recommend updating the system to the latest version of VG and see if you still get issues when using the current version.

 

To update to newest version just stop the VoiceGuide service and then install the new version over the top of existing copy. This way your .INI and configuration and licenses etc will be retained.

[rverones]

I just noted that 7.2.1 is now available. We just installed 7.2 yesterday.

 

On your tests, did you attempt to record a new greeting, while having more than 2 lines listening to the greeting at the same time?

 

C:\Program Files\VoiceGuide\data\VmWelc\1.wav is recorded via the standard greeting recording script.

 

We have the members call in on 7 lines at once, and the script points to that location and listens to the wav file.

 

If this is how you tested your system, and you were able to record a new greeting and overwrite 1.wav over and over while lines were in use to listen to that same file, without getting disconnected and without the same errors we are receiving, what is different that we need to setup?

 

Are you running your setup with the BLOB database setup?

[SupportTeam]

The test that we did was to call in on one line and record C:\1.wav (2 minute long) then after recording completed we sent in 20 calls on 20 other channels. While these 20 channels were playing back C:\1.wav we dialed in on 21st channel to record a new version of C:\1.wav

All went as expected. The second recording was made fine and resulted in a valid file that was played back to us afterwards as well.

 

ktTel trace showing this test is attached.

 

From your trace we see two problems:

 

1. Playback start attempts while recording is in progress.

2. Invalid headers attached to recorded files.

 

 

1.

 

Pleae note that while C:\1.wav has started recording and is still recording then no new playback of C:\1.wav can be made. There is no valid file to play back until recording is complete. Your trace shows some playback attempts while recording is in progress - with playback failing as expected.

 

If you want to be always able to play back a file then you need to set up a differnt system - using database BLOB approach, or copying a temporary recording file to C:\1.wav after the recording has completed.

 

 

2.

 

The WAV file that you posted has an invalid header. And your trace shows that for some recordings an invalid header was attached to file afterwards. This makes that recording unplayable. We have not seen this bug before and hence would ask you to test with a fresh VoiceGuide version (7.2 or 7.2.1 etc.) and provide traces form that version to see if you get these problems on your system when using the current VoiceGuide release.

The traces that you posted were not from v7.2

They were from a much older version.

1119_ktTel.zip

[rverones]

I will reinstall. I also appreciate your testing with 20 lines, it does show its well above the norm for this situation and we are unsure why ours is failing. My test on 2 lines showed its not working correctly and shouldn't have this issue.

 

However, for the install version, its direct from the website and says its 7.2. This I have no idea how to resolve as we haven't downloaded any other version of the product, and the visual of the script editor etc... looks like the correct product.

 

I should clarify, we installed 7.1.1 last week or so. We installed 7.2 2 days ago and had the exact same issue. The file we sent was from 7.1.1. No change in 7.2 and we have installed 7.2.1 today.

 

We actually don't need the playback to be playing while recording at all. This should in fact be sending the caller back to the main menu and not attempting a playback at all. Our suspicions in this case, was that the callers were the cause of the wave file corruption (headers or otherwise).

 

The other thought we have, can we "launch" the wave file recording into another folder once its recorded?

 

in other words, allow the line 8 recording to proceed as normal, calling into mailbox 1 and record to C:\Program Files\VoiceGuide\data\VmWelc\1.wav and save it.

Then, add in an extra choice for the person recording, to launch the recording, which is a command to delete the old 1.wav file in another directory where the playback is occuring. We would have a folder called C:\recordings\1.wav. This command would tell:

 

del c:\recordings\1.wav

copy C:\Program Files\VoiceGuide\data\VmWelc\1.wav to c:\recordings\

 

That would work fine for us and I know I would be able to add in a small app that would unlock that file and delete it.

 

Thinking further on that, maybe I can do the same in C:\Program Files\VoiceGuide\data\VmWelc\1.wav, however it would not solve the issue of callers calling in and possibly attempting to play the file being recorded.

[rverones]

I have reinstalled it and its in the Add/Remove programs as 7.2.1.

 

I will test again with the fresh install.

[SupportTeam]

 

 

The other thought we have, can we "launch" the wave file recording into another folder once its recorded?

The usual approach is to record into some temporary file, and then copy that file over to the file that is the one being played back all the time.
Your 'copy file' function should be able to handle a case where the copy fails as at that very instant the file is being read in by one of the lines for playback. Reading in file for playback takes at most about 50ms, and during that time that file is blocked by operating system from from deleted or overwritten.

One way to get around the blocking is to place file as BLOB into Database and read it back form DB.



Also, version below will show in the trace the WAV headers as they are updated after end of recording and as the file is read in for playback. It may be a good idea to use this version on your system so that if any issues occur we can see what headers VoiceGuide wrote and read back.

[old link removed]

[SupportTeam]

We actually don't need the playback to be playing while recording at all.

Then just use the Record module to record direct over your main file (the one that gets played back).

Any playback attempts will fail during the time when recording is made, but sounds like this is not an issue for your application.

[rverones]

alright, thats something I was looking at last night as well.

[rverones]

One way to get around the blocking is to place file as BLOB into Database and read it back form DB.

 

Do you have an example of how this is done? ie: in the database module in your app in the script editor, how does it query the database and play it back from the blob stream without writing the file to the harddrive?

[SupportTeam]

Please see the demo script C:\Program Files\VoiceGuide\Scripts\Database BLOB WriteRead\Databse BLOB WriteRead.vgs

 

But there is really no need to do this.

 

Just use a normal Play module to play back and a normal Record module to record.

 

Are you encountering problems with this straightforward approach? If yes then please post traces and the recorded file and we can see what actually happened.

 

(Please .ZIP up trace etc before posting).

[rverones]

If you read all the above thread, you will see this is exactly what we have ran into.

 

For each caller that comes in and is listening to the greeting, the wav files we are trying to record over, become locked and the system cannot record. Only way around it is to shut down the system and manually delete the wav file. We are sure this is not working as intended, but no one has given us a solution. We sent all records to you guys a couple of weeks ago and the BLOB database was the solution they gave as per the info above.

 

We were told to create the database and use the BLOB to run it. Problem we have in the C:\Program Files\VoiceGuide\Scripts\Database BLOB WriteRead\Databse BLOB WriteRead.vgs we are not entirely sure on the playback portion how its playing the file from within the BLOB. We want it to read from the database and not the harddrive to prevent the file from being locked.

 

As far as we can tell, the database will now read the file we create from our directory c:\IVR Files\1.wav and place it into the BLOB. We then have it call for that file and place it in C:\IVR FIles2\1.wav

 

The entire process seems redundant seeing as its just a copy and paste really, and my database person mentioned he is not sure how your demo writeread.vgs is reading it from the database without copying the file back to the harddrive.

 

We think, if its copied back to the harddrive for playback, we most likely will have the same issues with the file being locked by Voiceguide.

 

No, there are no other programs on the server using the files. There is no audio card to playback the files with on the system. They are played entirely by Voiceguide when a caller calls in and grabs it. Many people call in and listen to the file. Once 2 call in, the file becomes locked.

 

So basically, we just want to know if we can read the file directly from the BLOB stream without actually copying the file to the harddrive where it will be locked. If that makes sense to you

 

Thanks.

[SupportTeam]

On 19th November we provided a link to a special debug version of software:

Also, version below will show in the trace the WAV headers as they are updated after end of recording and as the file is read in for playback. It may be a good idea to use this version on your system so that if any issues occur we can see what headers VoiceGuide wrote and read back.

Can you update your system to that version and post traces and .WAV files if you still encounter the problem?

 

The traces you posted so far are all from older versions of VoiceGuide, not v7.2

[SupportTeam]

With the BLOB approach the file read back from DB would need to be saved in a unique filename, and that file deleted after it is played back.

 

As mentioned before it should not be necessary to do do this. Straightforward Record/Play should be fine. Please update system to the v7.2 with special debug tracing that we provided specially for you and post traces/.WAV files from that version.

[rverones]

I had 7.1 installed when we did this a couple of weeks ago. We installed 7.2 as per one of our last posts (being these are the only versions available for download) and had the same trouble. We did a fresh install.

 

My database expert read your last post on the forum and we will look into this and if need be, send the log info and wav files and anything else that we need to.

[SupportTeam]

Can you post the traces and the problem .WAV files created when v7.2 was used?

 

Ideally we would like to see the traces & .wav files created when you use the "_wavdbg" version that we provided especially for you.

 

To update you just need to stop VG service and then install new version over the top of the existing one.

 

(Please .ZIP up traces etc before posting).

[rverones]

Honestly at this point, we will have to redo what we did back a couple of weeks ago and send that to you. The log files are many (13 from Nov 22 alone) and the wav files were deleted and replaced many times via more tests and subsequently removed again for a fresh start.

 

We know the straight record/play service should work, but given the 2 weeks spent trying to make that work, we need a solution that will be a long term one, that is guaranteed to work as apposed to the chances we are taking with even 1 wav file being locked and not being able to be recorded correctly.

[SupportTeam]

Our recommendation is to install the "_wavdbg" version that we provided especially for you back on 19th November, and replicate the problem and post the trace files + the problem .WAV file.

 

This approach is the quickest way of resolving what is happening on your system.

[rverones]

I will do what I can. I installed that version back at that point, but as mentioned, the solution given to us was to create a database. We spent time doing this and the system was taken offline for a time while the customer continued to use their old system.

 

We will do a number of tests tonight and send all results.

 

1. With a BLOB method without a random generator.

2. With a BLOB method with a random generator.

3. With a simple record/play method.

 

We have to test each of these at this stage to satisfy the customer.

 

I will send each one as we test for you to look at if there are errors.

 

Errors on #3 should be straight forward. The recording will work the first time. Playback will work for all 7 other phone lines. During playback, we will be attempting to record the file 1.wav again. At this stage, if it works now, thats great, we will test again. If it does not work, we will end the test and send you the log files.

[SupportTeam]

Can you first do the simple Play/Record test with the "_wavdbg" version, and provide those traces and .WAV files.

[rverones]

Please find attached our latest test.

 

5.wav was recorded succesfully with our basic record script. When 1 person called in and listened to the wav file, we were able to succesfully record a new 5.wav file. When a caller called in during that recording, the system hung up on them.

 

When 2 people called in to listen to the new 5.wav file, we tried to record a new 5.wav file. The system hung up on us and we were not able to delete the file any longer either through the file system or with the application.

 

We shut down the system and were able to delete the file.

5.zip

1204_1752_vgEngine.zip

[SupportTeam]

Thank you for the traces. Looks like a bug has crept into the playback function. When playback was being attempted on a file that was currently recorded, the file handle used for playback was not being closed afterwards. This did not affect future playbacks of newly recorded file, but it did affect any future re-recording and deletions of that file.

Please update your system to this version of Voiceguide v7:

[old link removed]

The above version fixes that bug.

Please note that you will still not be able to start playback on a file that is currently being recorded. To workaround that you should record new files to a temporary unique filename and then copy them across when recording is completed (use a VBScript or batch file when copying the file over which tries to copy multiple timesm, until copy over succeeds, jsut in case copy is attempted during the short time when file is open for reading in).
A unique filename can be created using $RVs like this: temp_$RV_HH$RV_NN$RV_SS$RV_LINEID.wav

[rverones]

Okay thanks for that.

 

I am guessing the log does not show the file is locked and that the only way we could delete the file was to shut off the service. I am thinking that even if we create the batch file to consistantly attempt to copy 1.wav to another folder where it is being played back from, the play back 1.wav file will still be locked.

 

We will test this.

[SupportTeam]

The file is only locked when it is being read in, or recorded.

The file is not locked the entire time the contents are played back.

At read in time the file is locked for a very short time.

At most about 40ms if read from disk but most of time the file is cached so read in time is <1ms.

[rverones]

I think you guys have misunderstood. The file remains locked many minutes after all calls are finished. We cannot manually delete the files during testing even after the calls are finished and hung up. This is the main issue. Even though you suggest this is not the case, our hours of testing on this is showing otherwise.

 

If the file was only in lock for 40 ms or 50 ms as mentioned earlier by another tech, we should be able to overwrite the wav file 10 sec after calls are either running or a few sec after they are finished. This is not the case and thus the main reason of all of our postings here.

 

There are no other apps running that use the files. Only AFTER we shut off the Voiceguide service, can we delete the file. We even waited many minutes after all calls are completed and still could not call in to overwrite the wav files or delete them until after the VG service is reset.

 

This was the entire reason we believe we were told to go the BLOB route.

[SupportTeam]

The new version that we supplied fixes the file locking bug that you encountered.

 

We confirmed this it was a bug and that we have fixed it in the new release of software.

 

Have you installed the new version that we provided?

 

The 40ms locking is what happens normally in correctly functioning software if file needs to be read in from hard disk for the first time.

[rverones]

I will be happy to test it tomorrow (monday AM).

 

Thanks much.

[rverones]

We are about to test this.

 

However, before we test the playbacks and re-recordings, we already ran into an issue with our initial recording.

 

2.wav did not record correctly, while the other 3 files 1 3 and 4.wav all recorded correctly.

 

What could be causing this? If 3/4 files record correctly, we need to figure out how to be sure they all record correctly.

 

We will continue with our testing as well.

1206_ktTel.zip

[rverones]

I can say now, that after testing 3 call ins into the system, that while our test wav file, 5.wav was being listened to by more than 2-3 lines, we were in fact able to record over those files. We watched 5.wav go from a 500kb file to a 0kb file and grow from there.

 

We were then successful at doing this more than 2 times without issue.

 

The only issue we have right now, is why our 2.wav file is not saving correctly. Its not being listened to, and we are able to run the record session without errors.

 

We confirmed that the script is setup the same for each wav file being saved. 2.wav did this twice.

[SupportTeam]

Can you please post the 2.wav file, along with traces capturing time when file was recorded.

(Please .ZIP up before posting).

[rverones]

Sorry, we didn't keep them. If it occurs again, we will send them to you.

[SupportTeam]

Looking through the supplied traces were able to see the issue that you encountered.

Please update your system to the version below. Version below fixes this problem.

[old link removed]


This new version also has an improvement to the way recording over existing files is done. If the file exists VoiceGudie will automatically record into a temporary file, and rename that temporary file to the the right filename when recording is completed. This means that you will no longer have to do the 'record into temp file and then rename' in your script. This is now all done internally by VoiceGuide.

[rverones]

I will download this and keep it handy if it occurs again.

 

the current release seems to be working correctly when it comes to overwriting wav files that are in use by other callers now. As long as the files being recorded do not save with corrupted headers, things should be fine.

 

the menu options I setup allows the recorders to listen to their current messages and re-record them if needed.

[SupportTeam]

We recommend updating your system to the new version.

You will get the corrupted headers bug unless you update your system to new version.

[rverones]

We monitored the system for the past 2 weeks and everything was great. We did not apply the last patch you posted, but we did have it downloaded.

 

Finally, 1.wav was corrupted again, and we had to manually delete (not locked either, so that issue is well taken care of.

 

We then applied the patch you posted from Dec 7, 2010.

 

We reset the system and a new recording worked. 2 more recordings were successfully setup, however, the last one this AM failed and was corrupted.

 

We are resetting the system again. If it happens again, we will post the logs. The current logs are too large to post.

[SupportTeam]

Can you post the sound file itsef. (.ZIPed) ?

[rverones]

Sorry no. It was deleted as soon as it was discovered so as to get the system running. I will make copies of it if it occurs again.

[SupportTeam]

Can you .ZIP up the logs and post them or email them to support@voiceguide.com? .ZIPed up logs should not be that big.

[rverones]

In total, they were over 4mb and max we can submit is 2mb. We did a number of resets over the past few days. Seems stable again.

 

If e-mail is larger, I can send all the files that way.

[SupportTeam]

Please email .ZIPed up traces to support@voiceguide.com

Any size is fine.

Please indicate the rough time when problem happened. Then we know where to look in the traces.

[rverones]

I have e-mailed the audio file along with the logs for you to look over. It happened again this AM (watched the recording and completion).

 

I halted the system, copied the logs and 1.wav file and zipped them for you to look over.

 

Thanks.

[SupportTeam]

We have received the emailed trace.

 

In the trace we can see that the version of VoiceGuide used on this system is the 5th December build:

 

002109.795 4156 1 info ktTel_SR60 v7.2.2, build: Dec 5 2010 21:13:21

 

000017.290 19 4 3 ev CallState TDX_SETHOOK_DX_ONHOOK, crn=1000310a, iEvent=2 ,1,0,32,,,]. vgEngine v7.2.3991.38371 (2010-12-05 21:19:02.82)

 

and not the 7th December patch build.

 

The patches have now been rolled into the main release. Suggest that you download the latest version of VG downloadable from our WWW and run the install. Then confirm by looking at the start of the trace files that the correct version is in fact running on this system. The build dates are shown in the trace file.

[rverones]

Not sure what to tell you. We installed the version you posted for us a couple of weeks ago.

 

I will download the latest from the website and install.

[rverones]

112918.247 5 é-----------------------------------------------------------------------------------------------------

112918.263 5 vgEngine version : 7.2.3994.39528 (RELEASE Build)

112918.263 5 created on : 2010-12-08 21:57:37.35

112918.263 5 AssemblyLocation : C:\Program Files\VoiceGuide\vgEngine.dll

112918.263 5 LastWriteTime : 2010-12-08 03:15:24

 

I have confirmed this in the latest log file after downloading your updated version from the website.

 

We will continue working with this and see if the file corrupts itself again.