Print

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

[th0ut]

If I play from JRiver Media Center to my Denon AVR, and look at image cover on TV or in the phone, the quality of the image is low.

But if I  use JRiver Media Center as DLNA server. Use my phone to select song from this server. Then quality of the image cover is fine, high quality.

In DLNA options, Audio mode = Original, no conversion.

Here is an example how it looks



Is there an option in program to fix that? If not, can you please fix this in upcoming updates. Or maybe add an option for cover quality.

[bob]

..
But if I  use JRiver Media Center as DLNA server. Use my phone to select song from this server. Then quality of the image cover is fine, high quality.
..

How exactly are you doing this option? With a phone remote or other?

[th0ut]

How exactly are you doing this option? With a phone remote or other?

Yes, with program on the phone. Its HEOS app from Denon. I can start playing to my AVR from JR, and then open this HEOS app on the phone and see whats playing, and I can see the cover there. In this app I can open DLNA server that JR is serving and start playing from there.

[bob]

Yes, with program on the phone. Its HEOS app from Denon. I can start playing to my AVR from JR, and then open this HEOS app on the phone and see whats playing, and I can see the cover there. In this app I can open DLNA server that JR is serving and start playing from there.

Is your cover art stored in the tags, album folder or both?

[th0ut]

Yes, cover art stored in the tags of the files, flac files.

[bob]

In your DLNA server settings on MC, advanced, present small artwork should NOT be checked unless that's all your device can handle. Also, DLNAExtra should be checked.
MC will provide several sizes to the renderer, and it's up to the renderer itself which size it chooses.
Many renderers will not choose the larger artwork because they allocate fixed buffers for it.
When you query the renderer for what it's playing you will get the artwork size IT picked.

[th0ut]

In your DLNA server settings on MC, advanced, present small artwork should NOT be checked unless that's all your device can handle. Also, DLNAExtra should be checked.
MC will provide several sizes to the renderer, it up to the renderer itself which it chooses.
Many renderers will not choose the larger artwork because they allocate fixed buffers for it.
When you query the renderer for what it's playing you will get the artwork size IT picked.

Do you mean this one? But its for video, not?



So there is nothing to do\fix here? Or maybe you can add an option in program for artwork size?

[bob]

Do you mean this one? But its for video, not?



So there is nothing to do\fix here? Or maybe you can add an option in program for artwork size?

That Advanced is for everything, not just video.
I don't see that you can change the behavior, it's the renderers choice of artwork that's the issue.
You might try putting a folder.jpg in the album folder, MC's server will present that as an option to the renderer as well but there is nothing that says the renderer has to use it.

[th0ut]

Same low quality cover with just folder.jpg in the album folder, and files without image inside.

Its definitely not AVR issue. I tested with two different apps on the phone, to send files to AVR, and two programs on PC, and cover image displayed on TV and in HEOS app in high quality.

Please, fix it in JR.

[D1os]

Hi everyone! Was there ever a fix for the low quality album cover issue? I am currently using Jriver28 as a server to an auralic Aries g2.1 everything seems fine except the album cover’s quality is very bad. My album arts are for the most part 1440*1440 and up embedded into flac files. Is there a setting in jriver itself that I can change to remedy this situation? 

[VinBob]

Hi All,

I am experiencing the same issues on the latest Mac build where the album cover art is of a much lower resolution and not clear where using a tool such as Twonky Server or MinimServer show the artwork just fine.

Was there ever a solution to this, as I really want this to work so I can go ahead and register a copy for my needs.

Cheers,
Vin.

[bob]

Hi All,

I am experiencing the same issues on the latest Mac build where the album cover art is of a much lower resolution and not clear where using a tool such as Twonky Server or MinimServer show the artwork just fine.

Was there ever a solution to this, as I really want this to work so I can go ahead and register a copy for my needs.

Cheers,
Vin.

Cover art showing in low res WHERE exactly?
There is more than one way a cover art image can be shown and more than one place.

Are you pushing a file to a renderer from MC and seeing it in low res ON THE RENDERER?
Are you pulling a file from a renderer supplied by MC and seeing in in low res ON THE RENDERER?
OR??

[VinBob]

Sorry for the late reply and appreciate the support.

The picture is showing in low resolution on my Lightening DS app that I am using on my iPhone to play audio to my Auralic DAC. However, if I use Twonky or MinimServer, the artwork displays perfectly fine. So someting being changed I would think from JRiver MC Server running on my Mac Mini ??

[krmasson]

I have been experiencing the same for years : when driving my DLNA player from the associated proprietary app (Naim) on my Android tablet, cover pictures are displayed with a very poor quality. However they look fine when displayed by JRiver Panel.

[bob]

MC offers at least 4 different resolution images for cover art.
It's up to the control point to choose the one it wants to display.

I assume your other DLNA server software probably doesn't offer low res images.
The low res images are important because some rendering devices which can display cover art only can handle the low res images.

[brittex]

I am having the same issues in sending to a Wiim. Has there been any progress?
Thanks

[brittex]

Got the following reply over on WiiM forum....

"
brittex said:
JRiver is stating that it sends multiple res images - unless the DLNA setting is checked to only send thumbnails. Mine is not checked
Their position is that Wiim is choosing to use a smaller image even though a higher res image is available

