Cannot play some files with non-latin characters

[anb0s@…]

Hi,

i'm new to Jajuk. I can select and add files with russian names (cyrillic) in Jajuk, but if i double click on them nothing happens. Other english / german filenames are working.

Regards, Andre

[anonymous]

Please provide the operating system you use.

If under MS Windows, this should have been fixed already (see #1267) by using JNA and DOS short names but may fail in some rare case (like when using some kind of NAS / network drive).

Where is your music located, on your hard drive ? USB drive, Network drive ?

[anb0s@…]

I'm using Windows 7 x64 with: java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot?(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)

My music is located on local hard drive.

[bflorat]

OK, this marks off potential issues. This may be a problem related with Seven or the 64 bits version even AFAIK, this OS (even in 64 bits) still manages the file systems the same way (and problems related with mplayer were caused by some file system and file names issues).

To begin, I'll like to try to reproduce under my Windows XP / 32 bits to elimimate (or not) the Seven / 64 bits context. Please send attach a sample MP3 file that causes your issue to this ticket (use the "attach" button above) or send it to  http://www.florat.net/upload/d/d3/UmFuZG9tSVadMQU8yCI7hTZWr%2AYK4B5pzU6pWPqOZXhLirlwHqa62-2XtpfZO2ip9hloICcgUKk.png .

[anb0s@…]

Batch file to start Jajuk with 32-Bit-JVM on 64-Bit Windows

[anb0s@…]

sample file with cyrillic name

[anb0s@…]

Hi,

i just tested the file with Winbdows XP 32-Bits and it works. I found it is related with 64-Bit JVM and created a batch file (attachement) to start Jajuk with 32-Bit JVM on Windows 7 x64:

java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot?(TM) Client VM (build 14.3-b01, mixed mode, sharing)

If you copy the file jajuk_x32.bat to Jajuk folder and start, it should play the attached mp3 file.

I hope it helps.

Regards and Thank You!

Andre

[bflorat]

Thanks a lot Andre for your efforts and patch.

@team : The strange thing is that the file names issues should come from mplayer, not java itself so if only switching to a 32 bit JRE makes the trick, it probably means the the Process class is different from 32 bits to 64 bits JVM and that it affects mplayer a way or another ...

@André : We may consider to add this patch to official jajuk .bat file but the user should then install 32 bits JVM and may want to install it to a specific path, right ? so it's a problem to use an absolute path to java command. however, as we probably have no regular way to find a 32 bits JVM, we could keep your PATH update because :

• if the 32 bits JVM is installed in the regular path, it will be used, otherwise, the system will find any java executable it finds (as we finaly launch the 'java' command without full path)

• However, I don't like much to set the JAVA_HOME environement variable to a possibly non-existant path. To begin, is it actually required ? (not for me here under Gnu/Linux?), could you please try your test again without this line ?

[anb0s@…]

Hi,

I'm glad I could help! After trying a lot of mp3 tools i'm very happy with jajuk. Thanks a lot you guys!

Yes, it works without setting JAVA_HOME variable. I attached new batch file (jajuk_x86.bat) with some enhancements:

* env variable %ProgramFiles?(x86)% is used for default location

* user can pass different path as first parameter or change it (line 16)

* check if path exists and set PATH env. variable, otherwise print out warning message

* show used path if exist

* show java version

I attached a log file from x64 JRE (jajuk_log.txt). I saw some error messages like 'Can't load IA 32-bit .dll on a AMD 64-bit platform [AWT-EventQueue?-0]'.

Maybe I can help with mplayer and x64 JRE if you give me some hints where to get code (repository) and start. I'm C/C++/Java developer.

Greetings,

Andre

[anb0s@…]

enhanced Batch file to start Jajuk with 32-Bit-JVM on 64-Bit Windows

[anb0s@…]

Jajuk log file from x64 JRE

[bflorat]

Thanks André for the patch. I checked it in (with minor changes) into 1.8 branch. Will be available tomorrow at  http://integration.jajuk.info/hudson/job/Jajuk%20Daily%20Build%20-%20Maintenance/

On the issue itself, check #1267 to get history on the mplayer almost bug under Windows (requires DOS filenames). The java code that simply launches the mplayer process is available at  http://jajuk.svn.sourceforge.net/viewvc/jajuk/branches/maintenance-1_8/src/main/java/org/jajuk/services/players/MPlayerPlayerImpl.java?view=log

If you need to full dev environement, please see our dev guide at http://jajuk.info/index.php/Java_Developer_Guide .

Thanks.

[anb0s@…]

I installed the build #335 (26.12.2009 06:00:10) and it works with jajuk.bat. Thanks!

I will setup development environment with eclipse and try to go deeper in to code.

[anb0s@…]

Test program for starting mplayer.exe with jna 3.0.5 and 3.2.4

[anb0s@…]

It looks like the problem caused by JNA version 3.0.5 used in jajuk. From description it supports only x86 on windows: "Includes support for OSX (ppc/x86/x86_64), linux (x86/amd64), w32 (x86), solaris (x86/amd64/sparc/sparcv9) and freebsd (x86/amd64). "

I attached small test program to start mplayer.exe. The program uses the code from jajuk to get short file names (NativeFunctionsUtils?) and new JNA version 3.2.4 with x64 support: "Includes support for OSX (ppc/x86/x86_64), Linux (x86/amd64), Windows (x86/x86_64), Solaris (x86/amd64/sparc/sparcv9), and freeBSD (x86/amd64)."

With this test program i can reproduce the problem with JNA 3.0.5. With JNA 3.2.4 it works!

It would be good if you can update JNA lib to 3.2.4. I can test the new build then.

[bflorat]

Fine, I checked-in JNA 3.2.4 into trunk. Please have a look at trunk daily build from tomorrow :  http://integration.jajuk.info/hudson/job/Jajuk%20Daily%20Build%20-%20Trunk/

[anb0s@…]

Thanks, i will test it with trunk (version 1.9).

[anb0s@…]

Hi,

i just tested the build 418, but with 64 bits JRE it still does not work. It shows "[ERROR] (7)" and "org.jajuk.util.error.JajukException?" in console. I will try to setup jajuk dev environment and debug it.

Andre

[bflorat]

All right, strange, the build #418 contains the JNA upgrade (  http://integration.jajuk.info/hudson/job/Jajuk%20Daily%20Build%20-%20Trunk/changes ), or may I have miss something ?

[bflorat]

Indeed, I think I forget something. The jajuk.bat used in trunk was not the patched one but jna was the good one so your patches was half in 1.8 branch and half in trunk. I checked-it the last jajuk.bat into trunk along with the JNA upgrade (I'll report JNA upgrade to maintenance branch when we'll close this ticket). Please try next trunk build at  http://integration.jajuk.info/hudson/job/Jajuk%20Daily%20Build%20-%20Trunk/ .

[bflorat]

Hi Andre. Is it OK now ?

[anb0s@…]

Hi,

i tested the trunk build "434 (12.01.2010 05:01:05)", but it does not work with 64 bits JVM. It means with new JNA it is still not possible to use 64 bits JVM. OK, it works as expected with jajuk.bat and 32 bits JVM.

Thanks, Andre

[bflorat]

I don't see what can be done from us on this ticket. I move it to "Known issue.

[anb0s]

I think the workaround with batch file to start 32 Bits JVM is usable.

[bflorat]

OK fine then. However, the issue is not fully covered as most of time, users don't use the .bat to start jajuk but Start-> Jajuk -> jajuk startup menu that just performs a:

javaw -client -Xms20M -Xmx512M -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -jar "$INSTALL_PATH/bin/jajuk.jar

We should try to make a cmd <path>\jajuk.bat instead . To be studied against Killer Queen.

[bflorat]

Update : due to #1594 and to fix issues related with this ticket (32/64 bits JRE choice), we drop JNA and we now use a .bat to convert filenames to 8.3 DOS format.

I tested with your mp3 cyrilic and it works.

I also reverted most of your changes against the .bat file to allow implementation of #1602.

Please have a look at 29/04 build or upcoming RC4 next week end and please reopen if you still have a problem.

[anb0s@…]

I tested trunk build from 2010-05-02: sometimes it can play files with cyrillic filenames, but mostly it just reports errors and crashes (jajuk UI disappears and mplayer.exe is still running).

[anb0s@…]

console log

[anb0s@…]

I've attached the console log 'jajuk_trunk_build_2010-05-02_errors.txt'. My playlist has cyrillic, german and english filenames. You can see mostly the error message '[ERROR] (7)' and cyrillic filenames with '?', like it was in previous jajuk build with 64-bit JVM.

First the attached mp3-file (???????? - ?????-???? (cut).mp3) doesn't work, because of '???????? - ?????-???? (cut).mp3':

... [ERROR] (7) Fehler beim Abspielen der Datei, eventuell konnt e MPlayer bis zum Timeout nicht mit dem Abspielen beginnen:: Warte auf Audio-Res source (in Verwendung){{???????? - ?????-???? (cut).mp3}} [Queue Selection Thre ad] (Player.java:146) ...

and than it works again, with DOS filename 'G:\Musik\_MASCH~1\04\IKA-(V~1.MP3]':

... 2010/05/02 13:49:54 [DEBUG] Using this Mplayer command: {{[C:\Program Files (x86 )\Jajuk\mplayer.exe, -quiet, -slave, -af, volume=-8, -softvol, -cache, 500, G:\M usik\_MASCH~1\04\IKA-(V~1.MP3]}} [Queue Selection Thread] (MPlayerPlayerImpl.ja va:406) ...

It looks like the convert mechanism doesn't work always.

Andre

[anb0s@…]

I've copied the batch file from version 1.8.4 and it works without any problems with 32 Bit JVM.

[bflorat]

I just figured out that out new patch was applied only against Windows 32 bits, not 64 bits (sorry about that). It is applied against every Windows OS from 2010/05/06's daily build, could you please have a check ?

My own log under XP 32 bits :

2010/05/05 21:56:37 [DEBUG] Using this Mplayer command: {{[D:\Documents and Settings\bflorat\.jajuk_test_1.9\mplayer.exe, -quiet, -slave, -af, volume=-4, -softvol, -cache, 500, F:\music\CLASSI~1\test\--(CUT~1.MP3]}}  [Queue Push Thread] (MPlayerPlayerImpl.java:406) 
2010/05/05 21:56:37 [DEBUG] Now playing :File[ID=5k2fsyxe4cd52kaacbj5cmok7 Name={{Инфинити - Слёзы-Вода (cut).mp3}} Dir=Directory[ID=1e010fw4uhhqa9a3c8kvg3c0c Relative path={{\test}} ParentID=1p2epfzc6g3fpnw14rlev8jfm Device={{t}}] Size=19839470 Quality=160]  [Queue Push Thread] (QueueModel.java:590) 
2010/05/05 21:56:37 [DEBUG] Notify: PLAYER_PLAY  [Event Executor for: PLAYER_PLAY no details] (ObservationManager.java:139) 
2010/05/05 21:56:37 [DEBUG] Notify: QUEUE_NEED_REFRESH  [Event Executor for: QUEUE_NEED_REFRESH no details] (ObservationManager.java:139) 
2010/05/05 21:56:37 [DEBUG] Notify: FILE_LAUNCHED  [Event Executor for: FILE_LAUNCHED] (ObservationManager.java:139) 
2010/05/05 21:56:37 [DEBUG] JajukInformationDialog implementation is available for system notifications.  [AWT-EventQueue-0] (NotificatorFactory.java:78) 
2010/05/05 21:56:37 [DEBUG] Got update for new file launched, item: {{File[ID=5k2fsyxe4cd52kaacbj5cmok7 Name={{Инфинити - Слёзы-Вода (cut).mp3}} Dir=Directory[ID=1e010fw4uhhqa9a3c8kvg3c0c Relative path={{\test}} ParentID=1p2epfzc6g3fpnw14rlev8jfm Device={{t}}] Size=19839470 Quality=160]}}. Sending text: {{<HTML><b>Инфинити - Слёзы-Вода (cut)</b><br/>test<br/></HTML>}}  [AWT-EventQueue-0] (PlayerStateMediator.java:234) 
2010/05/05 21:56:37 [DEBUG] Notify: QUEUE_NEED_REFRESH  [Event Executor for: QUEUE_NEED_REFRESH no details] (ObservationManager.java:139) 
2010/05/05 21:56:37 [DEBUG] Local cover list: {{[Type=NO_COVER URL=file:/D:/workspaces/workspace-perso/jajuk/bin/images/included/jajuk-splashscreen.jpg]}}  [Event Executor for: FILE_LAUNCHED] (CoverView.java:1576) 
2010/05/05 21:56:37 [DEBUG] display index: 0  [SwingWorker-pool-1-thread-12] (CoverView.java:1042) 
2010/05/05 21:56:45 [DEBUG] Seeking to: 0.09  [TrackSlider Position Thread] (Player.java:393)

[anb0s@…]

No problem i can try it. It looks like the previous build #572 (2010/05/05) blocks the new one #573 (2010/05/06). I will check again at weekend if it's available...

[bflorat]

oops... I fixed it. Build #576 only waits for you. Thanks.

[abe lau]

I have tried the 11May2010 build, and files with chinese filenames are not working. I am not sure if it is related to this bug or not. Please let me know if you prefer opening another ticket for this, or you need another error log. Thanks.

[bflorat]

Thanks for the feedback. Using this ticket is fine.

It would be nice if you sent :

• The logs (from your <HOME>/.jajuk/jajuk.log file directly, not from Help->Show debug traces because they are anonymized and we need to see the final filename.
• Any detail about your OS : at least os.name, os.version, os.arch, file.encoding (from Help-> About-> System tab)
• A sample file you can send me at bertrand@fl(x)rat.net (x=o) if it's too big here

Thanks

[anb0s@…]

Hi,

i tried the newest build, but have still problems with cyrilic file names. Sometimes it works, but often it's not working. The error message is something like "timeout from mplayer". I can test it tomorrow at home and send error log.

Andre

[bflorat]

@Abe : I managed to reproduce for a while but after that, the problem disapared again by me. However, I refactored the player engine a bit to fix a race condition when dealing with non-ASCII filenames and I have good reasons to believe that I may have fix this issue.

@anb0s : thanks for testing. If the same file fails or not among time, my new fix is probably a good bug killer candidate.

Could you please try the 13/05 daily build ?

[abe lau]

Thanks bflorat. You probably have fixed the issue :) the 13/05 daily build seems working nice. I haven't encounter any unplayable tracks until now. I will let you know in case I encounter any.

[bflorat]

Excellent !

@anb0s : is it ok from your side ?

I'll release 1.9RC4 in few days if this issue appears to be over.

[anb0s@…]

Log file from build #596 (14.05.2010)

[anb0s@…]

Sorry, but it is not OK for me. I attached a log file with 3 different outputs (jajuk_logs_ Build_#596_(14.05.2010) .txt):

1. This file works: mplayer command is good, the file path is converted to DOS (8.3) path.

2. This file works too: first mplayer command has ? characters, then the message "[WARN] Inverted filename scheme (true)" is shown and the second mplayer command shows converted file name.

3. This file does not work: first mplayer command has ? characters, then the message "[WARN] Inverted filename scheme (false)" is shown and the second mplayer command shows "bad" file name again.

I do not know the logic for the convert mechanism, but some file names are not converted.

[bflorat]

Thanks for the feedback. It should be fixed in 15/05 daily build. Your problem was probably caused by the '&' characters in the file names. They made the converter shell fail because it see the as commands separator.

About the invert filename scheme : basically, we use long names by default and we switch to short names for current and following files if we encounter a problem. If we have a problem using shortnames, we switch back to longnames. Note that we can't simply always use shortnames because it would fail with some network drives or ext drivers.

Let me know if you have more issues.

[anb0s@…]

I tested the builds 15/05 and 16/05, but it still does not work. All file names with '&' character are not ok.

[bflorat]

Oops, sorry about that, seems that my tests with '&' character were not deep enough. I checked in a new fix I tested successfully with file names like '&Инфинити && Слёзы-Вода (cut).mp3' and the new fix should handle property any other special character than '&' because we now escape strings in the .bat :

@echo off set name=%* for %%X in (%name%) do set name="%%~sX" (see the quotes) echo %name%

instead of for %%X in (%name%) do set name=%%~sX

Let me now if it's ok for you, I'll release 1.9RC4 afterward.

[bflorat]

(will be available from the 19/05 daily build), thanks.

[anb0s@…]

With build from 19/05 all files are ok. Thank You!

[bflorat]

Excellent ! thanks for your tests

[abe lau]

bflorat: I just found that filename with chinese character as the first character would not play, giving the same error message. Files with chinese character within the filename (but not the 1st char) works. This is with RC4 (and possibly with previous nightly also I'm not sure). Any idea why?

[bflorat]

I cannot reproduce, could you please paste here the exact filename and the logs ?

[abelau]

I have emailed you a zipped file with a directory structure that does and doesn't work. I hope you could reproduce it on your side. Thanks.

[bflorat]

Please check the 2010/06/04 daily build, it should be better (thx to this link :  http://www.keyongtech.com/2420361-short-dos-names-for-paths). New convertion script is now :

@echo off
set name=%~s1
for %%X in ("%name%") do set name="%%~sX"
echo %name%

and the argument (the full long path) is given with quotes around it. Feel free to reopen.

[abe lau]

I have tried the 0604 daily build. Most songs are now playable again. There is still a number of files not playable: filename with Chinese char followed by english char, or chinese char with special char (brackets, plus sign). I have emailed you a directory structure for your testing. Thx.

[bflorat]

I applied my last fix applied against build #623, not #604. With current code, I can play the new samples you sent me today (yesterday for you?) like a charm, could you please have a look ?

[abe lau]

missing a / ;) I am actually trying 2010/06/04 daily build, not really sure what is the build number.

What I did was to create a new device pointing to the root directory structure I sent you. Apparently it looks to me that the chinese directory name would affect if the files are playable or not.

I just retried again, and all files I sent you did not play, with error "Error playing file, maybe mplayer did not start playing until timeout was reached"

[abe lau]

Hi bflorat,

I uninstalled jajuk, removed all the settings, did a clean install of build #636 (16June2010), imported the folder structure I sent you, and still get the error: "Error playing file, maybe mplayer did not start playing until timeout was reached"

I wonder if it is reproducible on your side, or how I may help in resolving this. thanks.

[bflorat]

Hi, I tried again the three "beep" files you sent me and it works. What you can do:

• Select one oh these file from the tree view -> "right click -> "Copy url", then try to open the file from another audio player pasting the exact url in its file browser. -> check if the file works outside jajuk.
• Please send me this full url so I can try to simulate it by me.

thanks.

[abe lau]

I have just tried what you suggested and here are the results.

Using VLC media player (portableapps portable version 0.8.6b), pasting the copied link to the "Open File" dialog:

--The first test beep file with path name D:\temp\files_not_playable\林峰\林峯 - 明天以後 (林峯+泳兒合唱).mp3 will freeze VLC player. Nothing is played and no error displayed. I need to kill VLC from the task manager

--The second test beep file with path name D:\temp\files_not_playable\雲凱弦\雲凱弦-Meditation.mp3 played normally. Everything is fine.

--The third test beep file with path name: D:\temp\files_not_playable\黃耀明\黃耀明 - 下一站天國 (Live).mp3 has a same behavior as the first file.

However, if I paste the file link within a double quote, the above 3 files all played sucessfully in VLC: e.g. "D:\temp\files_not_playable\黃耀明\黃耀明 - 下一站天國 (Live).mp3" played OK

All 3 files played successfully in Media Player Classic (unicode build, 6.4.9.0)

wonder if the info helps... thanks

[abe lau]

Another piece of maybe useful information:

If I move the file up one directory in the folder structure, all files played successfully in Jajuk build 636

ie. D:\temp\files_not_playable\林峯 - 明天以後 (林峯+泳兒合唱).mp3 OK in Jajuk D:\temp\files_not_playable\林峰\林峯 - 明天以後 (林峯+泳兒合唱).mp3 Error in Jajuk

[bflorat]

I reproduce your problem with path D:\temp\files_not_playable\林峰\林峯 - 明天以後 (林峯+泳兒合唱).mp3

Seems like that bat solution is too restrictive, we have to find an alternative (still without using jna). We should try to build a CLI windows executable in C or another language and which should call windows native functions.

[itoijala]

I have written a Win32 console app that calls GetShortPathName? using the first argument as the parameter and prints the result to standard output. I used Visual Studio 2010 Express Edition for this (free download). The program requires msvcr100.dll to be on the user's machine or in the program's directory. I included this file in the attachment. Since it is the official redistributable I think it is ok for us to distribute it. Publishing the app from Visual Studio also results in the file being included. If you do not agree, please delete the attachment and reupload without the file. Prebuilt executables are provided for your convenience. If you wish to get rid of the dll you need to find someone to compile the app with Visual Studio 6.0, the last version before .Net. This version is no longer distributed and was never free.

I tested the program with the path from the last comment and it works.

[itoijala]

Win32 console program

[bflorat]

Thanks for this. This works pretty from the shell well even if I get some over-numerous characters :

D:\temp>D:\temp\GetShortPathName? "D:\Mes Documents\Ma musique\unicode_dir_test\Õ «╣þÑûÕàÆ\Õ«╣þÑûÕàÆ-Sand_Storm.mp3" D:\MESDOC~1\MAMUSI~1\UNICOD~1\94FC~1\-SAND_~1.MP3\Do?♫??????????????????????????

Note that another contributor (Dominik) provided another implementation (see the dev ML) without dll dependency. Through, none of both implementations work from java because of JRE bug 4947220 ([1]), I'm trying a workaround.

[1]  http://bugs.sun.com/view_bug.do?bug_id=4947220

[bflorat]

Well, I tested various workarounds including using apache commons-exec API but none works. BTW, it seems that bug 4947220 is fixed in the JRE 7 RC7.

Now, I beg your suggestions. Maybe should our java program write the path in UTF-8 (or another encoding) to an temporary file that would be read by the C++ program instead of reading it from command line arguments ?

[bflorat]

All right, I think I got it using a very ugly "dir /x" output screen scrapping. This is available in the 2010/07/05 daily build.

@abe lau : could you please have a try ?

Note : we have to call dir /x from a bat itself called by java and parsing "%~s1" input (means "shortname" of the path). Because of bug 4947220, the arguments are translated to CP1252 or others charsets (the current charset actually ) and most commands (including the exe itoijala and Dominik wrote) fail but "dir" DOS command seems to own the ability to understand the path even after this translation...

[abe lau]

bflorat: I just tried Build #664 (Jul 5, 2010 5:00:24 AM), and still getting the same error on the 3 files I sent you.

[centic]

maybe we can uuencode or base64-encode or somehow else encode the filename when passing as argument to the Exe. This way we are not sending unicode chars as commandline?

[centic]

Another workaround is mentioned in the bug at sun:

I stumbled into a workaround that works for me. I used ProcessBuilder? rather than Runtime.exec(). For the part of the command where I wanted to pass the filename, instead I referenced an environment variable (such as "%THE_FILE%"). Then I defined that environment variable ("THE_FILE") to be the corresponding file name in the ProcessBuilder?'s environment before calling start(). It worked!

String[] cmd = new String[]{"yourcmd.exe","Japanese CLI argument: \ufeff\u30cb\u30e5\u30fc\u30b9"};

Map<String, String> newEnv = new HashMap?<String, String>(); newEnv.putAll(System.getenv()); String[] i18n = new String[cmd.length + 2]; i18n[0] = "cmd"; i18n[1] = "/C"; i18n[2] = cmd[0]; for (int counter = 1; counter < cmd.length; counter++) {

String envName = "JENV_" + counter; i18n[counter + 2] = "%" + envName + "%"; newEnv.put(envName, cmd[counter]);

} cmd = i18n;

ProcessBuilder? pb = new ProcessBuilder?(cmd); Map<String, String> env = pb.environment(); env.putAll(newEnv); final Process p = pb.start();

[itoijala]

Another working workaround is starting the program and writing the long unicode path to the process' standard in. The length of the string can be given as a command line argument to get the correct buffer length. Since Dominik's implementation was a bit better (no DLL dependency (I can also statically link mine, 40k larger exe), no extra question marks (I did not see these on my machine (7, XP)). Is Dominik's code available somewhere for reference. The change should not be a really large one.

[centic]

Yes, that sounds like another valid workaround, my source is available at  http://ubuntuone.com/p/8TN/ for Visual Studio 2008, if you want to have a try, I am not sure how soon I get around to take another look.

[bflorat]

• @abe lau : very strange, all the three mp3 works for me, even with several levels of directories with non-CP1252 codepage characters. I guess that my environment must be different from yours in several aspects.
• @centic : Yes, I tried the env variable workaround that without success
• @itoijala : this sounds good to me, probably the best solution IMO as I'm pretty sure that direct stream communication should not be affected by the JRE bug #4947220. (it is only in the fork native methods of ProcessBuilder/Runtime? classes AFAIK). UTF-8 or UTF-16 stream encoding should be all right. I'll wait for your new exe version before making further searches.

[bflorat]

I forget : with Dominik's code, file names with '&' characters were not correctly translated(we got an error message), please make sure that the C++ code is able to translate this kind of filenames as well.

[itoijala]

I had problems getting the C++ solution to work. I could not figure out how to set the encoding that stdin (wcin) uses when reading from the console.

I have a different solution that works with all paths that have been mentioned in this thread.

It uses VBScript run by cscript.exe. The script (< 1kB) has to be written to disk for every invocation.

I will attach a sample program that can be used to test the implementation.

Please note that I do not think that using a short path will solve the problem for all users. Some users might have a registry option set that disables the creation of 8.3 names. This means that it is not possible to provide short names for files on such a system. Another problem is that users who have their music on a server with a different file system (for example a NAS) will also have no short names to use. The JDK bug means that it is not possible to get the path to MPlayer's command line in all cases.

Perhaps we should try to write a script that serves as a pipe between Jajuk and MPlayer, forwarding Jajuk input to MPlayer and MPlayer's output to Jajuk. A batch script is probably not possible, maybe VBScript.

[itoijala]

I think that i have found another workaround. The problem (as I understand it) is caused by the JDK bug. We cannot output unicode paths to MPlayer's commandline form Java.

MPlayer's slave mode includes a command loadfile <path>. we could launch MPlayer with a silent file of 1 second length (ascii file name, relative path, no problems with unicode) and loop 0 (to loop until we change the file). Then we call loadfile <unicode path> and loop -1 to stop looping.

I could not test this workaround because slave mode does not work from the console but I believe that it should work.

P.S. The above VBScript could be changed to take the path as a command line parameter to avoid having to write it to disk every time. I could do this if we decide to use it.

[bflorat]

Thanks for your help

• About the VBScript : I tried very similar things without success but without the ChrW function call. Did it work against the provided test cases ? If so, we could simply integrate it for further testing.

• NAS/non 8.3 filesystem : right, we are aware of it but AFAIK, it would affect very few NAS or filesystems and note that jajuk automatically try both regular and short name and that regular names are ok if they don't content any non-CP1252 characters. So very few cases remain but I agree that we would not cover every cases.

• About the new workaround : this sounds good to me and could be a definitive fix indeed. IMO, it is worth a try in all every case. Why one second file length ? is it the minimum ? I just wonder if we wouldn't get a significant lag here, don't you ?

[itoijala]

The VBScript works with all test cases that have been posted to this issue, including names with &.

The file for the other workaround does not have to be 1 second. It could even be only one sample/frame. I tested the workaround with a one second silent flac (12kB) and -input file=input.txt to work around not being able to write to the console in slave mode.

I believe there is a small lag because MPlayer first has to read the silent file and then the real file. On the other hand, other things, for example changing the volume also lag a bit (just enough to be noticable). I think we have to live with it.

[bflorat]

Fine.

Few thoughts :

• I'll prefer to implement the Killer Queen as the option 2 would come with significant logic changes in the MPLayerPlayerImpl and I'm already tired with the regressions. Moreover, the VBS script only affect windows-specific code.

• This fix is for windows only. We don't want to affect others OS speed/reactivity/stability with the option 2 fix. So if we go for it (in another release), we may need a dedicated MPlayerWindowsPlayerImpl ?

• With current logic (sleep until track is launched for eg), I'm afraid of cases where mplayer closes before we actually manage to launch the slave command. We could create unreproductable issues. Is there any way to keep mplayer resident even without playing a track ?

[itoijala]

There are two ways to keep MPlayer open in this case.

• Use -loop 0 command line option, send loop -1 command after file change command
• Use -idle command line option, quit command needs to be sent manually

[bflorat]

Sorry for the delay, new job...

I just commited the itoijala's VBS fix. It is pretty clever and comes with what what I searched for a long time : the way to contain native Unicode characters thanks the ChrW() trick (I was expecting something like \uxxxx like in java but I never found something equivalent in VBS).

The only problem with this solution is the VBS execution overhead (in my case : around 15ms to create the script, 1800 to run it) so I had to change the shortnames usage policy : we no more keep stuck with shortnames mode at first file requiring it because it takes too long. Now, we always try to launch mplayer with the longname and then try shortnames ("fail fast" of onyl 100 ms) if mplayer can't find the longname file. It will slighty increase the pure non-ASCII collection owner experience but will save the experience of user with mixed-up collections with european/non-european filenames collections.

It will be available in 29/07/2010 build.

I tested it successfully against every test case I own, including the Abe Lau files.

@Abe Lau : could you please have a new look at it ? Thanks in advance.

[bflorat]

I created the #1696 : refactoring study for itoijal's second solution. I for one will probably not work on it. Anyone interested to work on it / implement it / integrate it / test it is welcomed.

[abelau]

I tried the 29/7/2010 build last friday, and so far so good. I haven't yet found any files that is not playable. Will report back later on after further testing.

[abelau]

Files not playable on 29/7/2010 build

[abelau]

I have attached a zipped file structure with files that are not playable on the 29/7/2010 build. The files are all playable IF they are the only file in the directory, but not playable when the other few files are present! There will be a 5-10 seconds freeze in jajuk, before the same error is shown in the bottom status bar

[bflorat]

All the four works for me.

The nb 1 is translated into short name GIGI-~4.MP3 The nb 2 and nb 3 can be played as it by mplayer with their long name The nb 4 has to be translated to shortname like nb 1 and is played properly afterward.

In your case, if the file combination in a common directory affects the jajuk behavior, I guess that it is because of shortname collision but in this case, it is a MS Windows API bug as we simply use the VBS functions now. (Note that a bug in MS API may explain the original issue of this ticket : the call to Windows API -previously using JNA- returned corrupted names, apparently only under 64bits windows)

I don't think we can go further for now. I'm not sure if the load slave function accept longname but if so, it may be an argument to implement #1696 in future releases. I keep this ticket as known issue. Thanks again Abe for your help on testing this stuff.

Any feedback on this issue is welcomed on this ticket to figure out if it is a very common issue or only very seldom.

[abelau]

thanks for fixing it also. At least more than 95% of the track works now.

By the way, I encountered a strange behavior never happen before. I pressed the fast forward button , and then the current track didn't stop playing, while the next one started, overlapping with the current track. I hit stop in jajuk, and only the next track stopped, but not the current track.

unfortunately I cannot reproduce it.

guess it maybe related to the new fix... any idea?

[bflorat]

It may be related as converting to short names can take until one or two seconds.

BTW, could you please provide the last four test files you send me the last logs, especially the "Using this Mplayer command: {{[ ..." lines so I can see the actual name given to mplayer ?

Moreover, I wonder if you could mix both fixes (dir parsing command and VBS script). Could you tell me if you kept the 2010/07/05 daily build if this release works for these four files (otherwise, I'll try to send it to you again) ? Please also provide the output of a dir /x in the directory with these four files.

Thanks

[bflorat]

It seems that we should try to implement the "load" from mplayer fix or wait from another fix from mplayer team (very unlikely). It is unclear if this bug really affect large part of Asian collections or not (and I cannot reproduce any problem with Chinese samples under my box).

The best decision for now is probably to keep this issue in stand-by state and wait and see if users report similar issues.

[bflorat]

See also #1916

It should be fixed using the last Windows mplayer release we linked jajuk to (20130411) and which now supports unicode in file names. This Windows mplayer fix along with the Oracle fix of ProcessManager? (JRE bug 4947220) in JRE 7 should make this problem solved (you need a JRE 1.7 though if under Windows).

Feel free to reopen if the problem appears again in the future.