MinimServer Forum

Hi there,

could you possibly add - if present - the following tags to the DIDL-Lite element returned by call:

- Rating
- AcoustId Id
- AcoustId Fingerprint
- MusicBrainz Track Id

I'd suggest to add "desc" elements (see here) with type something like:

- 'rating'
- 'acoustId'
- 'acoustIdFingerprint'
- 'musicBrainzTrackId'

and encode values into "id" attribute, namespace as you like.

What is the use case for this? Are you using a UPnP control point that can accept these elements if present? If so, which control point? Also, is this a standard mapping that other servers support? If so, which servers?

It is not clear to me how the id and type attributes are intended to be used. I would not expect 'id' to contain a value. The comments describe a 'name' attribute but this isn't present in the schema. The coments also mention chlld elements and I would expect this to be the place to put metadata values.

Although the 'desc' element is defined in the DIDL-Lite XML schema in Appendix A of the ContentDirectory spec version 1.01, I can't find it in the list of properties shown in Appendix B of this document. This makes me unsure about whether it is a standard part of UPnP.

For the above reasons, I would be very hesitant to use this element unless there is evidence and precedent for its use by other UPnP products.

Use case: I am developing a control point with rating support. The rating information is stored back into the music file (as rating TAG). For this to work the music files must be clearly indentified. Most music administration applications (like SongKong, Piccard, etc.) clearly identify a song by acoustID or musicBrainzID, embedding those ID's (as TAGs) in the music file.

Since a control point has only access to the information the content directory server delivers, the missing link is how to acquire those ID's. The obviously rather slow way is to download the track from the supplied resource url and extract those information.

Therefore I've asked if you could possible embed them, while browsing the content directory.

I see your point in staying as compatible as possible. But I still ask you to think about it.

I've read Section 2.8.11 of ContentDirectory:1 Service Template

Quote:2.8.11.Vendor Metadata Extensions

Vendors may extend DIDL-Lite metadata by placing blocks of vendor-specific metadata into <desc> blocks. In DIDL-Lite, a <desc> element identifies a descriptor. The required nameSpace attribute identifies the namespace of the contained metadata. <desc> elements may appear as child elements of <DIDL-Lite> root elements, <container>, and <item> elements. The contents of each <desc> must be associated with only one namespace.
A descriptor is employed to associate blocks of other XML-based metadata with a given CDS object. Examples of other XML-based metadata include DIG35, MPEG7, RDF, XrML, and etc. descriptor blocks could also be employed to contain vendor-specific content ratings information, digitally signed rights descriptions, and etc.
Allowing the <desc> to contain only elements from the namespace defined by the nameSpace attribute allows control points vendors to selectively deploy support for a given namespace using parser 'plug-in' techniques. <desc> blocks designating unfamiliar namespaces are ignored by the control point.

Reading that I'd say the desc element might look like this:

Thanks for this explanation and the additional pointer. It is possible that a future version of MinimServer might add support for vendor-specific metadata. If this happens, I will consider adding these elements.

Is your control point available to download and try?

ok, thanks. The CP is not yet downloadable, probably this year. I'll post the URL here, if available.

<desc> tags are a good idea for any metadata that you want to expose to Control Points and that does not fit the regular DIDL-Lite fields.
Of course, it is up to the CP to eventually make use of that metadata.