INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: csimon on October 29, 2010, 03:22:44 pm
-
DLNA Server: JRiver MC (latest build) - DLNA Extra is turned ON.
DLNA Renderer: WD TV Live
DLNA Controller: PlugPlayer on iPad
I've having mixed results on being able to display cover art in Now Playing on the Renderer and am trying to work out where the problem is. I've tried an experiment with one album to try and eliminate variables. I have deleted all cover art JPGs from the folder and I just have the cover art embedded in the MP3 files. I've deleted that album from the library and reimported it so there should be no further references to physical files. JRiver correctly displays the embedded cover art in its own client library views.
When I use the WD TV Live as a client and browse the JRiver DLNA server and select a track, the cover art is correctly shown in Now Playing. This shows that WD TV Live is correctly reading the MP3 tag when it's used as a client.
When I use PlugPlayer as the Controller and browse the JRiver DLNA server and select a track and send it to the WD TV Live box, the cover art is correctly shown in Now Playing in PlugPlayer but the WD TV Live box doesn't display the cover art. This seems to imply that PlugPlayer is correctly reading the embedded MP3 tag but WD TV Live doesn't when it's used as a Renderer only, but I can't work out which of the situations below is true to explain why it's failing.
1. JRiver is correctly sending a URL but PlugPlayer is not passing it on to WD TV Live.
2. JRiver is correctly sending a URL and PlugPlayer is passing it on (if it needs to - or is it obtained directly from the Server once the Renderer has been told to play the file?) but WD TV Live is unable to find it.
3. JRiver is not sending a URL to the cover art.
4. JRiver is unable to send a URL as there is no physical file to link to, only an embedded tag. (The cover art didn't display as described even when I had physical files, so I deleted the physical files in order to make sure only the MP3 tag could be used and the other devices weren't defaulting to the physical files. So I guess this option is not the correct answer.).
-
Some devices read the song tag, usually only when there is no cover art provided in the content directory (some like the WD don't use the cover art in the file). Cover art can be provided in several different ways. We provide it as a specific album art entry and a resource. PP as a renderer is simple, it just sees the content directory that the server gives to it and uses it. When it's sending to a different renderer, it has to parse the content directory and pass it along to the renderer. It appears that it's not doing this with the cover art presented by the MC server. I tried it with other servers in the same configuration and it doesn't display cover art for them either.
-
Could you explain the form that the URL to cover art takes, if the cover art is actually an embedded tag and doesn't exist in file form? Does the URL point to a script in MC that generates and returns an image file?
-
Could you explain the form that the URL to cover art takes, if the cover art is actually an embedded tag and doesn't exist in file form? Does the URL point to a script in MC that generates and returns an image file?
MC produces a thumbnail for an item. A reference to that item in the database asking for cover art provides a http url that looks like a file reference. You can actually try this in a browser using a url that looks like the logged url for the item itself. For example, if you look in the Media Network Activity log you'll see something like (for a music file):
http://199.242.131.131:52100/Music/F12931.1121.mp3
then the cover art url will look like:
http://199.242.131.131:52100/AArt/12931.jpg
The artwork is either as a http reference directly to the thumbnail or to a converted 120x120 image if the "present small artwork" option in advanced options is turned on.
-
Ah, that's very interesting, thank you!
Sorry, but I'm probably a bit of a geek being a programmer myself and like to know these things!
-
Ah, that's very interesting, thank you!
Sorry, but I'm probably a bit of a geek being a programmer myself and like to know these things!
I think PP could implement this if it grabbed the cover art URL when it gets the file url from the servers content directlry, then when it repackages the data for the renderer, include that cover art url. It sounds easy but it's really complicated since there's more than one method the server can use to present the cover art and to be fairly foolproof, you'd have to cover multiple methods. It's probably work most of the time though if it just grabbed the albumartURL and just resent that.