Audacious

I have created *. DMP file when beautiful. Today it is attached to the same bagu.Tak today try to play and flow describe the steps to reproduce the crash. Debugera I net.V brief can you describe the steps play Crush:
1. Player file stored in the archive is downloaded sashego site.
2 opens it in winrar.
3 drag and drop a file folder mu

So the crash occurs when you play a particular file? Can you attach that file to the bug report?

Please attach the file you are trying to play to the bug report.

On Windows, I verified that the player has two issues when some non latin characters (like cyrillic) are used with local files:

1) if the file to load has some non latin characters in its name, the player will just fail to load it. To reproduce this defect, rename an mp3 file by adding some cyrillic text in its name (you may simply copy and paste some text from the comment made by the user Денис Потапов, if you don't want to waste time in adding new languages and keyboard layouts on your Windows machine ^_-).

2) The player will load its settings from C:/Users/<MY_USER>/AppData/Local/audacious/ on Windows Vista/7 or from the "Documents and settings" tree for previous versions of Windows. If <MY_USER> has some non latin characters, the player will brutally crash when it starts.

Both troubles seem to be caused by the vfs_local plugin, now bundled into libaudcore library: this internal plugin relies on ASCII function _open() or fopen() and, evidently, they are not able to handle this particular condition.

If I can say my opinion, I STRONGLY discourage the usage of the "ccs=<encoding>" flag of fopen() because, from my memories, this would mean that the user has to install the recent Visual C++ runtime himself, if it has not been installed by other installers (sometimes, some of them do that).

I did an experiment and I was able to overcome the problems with some hacks, by excluding vfs_local and adding again the "file" scheme to GIO plugin.
These tricks have solved the troubles and perhaps it would be better to do the opposite, GIO plugin bundled inside the core (which it is already GLIB based interely) and the unix I/O plugin outside, which it could even not compiled, at least on Windows.

But I must say that I do not know all drawbacks of such changes, although it seems quite safe for Windows because, from the sources of GLIB, the GIO functions are based on CreateFileW(), ReadFile() and WriteFile(), which they are the key functions for any I/O access.

Sincerely,

Carlo Bramini.

There is nothing inherently ASCII about fopen() and all the other standardized functions, only Microsoft decided not to support the character set that the rest of the world uses (UTF-8). So without using wmain and all the other non-standard UTF-16 functions Microsoft wants you to use (CreateFileW etc.) it is impossible to have full Unicode support. And I'm not aware that GCC/MinGW supports wmain (correct me if I am wrong).

Edit: Using GetCommandLineW might be an option, and then converting to UTF-8 for use with g_open(), g_fopen() wrappers (GIO is different and not necessary).

John Lindgren wrote:

There is nothing inherently ASCII about fopen() and all the other standardized functions, only Microsoft decided not to support the character set that the rest of the world uses (UTF-8).

Yes, that's what I was talking about, perhaps I explained wrongly (sorry).

So without using wmain and all the other non-standard UTF-16 functions Microsoft wants you to use (CreateFileW etc.) it is impossible to have full Unicode support. And I'm not aware that GCC/MinGW supports wmain (correct me if I am wrong).

I have an up to date MinGW environment and it seems that there is not support of wmain() or wWinMain().
MinGW-w64 claims to have it, but I have not tried.
Unfortunately, I'm not expert of GLIB universe and using an hacked GIO plugin was for me the fastest way to check the origin of the problems...

Edit: Using GetCommandLineW might be an option, and then converting to UTF-8 for use with g_open(), g_fopen() wrappers (GIO is different and not necessary).

The fact that the player was also using argc/argv escaped to my attention, using wmain() would help although all this can be also obtained without big troubles with GetCommandLineW() and CommandLineToArgvW() as you wrote. If I can say my opinion, it seems strange that the argc/argv encoding problems were not faced by GLIB people, perhaps there are already some utilities for recovering those values as GLIB expects, to be put into something like:
#ifdef _WIN32 ... #endif

GLib handles argc/argv with g_locale_to_utf8(). So, just as in current Audacious, Cyrillic characters are handled fine if the 8-bit code page in use is CP1251 (as would be the case with the Russian edition of Windows), but will not work on an English (or other Latin-based) edition of Windows that is using CP1252.

Anyway, all this discussion is irrelevant to this bug report. There is no indication that the crash in question is related to character sets at all; anyway, it appears from the video that the reporter is using the Russian edition of Windows, so Cyrillic characters would not be a problem for Audacious.

Edit: And you can also see from the video that Audacious started up, opened the files, and read the Russian tags from them without any crash. It was only when trying to play one of the files that it crashed. So the problem is presumably NOT related to file access, but rather decoding or output.