Print

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

[AndrewFG]

Hi bob,

When MC publishes DIDL-Lite music track items it includes one albumArtURI element having the dlna:profileID="JPEG_TN" and the respective image is sized at 300x300 pixels.

But on the other hand the DLNA Interopabilty Guidelines define the following image profiles:

JPEG_TN   size must not exceed  160x160 (horizontal * vertical)
JPEG_SM   size must not exceed  640x480
JPEG_MED size must not exceed 1024x768

So apparently the 300x300 that you offer exceeds the DLNA guidelines (??) -- and so I wonder if perhaps you should be offering multiple albumArtURI elements with e.g. JPEG_TN 160x160, JPEG_SM 480x480, and (say) JPEG_MED 720x720.

Note: Whitebear offers two, namely JPEG_TN 160x160 and JPEG_SM 720x720 and admittedly the latter also exceeds the DLNA guidelines.

[bob]

Haven't looked at that in a long time.
Can one use more than one albumArtURI element?
IIRC, I've only ever seen JPEG_TN for albumArtURI in the myriads of content directory listings I've seen.
We use our existing TN's since they are pre-generated.

All other images we serve have the proper SM, MED and LRG suffixes.

[AndrewFG]

Can one use more than one albumArtURI element?

Yes it is allowed to have more than one.

The specs say that at least one of them shall be 160x160 JPEG_TN profile. And I think actually my suggestion would be to offer a second image at its full native size and with no DLNA profile attribute (i.e. a pure vanilla image offerring). That way, those CPs that have larger hi-def screens can show the larger image at hi-res.

I would suggest to do this both on the ContentDirectory items and on the Renderer Play To (SetAvTransport.. commands) so that hi-res CPs can benefit both on content directory browsing, and on their now playing screens.

[csimon]

I fully concur with that!

But are CP's sensible enough to look for appropriate ones, so that they display the TN ones when browsing artwork in a grid but choose the full-size ones for Now Playing? Or do they use the same image regardless of where it used?

[AndrewFG]

But are CP's sensible enough to look for appropriate ones... ?

Aha. A philosophical question indeed. ;-)

[bob]

It seems the PS3 will not accept a larger image with JPEG_SM and it won't accept anything without the JPEG_TN attribute. It will accept a large image with JPEG_TN though. Since there are already special tweaks for the PS3 I just added this one.

Now the album art can show up as an upnp:albumArtURI or a resource. As an upnp:albumArtURI, I not certain about having more than one. As a image resource that comes with the primary object, it seems fine.

I've changed the didl to offer a 160x160 (scaled to aspect ratio) as the standard TN and 400x400 (also scaled) as an alternative.
400x400 is our largest generated thumb (that may change).  I don't think we'll serve raw images, there are too many downsides.

[vagskal]

The change regarding cover art made in beta .33 (accessible only to beta testers) made the cover art look crappier than ever in iPeng.

[bob]

The change regarding cover art made in beta .33 (accessible only to beta testers) made the cover art look crappier than ever in iPeng.

I don't know how to control which image the client grabs. I tried putting the better image first but that seems not to work in your case.
Andrew, do you have any comments on this? How does WhiteBear pick the image?

vagskal, you can force reversion to the old behavior by turning on the PS3 Compatible switch under advanced. Unless you are playing video as well, the other PS3 tweaks will not affect anything other than the cover art display.

[vagskal]

Thanks for the reply. I am sure Andrew will sort it out. I still use v. 17 Media Server and just switched to v. 18 to test this.

[AndrewFG]

I don't know how to control which image the client grabs. I tried putting the better image first but that seems not to work in your case. Andrew, do you have any comments on this? How does WhiteBear pick the image?

At the moment Whitebear just picks the first one. But that seems to clash with vagskal's statement that the first one (the better one) looks worse (?)

However, I plan to have Whitebear iterate through them all and choose the best (biggest). This is why I support each one having appropriate JPG_TN, JPG_SM, JPG_MED, JPG_LARGE attributes because that gives an immediate information about the image size, whereas if all images would have the same JPG_TN attribute, then the client is forced to do a HTTP GET on each image in order to evaluate which is the best.

