This is a communication line in the trace that (according to what I am reading) is indicating the buffer is filling up on the Kef speaker. In this case, the "Zerowindow" response from the renderer is telling the server to stop sending data until the renderer reports back that the buffer is ready to receive more data. One might surmise the data exchange between the server and the renderer is not being managed correctly. As I understand it, a device that is receiving data and acknowledging receipt of the packets is also letting the device (server) supplying the data know how much room the receiving device (renderer) has left in the buffer. So the sending device knows how much can be sent on the next data packet transmission. This also works in reverse in that the server is also letting the renderer know how much space is left in its buffer before the renderer replies. How all of this correlates to the loss of audio at the track change is beyond me.
Anyway, the reason I am suspecting an application setting is wrong is that audio dropout was worse with setnext support disabled. I got several back to back Zerowindow lines from the renderer to the server rather than just the one line of Zerowindow with setnext support enabled. The odd thing was there were no lost packets according to the trace in either case.
Again, I am no expert here and I could be wrong about my assessment. But I am thinking that this is more of a data management/communication issue between server and renderer rather than network issues.
I really like MC's audio capabilities so it is my hope to get this resolved before my trial period ends this week.
Any help is greatly appreciated.