Same failure was seen with DLNA 7.3.122.8. I have attached the patch to fix the destroy container action.

Created attachment 250145 [details] [review]
Delete container action

Review of attachment 250145 [details] [review]:

On top of that, I'm wondering whether we really should allow to do this.

::: src/plugins/media-export/rygel-media-export-writable-db-container.vala
@@ +113,3 @@
+        var container = this.media_db.get_object (id);
+
+        yield this.remove_child_tracked (container);

This only removes the container from the database. On the next start-up, it will be re-added.

Created attachment 250846 [details] [review]
server: Fix recursive removal of items

Created attachment 250847 [details] [review]
media-export: Implement recursive container removal

With this, the test still fails if it happens to pick the Playlist folder.

Created attachment 250850 [details] [review]
media-export: Emit containerUpdateID on playlist

Patch looks good.

I'm thinking of limiting the actual removal to "guarded" objects, though; these are created remotely so only objects that were created remotely are allowed to be removed remotely (that's what we do in the tracker plug-in as well) with maybe an override switch.

I was considering that. But then I thought any unrestricted object(restricted flag not set) can be destroyed by destroyobject action. So do we really need to make it a guarded.?
Did I read the meaning of guarded correct.

Attachment 250846 [details] pushed as 331626c - server: Fix recursive removal of items
Attachment 250847 [details] pushed as 9398caa - media-export: Implement recursive container removal
Attachment 250850 [details] pushed as 43aea6c - media-export: Emit containerUpdateID on playlist