Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nycjazz]

Here is my config:  Mac mini with hdmi to oppo 105, oppo to TV.  iPhone/ipad as DLNA controller.

1.- I reinstalled jriver 19 (with registration)
2.- created DLNA connection to oppo and it plays fine
3.- all info shows up fine on iPhone/ipad per screenshot
4.- No information is displayed out of oppo on tv, just generic, unfilled headings (no cover art either).

[nycjazz]

with actual screenshots of music playing.

[nycjazz]

sorry, version is 19.0.103

[MrC]

The iPhone/iPad w/JRemote are using the MCWS service of MC, and the Oppo is using DLNA, so they are different protocols.

I wonder if using PCM is causing the trouble for the DLNA device?

[nycjazz]

If i navigate from the oppo to Networks, the oppo sees the JRiver DLNA.  I can then navigate through the oppo and when I select a song, all the information (except for the image) is displayed on the screen.  This, however, is using the Oppo, not JRiver as the interface so I dont want that. 

I also remember playing with the settings (which is why i did a complete reinstall) where I could push an image from my iPhone/ipad onto the screen and have that while the music played.

All files are FLAC, with album.jpg in the same folder.

I tried all the setting (all mp3s, pcms) but nothing shows up on the screen...

[nycjazz]

I reset the program.  Went back to Generic DLNA and now the information shows up.  I change to PCM and the info goes away.   Is it possible to get the information I see on my iPhone/ipad while using PCM?  that seems to be issue.  Even for mp3, I do not see the artwork. 

[MrC]

I wasn't aware that PCM carried metadata such as this.

[nycjazz]

"I wasn't aware that PCM carried metadata such as this."

Ok, so if this is a restriction of PCM, it is what it is.  My question is how come accessing the DLNA directly through the Oppo via the network gives the information, don't they both go through the same protocol?    Also, I able to push art cover from my iPhone/ipad onto the tv screen, but I can't anymore, even with settings on mp3.  Am i missing some simple setting.

Picture of the Oppo TV.  When I click on the JRiver icon, I then get the metadata on the screen (no pic through), even when DLNA is set to PCM.  Again, I'd like to know if that is possible with the JRiver app.

[MrC]

I'm no expert on this, but here's what I think is probably going on, in laymen's terms.

When you use the Oppo to request (pull) files, it gets back browse structures to show you the different categories or media trees (i.e. Audio, and the Artist, Genres, etc.).  So it has that data, because it asks for it.  At the end of the browse tree, you see the artist name, because it was a directory listing essentially, as asked for by the Oppo and provided by MC.  Then it request the file to be streamed.

In the other direction, a push by MC (the controller) is essentially blasting a bunch of bits to the renderer (Oppo), and whatever are in those bits has to be interpreted based on the type of file and the metadata it supports.  The Oppo didn't ask for data one level at a time; it just was told Play This Stuff.

Perhaps one of the DLNA experts will chime in.  I've changed the title on my post so it might be noticed.

[AndrewFG]

^

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...

[nycjazz]

Thank you.  This kind of makes sense. So I played a bit more and I can get lossless metadata (no image still) when I use Aiff.    Somewhere the data is not getting passed.  So with FLAC nothing gets passed, but the metadata and image are there because I linked the OPPO and the TV and all the info from FLAC shows up, and the picture (as you can see below).  This is not a workable solution as the music streams from both with a delay and the pre-buffering at the beginning of the song knocks out the sound through the oppo.  Still, this shows (if Im correct) that the metadata can be pushed from FLAC.  Thoughts?  If the data is there, it would be great to see it for FLAC on the screen.  I have not tried this, but assume that embedding the image in mp3 would show the cover, but mp3 is not an option for me for SQ reasons.

[MrC]

Thanks AndrewFG for that excellent info.  It occurred to me that the push AvTransport::SetAvTransportUri might contain metadata as well as the URI, but didn't have the time to confirm last night.

@nycjazz - both AndrewFG and bob @ jriver have been engaged in Oppo discussions in the Media Network forum, so if you need additional Oppo info, that's a good place too.

I'm going to move this thread to that Forum.

[nycjazz]

Thanks!   I will follow it there.  I just noticed that the latest screen capture was for aiff file, not FLAC  .   When I link oppo to the tv for FLAC files, nothing happens on the screen.  thanks for the help!

[AndrewFG]

When I link oppo to the tv for FLAC files, nothing happens on the screen.  thanks for the help!

Hmm. Your screen shots and your explanation in the last two posts is rather confusing, so let me just confirm that I understand your setup properly.

• You have MC running on a PC (Mac) connected to your network and acting as a UPnP / DLNA server.
• You have an app on your iPad connected to your network and acting as a UPnP / DLNA control point. Which app is it?
• You have your Oppo connected to your network and acting as a UPnP / DLNA player.
• Your Oppo is also connected to your TV via HDMI.
• Your PC is also connected to your TV via HDMI.

