Opened 5 years ago

Closed 4 years ago

#2363 closed defect (fixed)

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

Reported by: Max Osiponok Owned by: beastd
Priority: normal Component: undetermined
Version: unspecified Severity: normal
Keywords: Cc: reimar
Blocked By: Blocking:
Reproduced by developer: yes Analyzed by developer: no

Description

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
...

Attachments (1)

0001-XXX-Windows-Recode-dump-path-to-local-code-page.patch (897 bytes ) - added by beastd 5 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 by beastd, 5 years ago

Reproduced by developer: set
Status: newopen

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.

comment:2 by beastd, 5 years ago

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.

comment:3 by beastd, 5 years ago

Cc: reimar added

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


comment:4 by reimar, 4 years ago

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

comment:5 by beastd, 4 years ago

Resolution: fixed
Status: openclosed

Should be fixed with MPlayer SVN r38239 .

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

Note: See TracTickets for help on using tickets.