It depends very much on your renderer, and on the remote stream server, and very little on MC itself..
The UPNP / DLNA mechanism for pushing to a renderer is that the Control Point (MC) sends a command SetAVTransportURI to tell the renderer a URL that it should play, and then it sends a command PLAY to tell it to start the actual downloading and playing. Then the renderer does an HTTP GET command to fetch the actual music.
When this GET is for a track that is local on MC then MC can ensure that its response to the HTTP GET is strictly conformant to the UPNP / DLNA specifications; so for example it can transcode the media to a format that the renderer supports, and provide HTTP ContentLength and ContentType headers. But if the GET is sent to a remote streaming source, then MC is not in the loop, and the remote streaming source responds to the GET directly. And if the remote stream server doesn’t provide the right ContentType, or omits (say) a ContentLength header, then the renderer might fail to play the track.
One possible future solution would be for MC to put itself back in the loop when a renderer is attempting to play remote streams. So instead of passing the renderer the direct URL of the remote stream server via the SetAVTransportURI command, it would pass a proxy URL on its own server. Then when the renderer issues it’s HTTP GET, MC would download the remote stream into its own buffer and retransmit the data to the renderer whilst also adding any missing HTTP headers, and/or transcoding the media format if necessary.
PS I think this proxying mechanism is how BubbleUPNP does it..