^
There are two ways that the Oppo can play files from MC -- namely 1) when you use the Oppo UI to browse the MC content directory and use the Oppo to initiate playing (this is called "pull" mode), and 2) when you use the MC UI to browse the library and use MC to initiate playing (this is called "push" mode).
As far as meta data display is concerned, the Oppo seems to have different behavior between "pull" and "push" modes. Also it has different behavior depending on what media format is being played (e.g. MP3, Flac, PCM).
I don't know the exact inner workings of the Oppo, so the following description is partly speculative...
In "pull" mode, the Oppo reads track information from MC via the UPnP ContentDirectory::Browse method, and the response to this command contains the media url (what the Oppo downloads to play), the track meta data (track name, album name etc.), and an url for downloading the album art.
By contrast, in "push" mode, MC sends track information to the Oppo via the UPnP AvTransport::SetAvTransportUri method, and this command request contains the media url, the track meta, and album art url as above.
Now (this is where it gets a bit speculative) it may be that when the Oppo plays a media file from MC, it either a) tries to read meta data provided in MC's Browse response (pull), or b) tries to read meta data provided in MC's SetAvTransportUri request (push), or c) tries to read any tags actually embedded in the media file itself. In the latter case obviously it could only take tags if the media format supports such tags, if such tags actually exist in the file, and only when it has read enough of the file to have gotten to the place where the tags are located. So if tags exist at the start of the file (e.g. in native MP3s) they would be available at the start of playing, if tags exist at the end of the file they would only be available at the end of playing, and if there are no tags (e.g. in PCM) they would not be available at all. Also, it should be noted that when MC is serving a native Mp3 (that may have embedded tags at the start of the file) those tags will of course exist. Whereas if MC is transcoding from any other music format into Mp3 then MC does not put any tags in the transcoded file.
As general rule, the Oppo seems to be better at displaying meta data in "pull" mode than it is in "push" mode. This may be because it looks for embedded tags and does so better when it is in pull than in push mode. In this case I don't see any logical reason why the mode should make any difference. And there is certainly nothing that the MC developers could do to improve the situation in this case. Or it may be because it looks for meta data in the Browse response and/or the SetAvTransportUri request and is able to understand the former and not the latter. In this case I don't see any logical reason why the Oppo would be able to understand the one but not the other because the data are in both cases in the same format. But in this case it might be that the MC developers could improve the chances of the Oppo understanding its tag values, by tweaking the "dialect" of their message payload (the so called DIDL), however this could only be done if there were a direct dialog between the MC developers and the Oppo developers (something which we have so far not been able to set up).
Hope this helps...