I couldn’t find anything useful - maybe it’s unusual to have two juce apps running simultaneously? Here’s the story:
I have an app JuceA sending udp heartbeat-packets every second to some recipients (embedded hardware) on Port 1000. This is working well for years now.
Also I can monitor the incoming packets with an app called “packet sender” (very handy third party networking utility) when I run JuceA with a 127.0.0.1 recipient configured.
Now I wrote a monitor app JuceB that can receive that same data to display it in a way as it would look on the hardware. (just for debugging and preparation of JuceA)
If I start JuceB and use the “packet sender” to generate and send it packets, it behaves exactly as expected.
So far so good, JuceA and JuceB seem to run correctly.
But when I use them both (on the same machine, SurfacePro4/W10), nothing happens at JuceB. Just no packets are received.
And here’s the funny part:
When I additionally kick in the “packet sender” and send dummy packets with it, then sometimes the content of a JuceA packet is displayed (visually distinguishable in JuceB).
Not proven, but it seems to take one third party packet to receive one juce packet.
Debugging JuceB, I could prove that
socket.read(buf, 40, false) continuously returns 0 in the receiving thread’s run() loop, unless “packet sender” is talking.
The same happens if I use the local IP instead of 127.0.0.1.
Port numbers below 1024 are tricky (can’t bind without root on some systems), but cant’ be an issue here as it is receiving from the “packet sender”.
Any ideas of internal triggers that are excluding each other when run on the same machine? Some systemwide juce singletons or shared buffers that get scrambled when there is a second instance of juce (though a different app)?
Thanks for any hints!
Well, my main app is working flawlessly at least - but I’d like to start using my new tool