As a learning excercise I'm writing a simple server in C that controls multiple MPDs and SnapCast servers, and have come across an oddity.
I have the MPDs set up as one (port 6600) being the master, and the rest setup as slaves/satellites (ports 6601,2,3,4).

The library of audio files are mounted at /mnt via SMB on boot, and the master and satellites use music_directory "/mnt" to attach to it.

The satellites use the masters db via (with media being the name of the machine all the MPDs are running on):

This gives the expected result - a songs URI is printed. However, changing <master> to one of the satellite connections produces an approx 1s pause between “Search commited” being displayed, and "Song URI..." displaying.

The same result occurs if you use the search command directly via Telnet: on the master it shows the song URI instantly, but via a satellite there is an approx 1s pause between pressing <ENTER> and getting the song URI.

Is this the expected behaviour? If so, is there a way to remove the delay?

I would expect the master and satellite MPDs to each have a permanent (in this case) SMB connection to the music server, and the satellites to have a permanent connection to the master. Assuming the song URI comes from the tag database maintained by the master, I wouldn't expect there to be noticeable difference in getting it directly or via a satellite.

I just spent 3 hours building and installing Debian Unstable on a test PC to compile MPD 0.20.21, and noticed that 0.20.21 has been slipped into their repository, so i upgraded the media machine - hope that's good enough.

You should have the latest MPD on both machines. Any setup which involves an outdated MPD version will not be supported.

But in any case, the "proxy" plugin is currently unable to forward "window" to the next MPD, thus it receives the whole dataset and only then crops the window for its own MPD client. This is my best guess for the delay.