MinimWatch-Icon stays grey

[bjoernminim]

I already read a ton of other forum posts regarding this issue, but none of them solved my problem. The only difference I could see is, that I'm using OpenJDK instead of Oracle, but could this really be the problem?

Attached you'll find the log-File from MinimWatch in Trace-Level, when I deactivated my Firewall - so this shouldn't be a firewall problem. Also I changed the "ohnet.subnet"-Setting to 192.168.178.0.

My Environment is:

1. MinimServer 0.8.5.3 update 133 on Synology NAS DS716+ II with DSM 6.2.2.-249222 Update 4
2. MinimWatch 2.0.8 on Windows 10 64 Bit (I tested it on two computers with similar settings, but a MinimWatch 0.8-version, with same problem)
3. BubbleUpnp on Android (everything works fine there)
   

[simoncn]

The minimwatch.log file in this directory:

C:\Users\your-user-name\AppData\Roaming\MinimWatch\data

should contain additional information that would be useful for diagnosing this problem. Please zip this file to save space and attach the zipped file to a post here.

The AppData directory is hidden by default in Windows Explorer. You can open it by typing the full path into the Explorer address bar.

[bjoernminim]

Thanks Simon, for getting in that fast. Attached you'll find the file. Indeed there is additional information: Beginning in line 696 there are errors concerning fetching the device.xml. He tries the correct server 192.168.178.36, but probably the wrong port (0): Fetch for http://192.168.178.36:0/eb4e93de-9bb6-48...evice.xml.

[simoncn]

Thanks for this. I agree that the 0 port number is causing the problem. Please check the setting for ohnet.port in MinimServer. Is this 9791 or 0?

[bjoernminim]

Thanks, Simon. I could solve my problem thanks to your hint. For people with similar problem, here the steps taken:

1. Because MinimWatch was not running, I could not verify, on which port ohnet.port was set. I tried to change minimserver.config on my NAS in the appdata folder, but this broke the integrity check.
2. I then deleted all minimserver.config...-Files in the appdata-Folder (of course not without a backup)
3. I stopped and started the minimserver-package on my Synology NAS
4. I opened the Web GUI under 192.168.178.36:9790 in my case and accepted the licence rules
5. I started again MinimWatch on my Windows Client and could reconfigure from scratch (which wasn't that difficult because of the minimserver.config-Backup
   

[simoncn]

Did you accidentally set ohnet.port to 0 previously? Perhaps I should do some sanity checking of this but I am not sure which values (apart from 0) should be rejected as invalid.

If you were trying to clear a previous custom setting of this value, you should blank out the field rather than setting the number to zero.

Also, I am surprised that BubbleUPnP could discover MinimServer with this setting.

Edit: Apparently anything between 1024 and 65535 is valid.

[bjoernminim]

I have no clue, from where MinimServer got that setting, because I for sure didn't change the ohnet.port myself. But it is more than two months ago that I used MinimWatch the last time - so a lot could change since then (Windows Updates, NAS Updates, ...).

To be sure, it had something to do with the port: In the minimwatch.log-File now it correctly sets the url for xml fetching: Fetch for http://192.168.178.36:9791/d9b539a2-4614...evice.xml.

[simoncn]

This is quite mysterious as I have not been able to reproduce the problem after setting ohnet.port to 0. ohNet checks for a port number setting of 0 and dynamically allocates a new port number. This is why BubbleUPnP was working.

When you tried to edit minimserver.config before deleting it, did it contain a setting for ohnet.port? Was this set to 0?

[bjoernminim]

No, minimserver.config didn't contain neither a http.port nor a ohnet.port-Setting.

In the meanwhile I deleted the minimserver.config - sorry for that. But I downloaded the new minimserver.config from appdata. As far as I can tell, it looks more or less the same as the one, which lead to the problem with port 0.

[simoncn]

Thanks for your help with trying to find the cause of this problem.

I have looked carefully at the MinimServer code and I can't think of any chain of events that could have led to this, so it will need to remain a mystery for now. Please let me know if it happens again.