@pljones What is the internal/external IP issue that you are addressing? Since I am often supporting uses that trip over localIP/ExternalIP/NAT issues, I am interested in following the full range of issues. THX

Think of a LAN behind an external router. (I'll not get into the router configuration for ports.)

Say the Directory is 10.0.1.23
Say the Server is 10.0.1.24

Say the external address of the router is 86.212.104.22

When an internal client wants the server IP, it wants 10.0.1.24

When an external client wants the server IP, it wants 86.212.104.22

Now say a server not on the LAN registers with an IP address of 37.141.86.185

When an internal (to the directory) client wants the server IP, it wants 37.141.86.185

When an external (to the directory) client wants the server IP, it wants ... what? Well... 37.141.86.185 if it's not internal to that server but it wants the server LAN address if it is.

I'm not certain what it used to do but I think mine's clearer.

@pljones If the person operating the servers is the only one using a client on the LAN, that person is technically savvy and they can choose whatever they like.

In my case, I want a solution for guest on my LAN. In this case, I want a solution were the guest (being less technically savvy) has the same user experience on my LAN as when connected to the external network. For this goal, I put routing table entries so that the router routes the external IP address to the matching local address.

In your example, an internal client would request 86.212.104.22 and the router will route the messages to 10.0.1.24.
Similar messages to 37.141.86.185 would be routed to 10.0.1.23.

Now we get to the inconsistency of your example.
Your router's external address is 86.212.104.22. All external messages to your private LAN needs to be sent to this router address. I expected the external address for your Directory to be 86.212.104.22:PortA and the Server to be reached at 86.212.104.22:PortB. You would have to set up the port mapping table.

Unfortunately this requires a discussion about routing tables and port mapping. Are you on a path for a different solution?
I believe the desired solution needs to be invisible to the client user (meaning the Jamulus client code doesn't need to know anything about the machinery).

@gene96817 I'm not changing the intended current behaviour, just simplifying the code, as far as I'm aware. If you want to start a discussion on the topic, the discussions area is where you should do it, not during code review.

@pljones Thanks for your work. It just wasn't clear to me what you were trying to fix.

I think the Changelog entry should be made a bit clearer (what would an interested user want to read? What has changed? What is being handled?)

Hopefully nothing has changed. It's to make the code clearer. So it's aimed purely at someone reading the code. Really only smoeone looking at the diff would be interested.

Then the changelog should also say "clarify" and "Code"

Refactoring: Clarify handling of requests for the server list in code

Or similar