UMS won't launch

[Viridel]

Yes, the reason it's non changable is because it's inherited from the parent folder. I just have to figure out why the permissions are read wrong. I know it usually works fine on Windows 10, so what is different in this case?

Just as a shot in the dark - are you running 32 bit or 64 bit JVM?

Well, to help your troubleshooting, I just threw 5.2.3 on my system, and launched flawlessly. It's not finding any renderers though, even though I have a QNAP external, and run Vuze (PS3 not hooked up). At minimum, shouldn't it "find" my computer in the render list? **Correct that, it is finding my system - just not identifying it as a computer... Just an Unknown Device at the correct IP.

As far as Java, the About doesn't specify.

[Nadahar]

The reason UMS doesn't find renderers is usually because you're running a local firewall. Try to disable it.

In the Java control panel applet, choose the "Java" tab, and click "view". Select "system" and look at the path. If it's in the x86 version of program files it's 32 bit, if not it's 64.

[Viridel]

The reason UMS doesn't find renderers is usually because you're running a local firewall. Try to disable it.

In the Java control panel applet, choose the "Java" tab, and click "view". Select "system" and look at the path. If it's in the x86 version of program files it's 32 bit, if not it's 64.

Oh, duh, in doing a Run, it clearly says Java (32-Bit). I only care about the PS3, so when that time comes, I'll fight with firewalls if I need to.

[Nadahar]

Maybe a 64 bit version would be better? This is not just some "completely in the blind" attempt, Microsoft has done it so that 32 bit applications can only read a "copy" of the registry that's supposed to simulate a 32 bit environment. That means that any 32 bit Java application can't read the "real" registry, and I'm thinking maybe this could make the permissions check fail.

I'm running Windows 7 64bit, 64 bit Java, and I've just created a folder with only "full control" to the everyone group and then a subfolder that inherits that. When configuring UMS to use that folder, everything is fine.

It would be interesting if you created a folder on an actual harddrive and told UMS to use that via UMS.conf - if it could read the permissions there for some strange reason.

[Viridel]

Changed over to Java x64, took UMS 5.2.3 off and re-installed UMS 5.4 J8 - back to the original failure, instant self-termination with the same error as previous:

INFO 2015-12-29 22:37:56.355 [main] Working directory: I:\UMS
ERROR 2015-12-29 22:37:56.362 [main] A serious error occurred during PMS init
java.io.IOException: Temporary folder isn't writable:R:\Temp\UMS
at net.pms.configuration.TempFolder.assertFolderIsValid(TempFolder.java:89) ~[ums.jar:5.4.0]
at net.pms.configuration.TempFolder.getSystemTempFolder(TempFolder.java:76) ~[ums.jar:5.4.0]
at net.pms.configuration.TempFolder.getTempFolder(TempFolder.java:40) ~[ums.jar:5.4.0]
at net.pms.configuration.TempFolder.getTempFolder(TempFolder.java:32) ~[ums.jar:5.4.0]
at net.pms.configuration.PmsConfiguration.getTempFolder(PmsConfiguration.java:720) ~[ums.jar:5.4.0]
at net.pms.PMS.displayBanner(PMS.java:301) [ums.jar:5.4.0]
at net.pms.PMS.init(PMS.java:408) [ums.jar:5.4.0]
at net.pms.PMS.createInstance(PMS.java:1056) [ums.jar:5.4.0]
at net.pms.PMS.main(PMS.java:1205) [ums.jar:5.4.0]

[Nadahar]

Could you try to configure it to somewhere else by adding

Code: Select all

temp_directory = X:\\Some\\Folder\\temp

to your UMS.conf.

I need to figure out what goes wrong, and I'm interested to see if the problem is with the system or with the drive.

[Viridel]

Well, that solved nothing but shifting the failure

INFO 2015-12-29 23:06:03.597 [main] Working directory: I:\UMS
INFO 2015-12-29 23:06:03.602 [main] Temp directory: T:\UMS\temp
ERROR 2015-12-29 23:06:03.603 [main] The Java temp directory "R:\Temp" is not writable by UMS
ERROR 2015-12-29 23:06:03.603 [main] Please make sure the directory is writable for user "MINE"
ERROR 2015-12-29 23:06:03.606 [main] A serious error occurred during PMS init
java.io.IOException: Cannot write to Java temp directory
at net.pms.PMS.displayBanner(PMS.java:313) [ums.jar:5.4.0]
at net.pms.PMS.init(PMS.java:408) [ums.jar:5.4.0]
at net.pms.PMS.createInstance(PMS.java:1056) [ums.jar:5.4.0]
at net.pms.PMS.main(PMS.java:1205) [ums.jar:5.4.0]

But clearly it's a UMS issue, otherwise nothing would work that uses the Temp folder - which is like, everything.

[Nadahar]

I'd say it's probably a Java issue, as Java nio is responsible for reporting permissions. What I'm trying to figure out is why it is failing on your computers and not on a lot of other Win10 computers.

If we're going to fix it, we'll have to figure out what's the problem. I didn't quite understand that log, you rerouted to T:\UMS\temp right? Why then did it go on about R:\Temp then? I don't get it...

[Nadahar]

I looked in the code, and now it makes more sense. The line

Code: Select all

INFO 2015-12-29 23:06:03.602 [main] Temp directory: T:\UMS\temp

is fine, all is ok. What I didn't understand was why it then complained about

Code: Select all

ERROR 2015-12-29 23:06:03.603 [main] The Java temp directory "R:\Temp" is not writable by UMS

But, it happens to be so that one of our dependencies (JNA to be exact) uses the Java temp folder independent from what UMS is configured to do, and thus that folder is checked for write access as well. You have probably configured Windows to point it's temp folder to the RAM drive, or maybe Java? In either case, this (the path) comes from outside UMS.

What the above shows is that everything is fine with T: - the permissions check is ok and it moves on, but when it comes to R: it fails again. I'm pretty sure there must be something strange going on with the file system on the RAM drive, or simply that Java can't interpret it.

[Viridel]

What the above shows is that everything is fine with T: - the permissions check is ok and it moves on, but when it comes to R: it fails again. I'm pretty sure there must be something strange going on with the file system on the RAM drive, or simply that Java can't interpret it.

As I mentioned, the RAMdrive (R:\Temp) IS my Windows Temp location (as per the below image). Also remember that if Java was failing, I wouldn't be able to use it in my browsers; and more importantly that UMS 5.2x is working fine (tested on both machines), while 5.3+ failing. So putting the blame on Java simple isn't accurate, as our troubleshooting has determined that it's the UMS code update between 5.2 and 5.3 that is causing the grief. That said, it could very well be how UMS tells Java to interact - I don't know... But it's something in the UMS code change that has disabled the ability for it to work on our extremely specific/unique configuration (even though it's a freakin' awesome setup that keeps the system moving incredibly fast, with no space or wear issues on C:\ - I don't know why everyone wouldn't do this )

So with 5.2 working, then we just won't update in the foreseeable future... But with v6 on the horizon, I'm hoping this rogue code change can be brought under control for our configuration, and I'm more than willing to help test things, as I've been a faithful user of PS3MS for a bloody long time and have no issue giving back!