[vagskal]

iPeng (for iPad) has the ability to show the cover art in its original size. After the change the original image was much smaller than before, really tiny.

[AndrewFG]

As an upnp:albumArtURI, I not certain about having more than one.

In the specification ContentDirectory:1 Service Template Version 1.01, Chapter 6. Appendix B - AV Working Committee Extended Properties, for upnp:albumArtURI under Multiple Values, it says "yes".

[bob]

MC is supplying the art as both an albumArtURI and as a resource (if DLNAEXtra is enabled).

Now I am unsure as to whether it's legit to supply multiple albumArtURI's and whether JPEG_SM is supposed to be ok there.
The PS3 for example, ignores all JPEG_SM's in both the albumArtURI and resource entries.
If I simply remove the profileid from the albumArtURI, the PS3 also ignores the image.

So what I decided to do it to put the compliant image first in albumArtURI and the larger image second hoping that the renderer would pick the best resolution image.
When they are provided as a resource, since one can have any number of entries there, I put the large image first.

Perhaps the only way to handle this is to add a switch to relax contraints on compliance with the DLNA_TN size limits.

I'm wondering also if perhaps adding the size to the entry would help (instead of just relying on JPEG_TN and JPEG_SM).

[bob]

In the specification ContentDirectory:1 Service Template Version 1.01, Chapter 6. Appendix B - AV Working Committee Extended Properties, for upnp:albumArtURI under Multiple Values, it says "yes".

Well then maybe I'll flip it back around in albumArtURI and do some more testing. It's disconcerting that the PS3 won't take anything other than JPEG_TN since the 160 pixel images look pretty bad on a TV.

[AndrewFG]

Well then maybe I'll flip it back around in albumArtURI and do some more testing. It's disconcerting that the PS3 won't take anything other than JPEG_TN since the 160 pixel images look pretty bad on a TV.

I think I opened a can of worms here...

[bob]

I think I opened a can of worms here...

Well, it's important to be compliant. If any renderers are allocating space based on the JPEG_TN flag, they are likely to be unhappy that the image is out of bounds.

[AndrewFG]

Well, it's important to be compliant. If any renderers are allocating space based on the JPEG_TN flag, they are likely to be unhappy that the image is out of bounds.

Indeed.

In the current beta of Whitebear, the ContentDirectory now offers a JPEG_SM image and a JPEG_TN image too; it offers the larger one first. Also in the current beta of Whitebear, the SetxxAvTransportUri actions now scan all albumArtUri tags, looking for JPEG_MED, JPEG_SM or JPEG_TN images; and selects the largest of the three profiles it can find. The new version of Whitebear is coming out soon.

[bob]

Indeed.

In the current beta of Whitebear, the ContentDirectory now offers a JPEG_SM image and a JPEG_TN image too; it offers the larger one first. Also in the current beta of Whitebear, the SetxxAvTransportUri actions now scan all albumArtUri tags, looking for JPEG_MED, JPEG_SM or JPEG_TN images; and selects the largest of the three profiles it can find. The new version of Whitebear is coming out soon.

Cool, that sounds like a nice solution!

[AndrewFG]

I've changed the didl to offer a 160x160 (scaled to aspect ratio) as the standard TN and 400x400 (also scaled) as an alternative.
400x400 is our largest generated thumb (that may change).  I don't think we'll serve raw images, there are too many downsides.

Bob, do you offer both images as JPEG_TN? Or is the smaller one served as JPEG_TN and the latter as JPEG_SM? (I hope the latter).

I do hope we can also convince you to offer a third image in JPEG_MED size, since 400x400 is rather furry for (say) an iPad screen.

[vagskal]

FYI: iPeng on iPad uses 768x768 images in its now playing screen.

[bob]

Bob, do you offer both images as JPEG_TN? Or is the smaller one served as JPEG_TN and the latter as JPEG_SM? (I hope the latter).

I do hope we can also convince you to offer a third image in JPEG_MED size, since 400x400 is rather furry for (say) an iPad screen.

The latter.

We are considering a larger one. The nice thing about the current ones is that they don't have to be generated on the fly.