0

I am using a FilesystemWatcher class to convert audio to a listenable format as they come in. This worked perfectly for a while, until right around the time we upgraded to 4.5 on that server. Now, to get it to work, I need to debug it and set a breakpoint so the method does not exit before the process runs.

It only takes a few milliseconds for sox to convert the audio. Setting a Thread.sleep(10000) doesnt fix the issue. Downgrading the project to .net 2.0 did nothing.

What's really frustrating, is process.WaitForExit() seemingly does not block. While debugging, I step right over it and wait until the file shows up in the folder.

As always, I really appreciate the assistance.

Attached is the relevant code:

    void FileCreated(object sender, FileSystemEventArgs e)
    {
        string newname = String.Format(@"{0}{1}.mp3", _mp3FolderPath, e.Name.Replace(".wav", ""));
        string soxArgs = @"-t wav -r 8k -c 1";
        ProcessStartInfo p = new ProcessStartInfo
        {
            FileName = _soxPath,
            Arguments = string.Format("{0} {1} {2}", soxArgs, e.FullPath, newname),
            CreateNoWindow = true,
            UseShellExecute = false,
            RedirectStandardError = false,
            RedirectStandardInput = false,
            RedirectStandardOutput = false
        };

        using (Process process = Process.Start(p))
        {
                process.WaitForExit();
                Thread.Sleep(10000);
                //process.Close();
        }
    }
Ehren
  • 171
  • 3
  • 14
  • 2
    Perhaps the program just starts a second process and then exits? – Lasse V. Karlsen Mar 24 '14 at 12:42
  • 1
    A process is highly likely to *fail* in this kind of scenario, it won't be able to open the file since whatever process created/wrote the file still has it opened. You'll at least have to check the ExitCode, no guarantee that a program actually sets it. The only solid counter-measure against this is copying the file yourself. – Hans Passant Mar 24 '14 at 12:46
  • @LasseV.Karlsen that was exactly what I was thinking - a number of tools do that - sometimes feeding things to a daemon, sometimes where the launcher has been replaced with a script, etc – Marc Gravell Mar 24 '14 at 12:46
  • As far as I can tell `sox` does not spawn a second process or such (it does the work itself) so i'd bet ons Hanses suggestion. I'd too check the exit code, and then parhaps redirect stdout/err to see what the program might tell us... At least to me it seems natural to listen to what the unexpectedly behaving process might want to whisper in our ears. – MrPaulch Mar 24 '14 at 12:59

0 Answers0