I can see JRiver sending multiple images per track
Code:
<upnp:albumArtURI dlna:profileID="JPEG_LRG">http://192.168.20.12:52100/AArl/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_MED">http://192.168.20.12:52100/AArm/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://192.168.20.12:52100/AArs/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://192.168.20.12:52100/AArt/14.jpg</upnp:albumArtURI>
When I browse to the album using WiiM Home app it seems to be pulling the first (which is what I expected rather than making an informed decision between JPEG_TN/JPEG_SM/JPEG_MED/JPEG_LRG), which in my case was the largest.

If you enable logging in JRiver you can also see - what I believe to be - the request from the app.
Code:
0021146: 3160: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.20.105: GET: http://192.168.20.12:52100/AArl/14.jpg

So by good fortune it seems to be pulling the best image, unless JRiver doesn't always send it in order of quality.

That's not to say that WiiM should be simply be taking the first, as it does with <upnp:artist> so it would be worth leaving some feedback.
"


Does JRiver always send in the same order?
Is there a way to force an order?
Thx

[bob]

Got the following reply over on WiiM forum....

"
brittex said:
JRiver is stating that it sends multiple res images - unless the DLNA setting is checked to only send thumbnails. Mine is not checked
Their position is that Wiim is choosing to use a smaller image even though a higher res image is available

I can see JRiver sending multiple images per track
Code:
<upnp:albumArtURI dlna:profileID="JPEG_LRG">http://192.168.20.12:52100/AArl/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_MED">http://192.168.20.12:52100/AArm/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://192.168.20.12:52100/AArs/14.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://192.168.20.12:52100/AArt/14.jpg</upnp:albumArtURI>
When I browse to the album using WiiM Home app it seems to be pulling the first (which is what I expected rather than making an informed decision between JPEG_TN/JPEG_SM/JPEG_MED/JPEG_LRG), which in my case was the largest.

If you enable logging in JRiver you can also see - what I believe to be - the request from the app.
Code:
0021146: 3160: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.20.105: GET: http://192.168.20.12:52100/AArl/14.jpg

So by good fortune it seems to be pulling the best image, unless JRiver doesn't always send it in order of quality.

That's not to say that WiiM should be simply be taking the first, as it does with <upnp:artist> so it would be worth leaving some feedback.
"


Does JRiver always send in the same order?
Is there a way to force an order?
Thx

It always sends the same order with highest resolution image first. It's up to the renderer to pick the image to use.

[validimage]

When I analyzed this, I did see that MC sends artwork in different sizes.

But I concluded that the underlying issue is in the code that creates and caches the artwork to the database on the initial import.

So even "JPEG_LRG" is degraded on the initial import to the thumbnail database. By degraded, I mean images over a certain resolution are reduced in size and potential quality.

If your original artwork is low res, then you probably will not notice the issue. Examples above seem to be higher res, such as 1200x1200 or larger. The spot to look at is in the MC log as your DMC or DMR is pulling artwork. The log shows the size in KB of the artwork it is pulling.

In every instance I tested, the file size was significantly lower than the original, I believe less than half of the original. It might also be possible to download the file ending in 'AArl/14.jpg' to see the actual resolution and quality of the artwork presented.

I do understand the logic for MC to create a system that converts artwork, in different resolutions, to be stored in a database. The obvious benefits are normalization, caching and allowing database functions to gain performance. And also to maintain compatibility over all of the 3rd party hardware.

However, if an "advanced option" was created to specify "Present Original...", and the initial conversion to the artwork was done as lossless as possible, which is not easy to do with jpg, then this problem should be solved. And allowing us to send one version, like 'JPEG_ORIG", might also work.

Granted, it is the responsibility of the user to ensure the original artwork adheres to some sort of logical standard and understand the database size may increase, but that could be documented in the instructions for the advanced setting.

Just my observations. Hope this does not offend in anyway. My motivation is to hopefully improve the quality of MC in this one area. See https://yabb.jriver.com/interact/index.php/topic,131997.msg914939.html for more information.

[JimH]

I wonder if you're confusing full size cover art with the various sizes of thumbnails.  A thumbnail isn't ever the same as the cover art image.

[validimage]

Thank you for your response. I might not be using the correct words, but I am trying to reference the artwork image that is returned to the DMC, in my case. For example, when selecting an album to play, and choosing the now playing tab on BubbleUPnP on the android tablet. The image on the tablet is approximately 4" square, or even larger if you click on the artwork to make it take up the whole screen. What I noticed was a perceptible decrease in quality compared to when I use kodi or foobar as the DMS. The image sample at the beginning of this post is very obvious. In my testing, the quality difference was much more subtle, but still noticeable. I made the following assumptions, which I hope are correct. First, the original artwork is converted to different formats on initial import. It is stored in at least one database.
_LRG, _MED, _SM, _TN (large, medium, small, thumbnail)
When testing, such as clicking on the artwork to display full size, the MC log appears to show the URL of the image returned and it's size in KB. If BubbleUPnP is in fact using the first returned image at it's largest size, then the returned image, since it is lower in size in KB, explains why I see some level of decrease in quality. I also assume that since the flac file with the image embedded, or even as a separate file, like folder.jpg, is never reference again once it has been imported. In other words, the Library is returning the image from the underlying database. If I have made a mistake in any of these assumptions, please let me know. But I guess also let me know if I am on the right track. Thanks.