PMS Community Build Beta

[Coltaine79]

In that case, perhaps the problem is I was running it using 64-bit Java VM.

Let me try uninstalling it/clean-installing and starting it with 32-bit JVM, see what happens.

[maugus]

lightglitch thank you for osx build. Im having a problem with the latest version (412r31), it cant find my ps3, even if i force to en0. When i use 410c29 it can find ps3, but is showing the error below :

[pool-629-thread-3] ERROR 11:54:52.051 -- Fatal error in process starting:
java.io.IOException: Cannot run program "osx/convert" (in directory "/var/folders/Qi/QiW8+9f2FU8XxwywQrLgpk+++TY/-Tmp-/javaps3media/imagemagick_thumbs"): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) ~[na:1.6.0_20]
at net.pms.io.ProcessWrapperImpl.run(ProcessWrapperImpl.java:83) ~[pms.jar:na]
at net.pms.dlna.DLNAMediaInfo.getImageMagickThumbnail(DLNAMediaInfo.java:294) [pms.jar:na]
at net.pms.dlna.DLNAMediaInfo.parse(DLNAMediaInfo.java:439) [pms.jar:na]
at net.pms.configuration.FormatConfiguration.parse(FormatConfiguration.java:85) [pms.jar:na]
at net.pms.formats.Format.parse(Format.java:117) [pms.jar:na]
at net.pms.dlna.RealFile.resolve(RealFile.java:175) [pms.jar:na]
at net.pms.dlna.DLNAResource.run(DLNAResource.java:412) [pms.jar:na]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_20]
at java.lang.Thread.run(Thread.java:637) [na:1.6.0_20]
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method) ~[na:1.6.0_20]
at java.lang.UNIXProcess.<init>(UNIXProcess.java:53) ~[na:1.6.0_20]
at java.lang.ProcessImpl.start(ProcessImpl.java:91) ~[na:1.6.0_20]
at java.lang.ProcessBuilder.start(ProcessBuilder.java:453) ~[na:1.6.0_20]
... 10 common frames omitted

[Coltaine79]

I'm using 412c31

My changes:
I've swapped mencoder/mencoder_mt/mplayer with build 31170 (as recommended earlier in this thread)
I've replaced the mediainfo DLL's with the most recent DLL's
Manually running the app with Java x64.
PS3 fw 3.50.

I've occasionally noticed that when I use the "GoTo" function frequently within a x264 MKV, the synch will be messed up slightly. Not too much, (probably less than 1 second) but enoough for me to notice. I can remedy this by stopping the file, then choosing "Play from beginning" in PS3 XMB - then i immediately GoTo to my original point in the movie. but again if I hop around during the movie, synch gets messed up. Anyone else notice this?

[Edco]

Thanks for all you are doing!!!

BUMP!

[Coltaine79]

Major Bug:

In some cases, the "orphan/child process cleanup code" will actually kill OTHER processes which have nothing to do with PMS.

First time I noticed it, after watching a video file, went back to my computer and my system tray was empty... something had killed a whole bunch of my processes while I was watching a TV ep (I was on the computer prior to watching the video file).

Noticed it again today... after returning to my PC after watching a show, my antivirus process had been killed... for no apparent reason. Event Viewer has no explanation either.

This behavior never happens when the NON-community build (i.e. shagrath's regular build) is used.

[chocolateboy]

On Windows, the patch uses winp to kill a process and all its children (using the killRecursively method). It's possible that this could be the wrong process if Windows recycles process IDs, but the same would apply with the unpatched code. The only difference on Windows is that with this patch the child processes are also killed.

I'm more than happy to take out the winp code from the patch, but if this is a recycled process ID issue then removing winp or reverting to the unpatched version won't prevent the unpatched Windows code doing the same thing (albeit with a smaller gun), and, of course, won't fix orphan processes.

I've posted a link to your post on the winp issue tracker.

[Coltaine79]

Is it possible for it to do some sort of "sanity check" prior to killing the processes?

i.e. if it's about to kill PID 1234 - can it first check if the executable name of PID 1234 matches one of the executables which PMS has run since the program began?

OR maybe just check if the executable name is on a list of "approved killable" processes? "mencoder.exe;mencoder_mt.exe;mplayer.exe;ffmpeg.exe" -- etc.

Perhaps that's a quick way to ensure that PMS doesn't kill winword.exe or notepad.exe or something else which obviously would not be run by PMS...

If I see this issue happen again, what I might do is create a separate user account and "runas" PMS using that account, therefore preventing it from being able to kill any processes which are running under my own regular user account...

[chocolateboy]

The safest way is to only kill processes whose parent process is PMS. Unfortunately, winp's WinProcess class doesn't expose a getParentPid method (although it must be able to navigate a process tree internally), so that can't currently be done (without reinventing winp).

I've posted an updated patch (against trunk r412) with the Windows stuff removed. I don't use Windows, so someone who does can get it working on that platform.

[Coltaine79]

By "Windows stuff removed" do you mean it doesn't kill any processes at all on Windows, or just that it uses shagrath's old method rather than the "winp method"?

Thanks

[chocolateboy]

The latter.