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 686638 - GetCurrentTransportActions is not supported
GetCurrentTransportActions is not supported
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: librygel-renderer
0.17.x
Other Linux
: Normal major
: ---
Assigned To: rygel-maint
rygel-maint
Depends on:
Blocks:
 
 
Reported: 2012-10-22 13:04 UTC by Mark Ryan
Modified: 2012-11-23 12:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to implement GetCurrentTransportActions (4.98 KB, patch)
2012-10-22 13:08 UTC, Mark Ryan
none Details | Review
Patch to implement GetCurrentTransportActions V2 (5.00 KB, patch)
2012-10-23 09:22 UTC, Mark Ryan
committed Details | Review

Description Mark Ryan 2012-10-22 13:04:18 UTC
As far as I can tell renderers that support Seek also need to support the GetCurrentTransportActions method and its related state variable CurrentTransportActions to be DLNA compliant.

I've attached a patch that adds these missing items to Rygel's AVTransportv2 interface.

Some comments on my own patch.

1. It assumes that seek is always possible.  However, this may not be the case, depending on the underlying MediaPlayer and perhaps the media currently being played.  To implement this properly the MediaPlayer class would need to have a new method to indicate whether seek is possible.

2. In general, will it always be possible for rygel-av-transport.vala to compute the current set of TransportActions from the playstate?  If not, perhaps the computation of the CurrentTransportActions variable could be delegated to the MediaPlayer class.

3. Is it okay to use the same set of CurrentTransportActions for the TRANSITIONING and the PLAYING states?
Comment 1 Mark Ryan 2012-10-22 13:08:54 UTC
Created attachment 226991 [details] [review]
Patch to implement GetCurrentTransportActions
Comment 2 Mark Ryan 2012-10-23 09:22:19 UTC
Created attachment 227044 [details] [review]
Patch to implement GetCurrentTransportActions V2

Here is a new patch that fixes two problems with the previous patch

1. The values specified for CurrentTransportActions in the previous patch were incorrect, e.g., "PLAY" was specified instead of "Play".
2. The action, X_DLNA_SeekTime, has been added.

Note that this patch is still not quite correct.  We should only be adding the Seek and the X_DLNA_SeekTime actions if the underlying media and renderer actually support seeking.  I think perhaps a new property or method is needed on the player interface to support this state variable correctly.

Also, it's important to note that if we ever support PlaySpeeds other than 1, we will need to specify a new action to the CurrentTransportActions, notably, X_DLNA_PS.
Comment 3 Jens Georg 2012-10-23 11:49:36 UTC
in wip/track-changes, Rygel.Plugin has a capabilities property (see http://git.gnome.org/browse/rygel/tree/src/librygel-core/rygel-plugin.vala?h=wip/track-changes#n32 ). That would be something we can add there or maybe to the Player as well.

And with PlaySpeed > 1 you mean the server-side playspeed, right?
Comment 4 Mark Ryan 2012-10-23 19:03:11 UTC
For Seek and X_DLNA_SeekTime, I thought it might be easiest to add a new method/property to the player, as the value of CurrentTransportActions depends not just on the state, but also on the type of the media currently being played, and I guess its the player that has this information.

With PlaySpeed > 1, I'm taloking about the parameter passed to the AvTransport:Play method.  Currently, Rygel returns an error if the Speed parameter is != 1.  If this restriction is removed, it's my understanding that Rygel would also be obliged to add X_DLNA_PS to its CurrentTransportActions variable.
Comment 5 Jens Georg 2012-10-23 19:53:56 UTC
Right, it's a bit more dynamic, so we need to add something.

I really like how DLNA is consistent in its terminology *rolleyes*
Comment 6 Jens Georg 2012-11-23 12:11:23 UTC
Commited but adapted to current code.