"Cannot open dump file." error when -dumpfile contains non ascii symbols

[Max Osiponok]

Hi!

Summary of the bug:
How to reproduce:

% mplayer -dumpaudio "C:\Users\Администратор\AppData\Local\Temp\S2T_Bot\Dwvumufile_37.mp4" -dumpfile "C:\Users\Администратор\AppData\Local\Temp\S2T_Bot\Dwvumufile_37.mp3"

This gives me an error ("Cannot open dump file."). After changing the -dumpfile path to the one without cyrillic word the audio was dumped successfully.

Version: MPlayer sherpya-r38135+gb272d5b9b6-8.3-win32 (C) 2000-2019 MPlayer Team
...

[beastd]

Hi!

I can reproduce the problem here on Windows.

Didn't yet have time to take a close look :(

On another note, if the file name part of the path specified in -dumpfile contains non-ASCII characters, the file gets written but the name is not coded correctly. Depending on what I find out, I might open a new bug report for that problem.

[beastd]

So for me the problem is, that there is a mismatch between the encodings :(

The given file name is UTF-8 encoded, but the fopen routine expects local code page.

So the problem with the file name getting garbled, is the same issue. If you specify just a file name without a a leading path with non-ASCII characters, the file will be written, but if the name contains multibyte characters they will be encoded as fixed byte characters if the local codepage is set to a fixed 1-byte encoding. OTOH if the leading path already contains multi-byte characters and the local code page is fixed 1-byte, we won't output anything because we and fopen don't create directories, and the mis-interpeted path name usually just doesn't exist.

Can you build MPlayer yourself?
If yes please try if your problem goes away with the patch I just attached to this ticket?

0001-XXX-Windows-Recode-dump-path-to-local-code-page.patch​

It's just to be sure we are seeing the same problem. It won't even compile for non-windows builds... ...though for Windows-builds it might be acceptable workaround as long as we don't have a proper fix.

A real fix will be more involved.

[beastd]

Hi Reimar,

I just noticed you originally committed that code in mpcommon.c (SVN r35962) that does the recoding to UTF-8.

I wonder if you have a good idea how to proceed with this. The whole situation seems a bit messy for mingw. E.g.:

• we want to be able to open files outside the legacy code page
• messages we print with mp_msg seem to be expected in UTF-8
• stdio file functions expect the legacy cp, OTOH mplayer stream file works with UTF-8 and legacy cp

[reimar]

Switch to stream interface should solve it, patch on ML, but not tested on Windows

[beastd]

Should be fixed with MPlayer SVN r38239 .

Feel free to re-open if it still doesn't work for you.