Issue With Temp-file Deletes (vbs/tts)

[ktruk]

I have a serious issue with the temp-file delete process that currently operates.

 

I am using VG 5.2.5062 on win2003 (with fast SCSI disks)

 

While running a stress-test, 8 channels of VG create dozens of temp-files (TTS-WAVs & VBS files) every few seconds, over the course of an hour several thousand can build up in the temp-directory, these consist of VBS script files and TTS wav files. The cleanup process currently deletes these files hourly, but the cleanup causes the machine to freeze for up to 20 seconds, causing lines to time-out and calls to be dropped. This is causing me some big headaches and I could do with a permanent fix for this...

 

Options / Thoughts: (in order of preferred first:)

 

1. Provide a way to cleanup via the script thats running, perhaps build into 'onHangup' a process that clears all temp-files based on the line number that has just been cleared when the call ends. (My Preferred solution, see below). This keeps files to a minimum, is easy to do and is self-maintaining.

 

2. The cleanup process could (as-is) run more frequently, perhaps every 5 mins, (or as specified in the VG.INI, some param to set this only when needed maybe?). Possible issues for longer-call durations.

 

3. Rename the TTS files to include a timestamp (like the VBS files) IF the TTS files were 'time-stamped' then, the WAVs and VBS files could easily be deleted using a wild-carded filename based on the time stamp, rather than creating a collection of files based on a scan of their create time-dates and having them deleted one-by-one in a tightly-run loop. There are 2 further possibilities:

 

• A) Just add the time-stamp to the TTS files using the existing VBS format, eg: vbs_line_count_timestamp.vbs / tts_line_count_Timestamp.wav.
• Reorder both filenames so that the timestamp comes first, eg: vbs_Timestamp_Line_Count.vbs and tts_timestamp_line_count.wav. This makes it potentially more effeciant to do a line independent wildcard delete. eg: tts_112300_Line_count.wav, can be deleted with 'tts_9*.wav'. and run after 10am (so that last hour retained), OR, run every 10 mins, and catch every tts_112*.wav by looking back every 10 plus minutes. (ie: build the wildcard based on the current system-time). (could miss some files if a time-slot fails to run)

 

4. Build in some-form of 'yield' or shell-out to a separate thread/exe so the VG thread doesn't become blocked with the delete process. The shell call could come when the cleanup process schedules or via the hangup process. Perhaps combine with Option 2 to call as frequently as needed.

 

My own *temporary* solution is to add my own VBS script to the OnHangup script with the following code:

 

'script to delete temp files
dim fso
dim vg
debug = false							'<set true to keep temp-files (do via Global-RV)
iLineId = $RV_LINEID
if not debug then
   temppath = "c:\program files\voiceguide\temp"		'<better if this was an RV (do via Global-RV)
   set fso = createobject("Scripting.FileSystemObject")
   call fso.deletefile( temppath & "vbs_" & iLineID & "_*.vbs", false)
   call fso.deletefile( temppath &"tts_" & iLineID & "_*.wav", false)
end if
set vg = CreateObject("VoiceGuide.CommandLink")		'<Optional? use fail path!
vg.Run_ResultReturn iLineID, ""				'<Optional
set vg = nothing					'<Optional

 

This script is set to run at the end of every call via the the hang-up script. (The VBS module must be set to 'run until complete' or it attempts to delete itself before it has finished).

 

This appears to work !!!

 

BUT - Questions:

1. Is there anything wrong with this approach?

2. If not, could this be built into the on-hangup processing?

3. If not, could you implement any of the other options above?

 

PS: I know that I am asking for changes to the older 5.2.5062 codestream, but the same considerations must be present in your v6 and v7 products too. If you can make a change to the v5 code - it must be the 5.2.5062 (or newer) codestream for me.

[SupportTeam]

The OnHangup VBScript approach is fine and there are no problems with using it if you find that the volume of temporary files generated is so large that it needs cleaning up more then every one hour.

 

Another solution would be to create your own separate cleanup process which runs (periodically) in a background and deletes the files. You can query the files' 'last changed' timestamp property to determine whether the file should be deleted. This can be a VBScript started by the Windows Scheduler or just the VBScript running in a continuous loop (with a short wait time in between loops).

 

v7 is designed differently and would not encounter this issue (cleanup is a separate low priority process in v7)