It seems that fluent-ffmpeg is no longer maintained, but I'd be curious to understand what causes the issue. I couldn't replicate it, unfortunately (even on Windows 10). What I thought initially was a possible deadlock with the std streams but it doesn't seem to be the case. @laggingreflex did you manage to find what's the underlying problem? It would be easier to find a less "hacky" fix.

@federicocarboni Thanks for the reply!

I haven't found the root cause.

Another solution (than this fix) that works for me is if I use a retry function (with a timeout).

I've been using ffmpeg and this library in a project for a long time and this has only occurred on a particular setup - a large set of video files (150k files, 2.7TB) on a USB HDD. I should add that there were also bad sectors on this HDD that I repaired (chkdsk) earlier. My project involves ffprobe-ing a lot of those files and a lot of them have been failing seemingly randomly. I'm suspecting this whole particular setup (the HDD and/or act of probing a lot of files) might have something to do with it. Since I can't even seem to reproduce the issue on same files that failed when I try again.

PS: I tried your library (eloquent-ffmpeg) as well - same issue (fails randomly, works on retrying).

@laggingreflex
Does stdout emit the close event even when it gets stuck? If it does, a cleaner solution would just be to move the code that's currently running on exit into stdout's close, and since we already have ffprobe's output on close we can just kill ffprobe if it hasn't exited already.
The issue is difficult to reproduce so I just added my best guess.

CI tests seem to be failing because mocha was updated and it no longer supports Node.js 8, which is a test target for this project.

Does stdout emit the close event even when it gets stuck?

It doesn't. Just "data" event. Here's what console.log(ffmpegProcess) looks like: https://gist.github.com/laggingreflex/252585944ea4369efadc37076aed6fdc

  _eventsCount: 2,
  _maxListeners: undefined,
  _closesNeeded: 3,
  _closesGot: 0, << if this is a counter for close events, none received
  connected: false,
  signalCode: null,

(it's after a 5000ms timeout)

The issue is difficult to reproduce so I just added my best guess.

Definitely. Please feel free to give any other debugging pointers, I'll try them out.

Or I'll update if I come across anything more useful.