deadlock_resolution

[alperenalbay]

Describe the bug
When using File Converter v2.2 on Windows with non-English locales (specifically Turkish tr-TR in this case), the conversion progress bar freezes at
the beginning and the UI does not update or indicate when the conversion has completed, even though the conversion might eventually finish in the
background.

This issue is caused by two main factors in v2.2:

1. FFmpeg stdout deadlock: FFmpeg is started with -progress pipe:1 and RedirectStandardOutput = true , but stdout is not consumed continuously by the
   application. This causes the OS pipe buffer to fill up, deadlocking the ffmpeg.exe process (which stops writing and hangs).
2. Missing Language Probing Path: The FileConverter.exe.config file lacks the runtime entry, meaning the
   application fails to locate the satellite localized resource assembly FileConverter.resources.dll in the Languages\tr-TR directory. This failure to
   resolve resources triggers UI errors and freezes.

To Reproduce
Steps to reproduce the behavior:

1. Set the application language to a non-English language (e.g., Turkish tr-TR ).
2. Right-click on a media file (e.g., a .mp4 video) in Windows Explorer.
3. Select a preset that triggers FFmpeg (e.g., "To Mp4").
4. The conversion window starts, but the progress bar remains frozen at 0% or shortly after starting.
5. The UI does not show "Finished" even after the output file is fully generated in the background.

Expected behavior
The progress bar should update in real-time based on FFmpeg progress, and the window should show "Finished" (or close automatically) once the output
file is ready.

Screenshots and Logs

Settings.user.xml Snippet:

<ApplicationLanguageName>tr-TR</ApplicationLanguageName>
<ExitApplicationWhenConversionsFinished>false</ExitApplicationWhenConversionsFinished>
<DurationBetweenEndOfConversionsAndApplicationExit>3</DurationBetweenEndOfConversionsAndApplicationExit>

Diagnostics Log Snippet (e.g. Diagnostics13.log):
The logs reveal that the execution starts, but the output capture stops exactly after 20 lines of progress updates (~10 seconds of elapsed time) due to
the pipe buffer limit blocking the write operations of ffmpeg.exe :

frame=   56 fps=0.0 q=37.0 size=       0KiB time=00:00:01.80 bitrate=   0.2kbits/s speed=3.51x elapsed=0:00:00.51
...
frame= 1979 fps=191 q=37.0 size=    2560KiB time=00:01:10.83 bitrate= 296.1kbits/s speed=6.83x elapsed=0:00:10.36

Desktop:

• OS: Windows 10/11 64-bits
• File Converter Version: v2.2.0.0 (64-bit)

Additional context

• The issue is solved by:
1. Adding under the tag in FileConverter.exe.config so that .NET can find the localized
assemblies.
2. Disabling RedirectStandardOutput and removing -progress pipe:1 from FFmpeg arguments (relying on parsing stderr for progress) to prevent
stdout buffer deadlock.