There is a possible workaround, but it would be a bit of a kludge, and hasn't been tried.
Hmm. I am beginning to think that the guys at JRiver ought to try it. There are two potential models for pushing a remote stream to a UPNP renderer:
a) Control Point hands off the stream URL to the renderer, which downloads it directly
b) CP reads the remote stream to local buffer, and serves to the renderer from itself
And RoderickGI is suggesting a variation on model b)..
c) CP read the WDM input to local buffer, and serves to the renderer from itself
Currently MC only does model a), and sometimes it works, and sometimes it doesn’t: The issue is with the HTTP headers used in the GET request for the remote stream and the 200 OK response from the server..
In model a) (which is what MC does currently) some renderers either don’t send the right HTTP request headers (issue a1), or can’t parse the HTTP response headers (issue a2), or cant handle the response content format (issue a3).
Switching MC from using model a) to using model b) plus c) would certainly solve issue a3) because MC can always transcode to a format that the renderer can handle. It also has already solved issue a1) since MC can in general play most streams locally. So the blocking point would seem to be mostly issue a2) (HTTP response headers).
Now we know that MC can successfully push local files to renderers, so we know that in general it serves response headers that are acceptable by most renderers. (With the occasional glitch here or there). One of the response header errors that have been identified as a problem is the CONTENT-LENGTH header which MC cannot know for an infinite (indeterminate) length stream. Potentially MC could munge this by sending CONTENT-LENGTH=MAX_INT which would probably be Ok. However one would probably also need to figure out a gentle way of responding to a Byte-Range Seek from the renderer that is based on an offset from the start or (worse) the end of a munge CONTENT-LENGTH..
If the above could be overcome, then there would still be other issues. A few that I can think of are i) local buffer overrun or wrap around, ii) bandwith issues or MC cpu overload doing download and serving in parallel (but probably not a big issue), iii) handling (blocking) of MC progress bar, iv) blocking of MC Seek() commands, v) handling of MC Pause()/Play() i.e. continue saving to buffer, or resume play/buffer from live stream, vi) handling all of the above both for the MC main app, and also for its various remote UI apps.
Hmm.