Is the above correct? If so, then can you please also explain exactly what you were doing when you made the two photos of your TV screen? In your first post I recognize that your photo "tvscreen.jpg" (not showing any meta data) is a picture of the Oppo's output screen when playing a file via UPnP / DLNA. But in your later post your photo "ab1.jpg" (showing meta data) is something quite different which I don't recognize at all.

[MrC]

You have an app on your iPad connected to your network and acting as a UPnP / DLNA control point. Which app is it?[/li][/list]

FYI: It's JRemote, which uses MCWS, not DLNA.

[nycjazz]

For the last picture it was a screenshot of using the JRiver app on my iPhone where I linked the TV and the Oppo.  This was for an aiff file.  When I do the same for a FLAC file, I get blanks as shown in the first screenshot in the thread.  The connections are

thunderbolt>macmini>Oppo (hardwired)> TV

Push>jriver app>shows up fine (for flac apps) on my JRiver app (screen capture at beg thread)> shows w/o any metadata on TV screen
Pull> from DLNA instance via oppo> shows all metadata (except for picture) (no involvement from JRiver app)
Push?>  jriver app> linked oppo to TV(IAFF ONLY) > shows all metadata and image.  no progress bar.
Push?> jiver app> linked opop to TV (FLAC ONLY> same as first push, no metadata on screen.

Hope this helps.

[AndrewFG]

Push?>  jriver app> linked oppo to TV(IAFF ONLY) > shows all metadata and image.  no progress bar.
Push?> jiver app> linked opop to TV (FLAC ONLY> same as first push, no metadata on screen.

Hope this helps.

Not really    what do you mean by "linked oppo to TV"

[nycjazz]

Not really    what do you mean by "linked oppo to TV"

JRiver remote has the ability to link zones. Per the last screenshot, i linked the oppo to the TV. 

[MrC]

You're using the terms "JRiver remote" and "JRiver app", but this is confusing others, as a) the app you are using is named JRemote (and is not a JRiver product), and b) JRiver does have an app, but it is called Gizmo (and it is for Android).

The more clear and precise you can be, the better help you're likely to get.

[nycjazz]

Sorry about that.  The app is JRemote, its in my phone and my iPad, and it is the one i refer to pushing info.  I do not use Gizmo.  Pulling info is from the oppo network interface.

[MrC]

No problem.

JRemote does not push, nor pull, in this situation.  Rather, it uses a protocol to request that MC undertake some action (such as link a zone, initiate playback, or whatever).  From there, MC would do any pushing of content to your DLNA devices.  In other words, JRemote just acts as a sophisticated remote control device, controlling MC.

[AndrewFG]

^

MrC do you think that when he talks about "linking the Oppo to the TV" this is causing MC to push the same track to both his Oppo and to his TV at the same time? This would explain why his first screen shot (unlinked) shows an Oppo screen whereas the second shot (linked) shows a completely different screen which is presumably that of the Renderer in his TV.

[MrC]

Yes, this zone linking is described here:

    http://wiki.jriver.com/index.php/ZoneLink

MC is creating the link (as requested by the JRemote UI via the MCWS protocol), and MC pushes the track out to each one independently.  So from your perspective, you can think of it as MC pushing the same track to two different DLNA renderers at the same time.  I'm not clear how MC handles the case where one renderer requires transcoding and the other plays the file natively.

It seems like that one of the screenshots is the Oppo's HDMI output when there is a DLNA push.

[AndrewFG]

^

Ok nycjazz...

Let's forget the iPad JRemote app; it's got nothing to do with your issue, and it works fine.

Also let's forget the linking with your TV; it only shows that rendering to your TV works fine, and otherwise confuses the issue.

So let's just concentrate on the Oppo: Please tell me when you are pushing to the Oppo, which media formats do show meta data on the Oppo playing now screen, and which formats do not. Also please answer the same question when you are using the Oppo to pull tracks.

[bob]

Just FYI, linking zones that include DLNA devices is usually not deterministic enough to get synchronized sound.

[AndrewFG]

^

FWIW following are my test results (I did not test all formats like WMA, APE etc.)

• PUSH: NATIVE: DFF => Music plays / No meta data / No album art
• PUSH: NATIVE: FLAC => Music plays / No meta data / No album art
• PUSH: NATIVE: M4A => Music plays / No meta data / No album art
• PUSH: NATIVE: MP3 => Music plays / Displays meta data / Displays album art
• PUSH: NATIVE: WAV => Music plays / No meta data / No album art
• PUSH: TRANSCODED: MP3 => Music plays / Displays meta data / No album art
• PUSH: TRANSCODED: L16 => Music plays / No meta data / No album art
• PULL: NATIVE: DFF => Music plays / No meta data / No album art
• PULL: NATIVE: FLAC => Music plays / Displays meta data / Displays album art
• PUSH: NATIVE: M4A => Music plays / Displays meta data / No album art
• PULL: NATIVE: MP3 => Music plays / Displays meta data / Displays album art
• PULL: NATIVE: WAV => Music plays / No meta data / No album art
• PULL: TRANSCODED: MP3 => Music plays / Displays meta data / No album art
• PULL: TRANSCODED: L16 => Music plays / No meta data / No album art

My conclusion, (I think), is that in those cases where the Oppo succeeds in displaying meta data or album art, it is doing so by parsing embedded tags within the media stream.

And to be specific, (I think),  it is not getting meta data by parsing the DIDL payload in the SetAvTransportUri request, or the Browse response. Nor is it getting album art by doing a get on the AlbumArtUri.

NB I would have to do WireShark captures to find out more. But I am not sure if I want to go that far

EDIT: and BTW my conclusion is, (I think), that there is nothing more that MC could possibly do to improve the situation. IMHO its up to the guys at Oppo to make the next step...

[MrC]

...it is doing so by parsing embedded tags within the media stream.

Your findings seem to be in agreement with my hunch hinted at above (in my layman's description).  I'd suspect they just reused their tag-reading libraries to obtain metadata, and a) didn't want to rely on the DIDL, and/or b) didn't want to write more code to override the tag cache.

[AndrewFG]

I'd suspect they just reused their tag-reading libraries to obtain metadata, and a) didn't want to rely on the DIDL, and/or b) didn't want to write more code to override the tag cache.

I think they use a UPnP development kit from a 3rd party software house (I think it is called Mediatek), and I suppose they only use the features in that library and don't want to (don't have the skills to) extend / modify the functionality.

