GNOME Bugzilla – Bug 709723
It is not possible to customize the properties MediaObjects
Last modified: 2018-05-22 12:42:37 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 Makefile.am Add --pkg rygel-server-internal-2.0 to the VALAFLAGS in your plugin's Makefile.
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
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)
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
Created attachment 258442 [details] [review] server: Make MediaObject.serialize public
Comment on attachment 258442 [details] [review] server: Make MediaObject.serialize public Attachment 258442 [details] pushed as 6cccd5a - server: Make MediaObject.serialize public
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.
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).
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.
How did that get "resolved fixed"? Weird.
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.
-- 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: https://gitlab.gnome.org/GNOME/rygel/issues/55.