Console flashing bug when compiling & executing ffmpeg operations

[nednoodlehead]

When compiling a script that includes ffmpeg (only tested while threading), each time an ffmpeg operation is called, a console window opens immediately, then closed (console flashing). This error does NOT occur when in the IDE, which makes me believe that this may be a pyinstaller problem. On the other hand, the path (aka executable) that is calling said command prompt to flash is the .exe of ffmpeg

clicking the "non-ffmpeg test" button (which is just a print statement) does not cause this console error, playing the music that is loaded will cause the console error.

The repo is here: https://github.com/nednoodlehead/ffmpegthreading

The ReadMe includes all the steps to reproduce this bug.

[brentvollebregt]

Is pydub/ffmepg needed for the minimal reproduceable example? Is there really no way to show this issue without the library? If not, sounds like the issue is related to the library.

[nednoodlehead]

pydub is the logical interface I use to interact with ffmpeg. I mention how the compiled ffmpeg code is the problem. Whether that is because of compiling (pyinstaller) issues (works perfectly in IDE) or because ffmpeg is bugging out

[brentvollebregt]

Ok, so pydub is needed for your example - is tkinter and threading relevant to the minimal example? Or are they absolutely needed and the usage of pydub after packaging will only fail when using both tkinter and threading?

Trying to get your example as small as possible to help identify the cause.

[nednoodlehead]

After fidgeting with a few different variations of the script, I noticed a few things. 1). Using no tkinter GUI, combined with creating a second thread to sort of behave like the underlying tkinter thread, the bug did not occur. One thread was running, and the other called the ffmpeg operation successfully. I can't pinpoint exactly what differentiates the thread I had running versus the tkinter GUI. Perhaps the GUI is 'waiting' on an action and behaves that

2). Remaking the GUI in pyqt5 also produces the exact same bug. So it's not Tkinter specific

3). Removing threading (although 100% required on project) does indeed produce the bug

Only variable that persists is that a GUI will always produce the bug. I'm strongly assuming that it has something to do with the underlying GUI structure. Perhaps how it handles those sort of 'external' calls like that.

I added the two files (One for a GUI-less window and one for a PyQt5 window) to the repository mentioned previously

[brentvollebregt]

although 100% required on project

I understand this, but we are trying to figure out the specific issue, not fixing your project sorry

that a GUI will always produce the bug

Saying the issue is related to a "GUI" is very broad, thinking more toward the implementation of the GUI (mechanisms behind it) may offer some insight. Your #1 hints it may not be threading but potentially it's a different scenario.

Are you using the "Console Based" option? (not window based).

You potentially could add a global exception handler to your code (around the start) and output any errors to something like a file.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. Remove stale label or comment on this issue or it will be closed in 5 days.

[github-actions[bot]]

Closing issue due to no activity in more than 60 days.