Don't give subprocess our stdin, give it os.devnull instead. #231
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When calling subprocess.Popen to call ffmpeg, the process inherits our standard input. Apparently ffmpeg modifies the terminal parameters if it is given a TTY on standard in. Usually this isn't a problem, because ffmpeg sets them back to what they were when it is done. However if you're calling
AudioSegment.from_file()
orAudioSegment.export()
from multiple threads at once, the multiple ffmpeg process race each other in setting/getting the shared terminal parameters.On my machine at least, this pretty consistently leaves my terminal hosed when my program exits -- turning off echoing, and other weirdness, which is only fixed by blindly typing
reset
into the terminal.The easy solution seems to be to just give ffmpeg/avconv a file descriptor to
os.devnull
on stdin, which fixes the problem for me. Tested with ffmpeg, not with avconv, but I would be surprised if it broke anything.