[bob]

I think they use a UPnP development kit from a 3rd party software house (I think it is called Mediatek), and I suppose they only use the features in that library and don't want to (don't have the skills to) extend / modify the functionality.

From what I can tell, none of these guys who contract out for this stuff want to do firmware updates, it's not cost effective in their eyes. They are already working on the "next" product. If that's the attitude, it'd be better for them if they did a little more QA on the release version.

[AndrewFG]

From what I can tell, none of these guys who contract out for this stuff want to do firmware updates, it's not cost effective in their eyes.

To be fair to them, Oppo is very good at issuing bug fixes e.g. when a new release blu-ray won't play properly for some reason.
But as you say, they don't like to extend the feature set. 'cos that would remove the "motivation" to buy a new box from them...

[JohnAV]

To be fair to them, Oppo is very good at issuing bug fixes e.g. when a new release blu-ray won't play properly for some reason.
But as you say, they don't like to extend the feature set. 'cos that would remove the "motivation" to buy a new box from them...

As a FYI Oppo isn't like other BD vendors, if the user community constantly asks for some functionality, they will try to provide it.

If you look at their FW update descriptions you would see that its not just about BD playback compatibility updates, and bug fixes.   Take a look at this 103 update and see how much has been added.  http://www.oppodigital.com/blu-ray-bdp-103/BDP103-firmware-67-1204.aspx

The model changes when technology improvements warrant it, such as the change from 103/105 to the 103D/105D, not on a yearly cycle.

[MrC]

From what I can tell, none of these guys who contract out for this stuff want to do firmware updates, it's not cost effective in their eyes. They are already working on the "next" product. If that's the attitude, it'd be better for them if they did a little more QA on the release version.

This is so true.  And it causes me shy away from using/recommending/relying on Checkbox Item features in appliances.  Vendors rarely provide corrections or features updates, and the risk/reward ratio is not in consumer's favor.

It is good to hear that some vendors (like perhaps Oppo) at least try to address issues.

[nycjazz]

You guys are awesome, I ran the same tests and got the same results.  I will bring it up to the Oppo folks. Thanks again!

[JohnAV]

^  I brought this thread to their attention, earlier.  Thanks for pursuing this functionality in MC.

[nycjazz]

"PULL: NATIVE: FLAC => Music plays / Displays meta data / Displays album art"

Album art not displayed when FLAC is just in the same folder as the album (album.jpg)

[MrC]

Album art not displayed when FLAC is just in the same folder as the album (album.jpg)

For that FLAC file, does MC's Image File field show the name "album.jpg", or something else?  You can find the Image File tag in the Tag Action Window, when you Show All Fields, or add a column to the file list.

[AndrewFG]

"PULL: NATIVE: FLAC => Music plays / Displays meta data / Displays album art"

Album art not displayed when FLAC is just in the same folder as the album (album.jpg)

That is correct. There are two ways of storing album art: one is to embed the art within the flac file itself, and the other is to store a separate picture in the folder where the flac file is located.

When your Oppo is pulling a flac by UPNP / DLNA it only gets the flac file. So if the flac has embedded art the Oppo will get it, but if the art is in a separate file it will not...

[nycjazz]

"That is correct. There are two ways of storing album art: one is to embed the art within the flac file itself, and the other is to store a separate picture in the folder where the flac file is located.

When your Oppo is pulling a flac by UPNP / DLNA it only gets the flac file. So if the flac has embedded art the Oppo will get it, but if the art is in a separate file it will not..."

I have no storage issue to embed, but is there a sound quality issue if I decide to embed for my FLAC files?

[AndrewFG]

I have no storage issue to embed, but is there a sound quality issue if I decide to embed for my FLAC files?

There is no sound quality issue. The player knows how to separate the audio stream from the rest.