MC builds thumbnails of Artwork for music from either the Cover Art tag embedded in the file or an image file such as Folder.jpg. either on the fly, during import or a manual scan. It appears 3 versions are created in a database. Small, Medium and Large. In all 3 sizes, the quality and color of the original Artwork is reduced. It appears the concept for doing this is to reduce the chance that the Client will not be able to display the Artwork. In other words, some clients might not be able to handle the full, original Artwork. However, because a user can setup different DLNA “profiles”, an alternative would be to allow the user to set 2 new options under Advanced for the specific DLNA server profile: “Present Original Artwork” and “Do not generate Thumbnails”. A more elaborate solution would be to sniff the client and in the case of BubbleUPnP, automatically present the original Artwork.
To reproduce this issue, view the output in “Services…>Media Network”, filtered under the DLNA server created in MC. Note: this will not be visible if you try to generate a log from the help menu. Using a BubbleUPnP client, browse to the specific album. The original Artwork is 250kb, embedded in the flac file. In the log, you will see the GET requests with <ip><port>/Cart/####.jpg. Eventually you realize that ####.jpg, such as 1059.jpg corresponds to a particular album. To the right of the request is the image size and again, depending on the view on the client, this number will change. In the case of a view where the Artwork is very small on the client, the image size drops to only 5kb. However, BubbleUPnP has a feature where if you tap on the Artwork, it will expand to the full size of the screen of the tablet. On a large tablet, one would expect the full-size image to be presented. But it does not. You only get a 100kb file from the GET request. Less than half the size of the original image. And it does not end there. In the playlist view, where the Artwork is designed to be small, the quality is noticeably degraded in terms of sharpness, color shift, etc. (see screenshots). This appears to be because a version of the Artwork from the MC thumbnail cache for the Small, Medium or Large database is sent as opposed to the original, full-size image. All of this can be confirmed by watching the GET request.
In terms of testing, it appears the only settings to control this are under “Advanced” for the specific DLNA server. These settings do not seem to be fully documented. Via trial and error, numerous combinations were tried. For example, all combinations of turning off/on DLNA, DLNAExtra, Present Small Artwork (which did indeed yield very tiny Artwork), PlayStation 3 compatible and finally WMC compatible. Before changing the setting, quit MC, remove thumbnail database and delete thumbnail cache in BubbleUPnP client. No combination of settings could retrieve the full-size image at any point and viewing the GET request confirmed this. It appears this issue has affected every version of MC since at least 2016, if not longer. Until now, it was apparent the image quality was being reduced, and now this shows why from viewing the actual logs.
Note: path to thumbnail database on Linux is ‘~/.jriver/Media Center <version>/Thumbnails/<GUID>/Normal (v3)/*.jmd’
One could argue sending a 5kb image will increase performance on slow networks, with possible other advantages, however certain clients do their own caching of Artwork, which therefore makes caching on MC redundant. First, allow the original image to be sent to the client if the user determines the client can handle it. Again, allow this under Advanced or sniff the client to perform automatically. Next, reducing image size and maintaining sharpness, color, etc. requires a relatively sophisticated algorithm. It appears that the code in MC that handles this is not performing this correctly. This should be adjusted for clients that cannot handle the original image size, such as, for example, receivers that may be limited to 160x160 resolution. There is a large amount of information on how to reduce image size without sacrificing quality from sources like ImageMagick, Photoshop, etc. But again, in this case, sending the original Artwork should resolve the entire issue.
There was a post that stated the client makes the request for the size of the image to be returned. It does not seem to be in the logs, or could not make sense of it if it was there. Whether it is in the logs or not, the information proved here should be more than enough to duplicate the issue on your side. There was another post that stated max image resolution per the DLNA spec was something like 200x200. However, different systems can, and do make their own rules. For example, Apple seems to have landed on 3000x3000 as their standard. Whether that resolution is excessive or not, it should not be limited to one resolution.
Using a different system:
‘ss-1-foobar_BubbleUPnP.png’ was a screenshot from the client using foobar2000 as the DMS, via the plugin “foo_upnp” (which also has the concept of “profiles”) and BubbleUPnP on the android client. Obviously, ‘ss-2-jriver_BubbleUPnP.png’ is using MC as the DMS. This is only one, hopefully clear example, of the image quality degradation. The experience of Artwork presented from viewing many albums demonstrates the problem consistently.
Note:
There is a post “Low quality image cover when playing to DLNA player” that is similar, but not exactly the same. But a resolution here should cover that post as well.
The goal of MC has always seemed to provide the highest quality in all aspects of media presentation. Hopefully this will be addressed.
Author
Topic: Present Original Artwork (CArt) (Read 1261 times)