After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709723 - It is not possible to customize the properties MediaObjects
It is not possible to customize the properties MediaObjects
Product: rygel
Classification: Applications
Component: librygel-server
git master
Other Linux
: Normal enhancement
: ---
Assigned To: rygel-maint
Depends on:
Reported: 2013-10-09 11:47 UTC by Mark Ryan
Modified: 2018-05-22 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

server: Move properties up the hierarchy (8.75 KB, patch)
2013-10-11 11:15 UTC, Jens Georg
none Details | Review
server: Make MediaObject.serialize public (3.41 KB, patch)
2013-10-29 13:23 UTC, Jens Georg
committed Details | Review
Prototype of an approach that might scale (13.09 KB, patch)
2014-09-09 06:14 UTC, Craig Pratt
none Details | Review
Prototype of an approach that might scale (updated) (13.08 KB, patch)
2014-10-03 19:45 UTC, Craig Pratt
none Details | Review

Description Mark Ryan 2013-10-09 11:47:58 UTC
DMS plugins that derive from the MediaObject classes in librygel-server, such as VideoItem, may want to add additional properties.  For example, a plugin may wish to specify the artist property in the VideoItem.  Unfortunately, this is not possible for vala based plugins as to add a new property they need to override serializable and unforunately, serializable is internal.  The easiest fix would be to make serializable public but I realise that this would be modifying the API.

There are two short term workarounds.

1. Write your plugin in C.
2. Modify the librygel-server make file and the makefile of your plugin

Add  --internal-vapi and --internal-header to  librygel_server_2_0_la_VALAFLAGS in the librygel-server

Add --pkg rygel-server-internal-2.0 to the VALAFLAGS in your plugin's Makefile.
Comment 1 Jens Georg 2013-10-09 12:10:08 UTC
As discussed on IRC: We probably need to rethink the meta-data a bit, some of the properties (such as artist) on MusicItem also make sense on VideoItem
Comment 2 Jens Georg 2013-10-10 07:30:30 UTC
The properties in question are artist, genre, album and albumartURI. I would even propose to move them (except album) to MediaObject so we can use them in album.MusicAlbum containers (which is recommended by UPnP, Table C-25 CDv3)
Comment 3 Jens Georg 2013-10-11 11:15:19 UTC
Created attachment 256990 [details] [review]
server: Move properties up the hierarchy

Move artist, genre and album to MediaObject/AudioItem to make them available in
containers and videos as well
Comment 4 Jens Georg 2013-10-29 13:23:52 UTC
Created attachment 258442 [details] [review]
server: Make MediaObject.serialize public
Comment 5 Jens Georg 2013-10-29 15:01:06 UTC
Comment on attachment 258442 [details] [review]
server: Make MediaObject.serialize public

Attachment 258442 [details] pushed as 6cccd5a - server: Make MediaObject.serialize public
Comment 6 Jens Georg 2014-06-22 09:55:20 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 7 Craig Pratt 2014-09-03 11:07:49 UTC
I'm not sure these should be moved up the hierarchy.

If the intent is to follow the UPnP hierarchy, artist, for example, is on playlistContainer but not container, playlistItem but not Item, musicAlbum but not Album, and musicTrack but not audioItem. Additionally, artist needs to be multi-value for playlistItem. (guess that's why DIDLLiteItem has get_artists())

I think the issue is that (a) the MediaItem hierarchy doesn't equivalent granularity to the UPnP hierarchy (e.g. there's an AudioItem class but not a MusicTrack class), (b) there's not a simple class-type test that a MediaServer can use to determine if author is searchable on the object (the AudioItem class test used in RelationalExpression isn't correct or sufficient).

Not sure I want to elaborate too much on a solution. But (a) could probably be solved by adding the missing classes (just a few?). For (b) maybe search comparisons should always be delegated to the object (e.g. compare_by_property() taking an optional SearchCriteriaOp). That should eliminate the need for subclass knowledge when doing searches (only the particular MediaObject subclass should need to know what UPnP properties it contains/supports).
Comment 8 Craig Pratt 2014-09-09 06:14:01 UTC
Created attachment 285712 [details] [review]
Prototype of an approach that might scale

This patch defines a MediaObject.satisfies() method to allow UPnP property checks to be delegated to MediaObject subclasses/subinterfaces with RelationalExpression.satisfied_by() delegating to MediaObject.

I think there's still some need to sort out properties among the subclasses. And I haven't done much testing with this. But I think this approach should allow for properties to be placed arbitrarily without changes to the object hierarchy. 

e.g. the patch adds "upnp:genre" to VideoItem as an example.
Comment 9 Jens Georg 2014-09-11 07:19:01 UTC
How did that get "resolved fixed"? Weird.
Comment 10 Craig Pratt 2014-10-03 19:45:06 UTC
Created attachment 287693 [details] [review]
Prototype of an approach that might scale (updated)

Just added short-circuit comparisons for some of the satisfies(RelationalExpression) implementations.
Comment 11 GNOME Infrastructure Team 2018-05-22 12:42:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: