Problems with MinimWatch and Updates

[Oliviander]

(19-04-2021 22:11)simoncn Wrote:  Thanks very much for these logs.

It looks like the machine running MinimWatch has the IP address 172.19.0.66. What devices have the IP addresses 172.19.9.100 and 172.20.25.31?

How does the 172.19.0.0 subnet communicate with the 172.19.9.0 subnet?

How does the 172.20.9.0 subnet communicate with the 172.20.25.0 subnet?

Do you have Minimwatch 0.8 running anywhere in your network?

There are some anomalies in the server logs for test 2 and test 3. This might be because the server was not restarted before running test 2 and before running test 3.

I would like to focus on test 3 because this shows the problem and provides a reasonable amount of log information. Please run test 3 again but this time stop and relaunch MinimServer before you start the test. Many thanks.

172.19.0.66
Machine WIN10 running MinimWatch

172.19.9.99 and 172.20.9.99
Debian VM running Minimserver Instances with 2 network cards

subnets are 172.19.0.0/16 and 172.20.0.0/16
so the other machines are in the same subnet as the Minimserver VM

172.19.9.100 is a VM running Roon

172.20.25.31 is a VM that has nothing to do with Audio

Minimserver 0.8 isn't running anywhere

I already restarted the servers before each test
but to be sure I've uploaded another pair of files that
I made after reboot of the VMs debian system
and waited a long time until the Test Instance was discovered

[simoncn]

Thanks for this. In the failing scenario, MinimWatch sends six multicast discovery messages in quick succession. Only messages 1 and 2 are received by MinimServer. When you have Debug/All enabled in MinimWatch, there is a small gap between sending the six messages. In this case, messages 1, 2 and 4 are received. For discovery to work, it is essential that message 4 or 5 is received.

I am not sure yet whether it is your router that can't handle six messages sent in quick succession or an issue with how MinimServer (ohNet) reads these messages.

A simple workaround should be for MinimWatch to add short delays between sending the six messages. I will produce a test build for this and send you details by PM.

Thanks very much for all your work on running these tests and sending me the logs.

[Oliviander]

(20-04-2021 11:32)simoncn Wrote:  Thanks for this. In the failing scenario, MinimWatch sends six multicast discovery messages in quick succession. Only messages 1 and 2 are received by MinimServer. When you have Debug/All enabled in MinimWatch, there is a small gap between sending the six messages. In this case, messages 1, 2 and 4 are received. For discovery to work, it is essential that message 4 or 5 is received.

I am not sure yet whether it is your router that can't handle six messages sent in quick succession or an issue with how MinimServer (ohNet) reads these messages.

A simple workaround should be for MinimWatch to add short delays between sending the six messages. I will produce a test build for this and send you details by PM.

Thanks very much for all your work on running these tests and sending me the logs.

Interesting

You said that these are mulitcast messages.

I am in a complex enterprise level network
between the VM running the minimserver instances
and my PC running Minimwatch
there are 5 switches
(including the openVswitch on the proxmox node)

At least some of them have Stormcontrol for multicast enabled
for security.
So there might be an issue if these messages come too fast.

I'm looking forward to your test build
thx for your support

[simoncn]

One more thing to add. For 0.8, there were only three messages and message 1 or 2 needed to be received. This is why 0.8 discovery was working for you.