Note the problem may actually be in gupnp-av ( gupnp_didl_lite_object_apply_fragments).

We may also be able to provide a patch shortly.

Created attachment 246078 [details]
Modified didl-lite xsd for fixing dlna namespace validation error for UpdateObject

Modified snippet to fix xsd validation:
<xsd:attributeGroup name="commonAttrs-item-container.group">
.....
<xsd:anyAttribute namespace="##any" processContents="lax"/>
</xsd:attributeGroup>

This fixes the problem for me, although I have to admit I don't understand the XSD stuff.

BTW., there is an extra space introduced in line 2, the line starting with <xsd:schema, which doesn't seem to be needed.

You might want to attach a patch file created with git-format-patch to allow your fix to be easily integrated and of course to get credit for your work.

(In reply to comment #2)
+               <xsd:anyAttribute namespace="##any" processContents="lax"/>

I'm not an expert on didl-lite either but I think this does require some more explanation: the xsd file comes from upnp.org and is referenced from the UPnP AV spec (we are not using the newest xsd file but as far as I can tell the only changes are moving documentation indentation back and forth).

IIRC We're using the XSD that was mentioned in the ContentDirectory:3 spec.

I think the issue here is rather why does gupnp-av thing the "dlnaManaged" attribute was changed. I can't see it in the wireshark log.

hrm. This is a side-effect of DLNA not providing xsd's for their namespace (and UPnP now knowing about DLNA here).

I wouldn't really want to lower that to "lax" for all attributes, that seems to wide. Either drop the dlna:managed before validating or add that explicitly to the XSD.

>I think the issue here is rather why does gupnp-av thing the "dlnaManaged"
>attribute was changed. I can't see it in the wireshark log.

So the problem seems to be in MediaObject.apply_fragments.

This function first creates a GUPnPDIDLObject from the object that is being updated.  This object includes all the current properties of the object including the dlnaManaged attribute.  It then calls gupnp_didl_lite_object_apply_fragments on that object.

It's not entirely clear to me how this works, but I think the code updates a copy of the GUPnPDIDLObject with the new values and then checks that the new object is valid by checking against the XSD.  However, the GUPnPDIDLObject contains the dlnaManaged attribute and so the check fails.

Created attachment 246136 [details] [review]
server: Drop dlnaManaged attribute on UpdateItem

That works for me, but not sure what the side-effects are, for example some client trying to modify dlnaManaged.

Works for me too.  Client's are not allowed to modify dlnaManaged and I think the code would still return an error if they tried to do so, right?  If so, we should be okay.

@Jens : Shouldn't the dlnaManaged attribute added back after validation is complete, Since dlnaManaged attribute is needed in the original document?

If I read the code correctly the original object is not replaced.  Certain properties are copied from the modified object to the original object and so dlnaManaged is preserved.

I tested this with dLeyna and this seems to be the case.

Makes sense. I missed that part. Then patch Jens has provided would solve it perfect.

Yes, that DIDL object is just used the way Mark said.

So if we apply that, the test runs into

Schemas validity error : Element '{urn:schemas-upnp-org:metadata-1-0/upnp/}albumArtURI', attribute '{urn:schemas-dlna-org:metadata-1-0/}profileID': The attribute '{urn:schemas-dlna-org:metadata-1-0/}profileID' is not allowed.

Which starts to get slightly annoying.

The only way to avoid this would be either to remove all dlna namespaces attributes before validation for all elements or define a xsd for knowm dlna attibutes within gupnp.

@Jens : Are you running into this for DMR or DMS tests?

DMS

Schemas validity error : Element '{urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/}item': Character content other than whitespace is not allowed because the content type is 'element-only'. also sounds weird.

(In reply to comment #19)
> Schemas validity error : Element
> '{urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/}item': Character content other
> than whitespace is not allowed because the content type is 'element-only'. also
> sounds weird.

I think I have seen this error when the test tool is executing negative test scenarios. And the error is valid since item element must not have content other than elements under it.

But are you seeing the test failing because of this reason?

yes, you're right, this is "correct", I misinterpreted the output.

Created attachment 247042 [details] [review]
server: Drop dlna: ns attributes on UpdateObject

We cannot validate them and the UpdateObject action fails because of
that, so we walk the node and remove all those attributes.

Still, after fixing this, the UPnP CTT tries to add a dc:creator which fails since we don't explicitly support that ...

For some weird reason we only support dc:creator on photoItem

@Jens : I encountered cd:creator issue. I added this support in our local branch. I will update the patch soon.

Created attachment 247161 [details] [review]
Patch to add dc:creator support for video items.

This adds a new column for creator in addition to author element

Review of attachment 247161 [details] [review]:

The commit message should be "server,media-export: Support dc:creator"  or something like that.

::: src/librygel-server/rygel-video-item.vala
@@ +142,3 @@
+        case "dc:creator":
+            return this.compare_string_props (this.creator, item.creator);
+        // Replaced dc:author with upnp:author

No need to comment that, better put into commit message

::: src/plugins/media-export/rygel-media-export-sql-factory.vala
@@ +86,3 @@
     private const string SAVE_META_DATA_STRING =
     "INSERT OR REPLACE INTO meta_data " +
+        "(size, mime_type, width, height, class, creator, " +

Always add new columns at the end in this list, it avoids the error-prone column renumbering you have to do otherwise

@@ +117,3 @@
     private const string ALL_DETAILS_STRING =
     "o.type_fk, o.title, m.size, m.mime_type, m.width, " +
+    "m.height, m.class, m.creator, m.author, m.album, m.date, m.bitrate, " +

Same as above

Created attachment 247227 [details] [review]
Follow up patch for "247161: Patch to add dc:creator support for video items."

This is in response to "247161: Patch to add dc:creator support for video items."

the current dc:creator support (without the patch) is also the reason for 7.3.66.2 failing if you happen to have a full tags MP3 in your media content

parthiban: Did you mean to obsolete the second patch in comment 28?

also, fixing it just for VideoItem isn't enough...

(In reply to comment #30)
> parthiban: Did you mean to obsolete the second patch in comment 28?
Yes I made it obsolete. I wanted to do some more testing on the updated patch, since I was seeing some failures in DLNA CTT after this change. Will soon update another patch after more testing.

(In reply to comment #31)
> also, fixing it just for VideoItem isn't enough...
by this you mean, we have to fix this for audio items?

(In reply to comment #33)
> (In reply to comment #31)
> > also, fixing it just for VideoItem isn't enough...
> by this you mean, we have to fix this for audio items?

Yes, UPnP CTT does this test with an audio item here. So moving it up to MediaItem should be "the right thing"

Got it. I am testing only with Videos items so I did not see this coming.
I will make the changes to move it to MediaItem and upload a new patch.

Comment on attachment 247042 [details] [review]
server: Drop dlna: ns attributes on UpdateObject

Attachment 247042 [details] pushed as 549ddb8 - server: Drop dlna: ns attributes on UpdateObject

Created attachment 247933 [details] [review]
Latest patch for including dc:creator in MediaItem

Moved the logic from Individual sub classes and moved it into MediaItem. Also incorporated review comments from Jens

Comment on attachment 247161 [details] [review]
Patch to add dc:creator support for video items.

Updated a latest patch. So this is obsolete.

Nice. Two fails down.