GNOME Bugzilla – Bug 674736
Some DLNA devices ignore DLNA.ORG_OP= parameters
Last modified: 2013-04-13 13:58:07 UTC
Created attachment 212720 [details] tcpdump when selecting "Sound on @HOSTNAME@" on the player I have enabled GstLaunch plugin in rygel.conf. Rygel gets recognized as an DLNA source on my Onkyo NR-TX616 receiver. When I select the sound source "Sound on @HOSTMNAME@" the player displays "Could not connect" The relevant lines in rygel.conf ################################## [GstLaunch] enabled=true launch-items=mypulseaudiosink mypulseaudiosink-title=Sound on @HOSTNAME@ mypulseaudiosink-mime=audio/mpeg mypulseaudiosink-launch=pulsesrc device=upnp.monitor ! lamemp3enc target=quality quality=6 ################################## When I dump the network traffic between the Onkyo (192.168.178.26) and the linux laptop(192.168.178.31), I can see, that rygel is rejecting the request: ################################## GET /GstLaunch/i/bXlwdWxzZWF1ZGlvc2luaw%3D%3D HTTP/1.1 Range: bytes=0- transferMode.dlna.org: Streaming Host: 192.168.178.31:40852 User-Agent: Mediabolic-IMHTTP/1.8.225 UPNP/1.0 DLNADOC/1.50 HTTP/1.1 406 Not Acceptable Date: Tue, 24 Apr 2012 16:51:12 GMT Content-Length: 0 ################################## Fetching the content with wget works: ################################## $ wget 192.168.178.31:40852/GstLaunch/i/bXlwdWxzZWF1ZGlvc2luaw%3D%3D --2012-04-24 19:14:16-- http://192.168.178.31:40852/GstLaunch/i/bXlwdWxzZWF1ZGlvc2luaw%3D%3D Connecting to 192.168.178.31:40852... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [audio/mpeg] Saving to: `bXlwdWxzZWF1ZGlvc2luaw==' [ <=> ] 38,701 13.6K/s ^C $ file bXlwdWxzZWF1ZGlvc2luaw\=\= bXlwdWxzZWF1ZGlvc2luaw==: MPEG ADTS, layer III, v1, 256 kbps, 44.1 kHz, JntStereo ################################## So it may be a bug in rygel?
I found out, when I comment the following lines in the sources, then rygel accepts the request from the player, and the stream gets delivered as expected ################################## # diff rygel-http-get.vala rygel-http-get.vala.DIST 130,133c130,133 < // if ((HTTPTimeSeek.requested (this) && !need_time_seek) || < // (HTTPByteSeek.requested (this) && !need_byte_seek)) { < // throw new HTTPRequestError.UNACCEPTABLE ("Invalid seek request"); < // } --- > if ((HTTPTimeSeek.requested (this) && !need_time_seek) || > (HTTPByteSeek.requested (this) && !need_byte_seek)) { > throw new HTTPRequestError.UNACCEPTABLE ("Invalid seek request"); > } ################################## So maybe a programmer could implement checking if a stream is requested and then disable this checking?
yeah, that's a similar issue to bug 659432
*** Bug 659432 has been marked as a duplicate of this bug. ***
Created attachment 238517 [details] [review] server: Ignore invalid seek requests for some devices
Created attachment 238518 [details] [review] server: Ignore invalid seek requests for some devices
Created attachment 238714 [details] [review] server: Ignore invalid seek requests for some devices Added Samsung to the lot
Review of attachment 238714 [details] [review]: Some more info in the docs would be useful, given how many times we already had to change/fix seeking related code. Also, AFAICT this patch 'entertains' rather than 'ignore' invalid seek request from some devices. ::: src/librygel-server/rygel-client-hacks.vala @@ +99,3 @@ public virtual void filter_sort_criteria (ref string sort_criteria) {} + public virtual bool accept_seek () { return false; } If i understood the code correclty, better name would be 'force_seek' for this one. ::: src/librygel-server/rygel-onkyo-hacks.vala @@ +22,3 @@ +using GUPnP; + +internal class Rygel.OnkyoHacks : ClientHacks { * Would be nice it have a short doc comment on top of every ClientHacks subclass saying which device/devices its for. * Since this and PlaystationHacks and SharpHacks are essentially the same, I don't see the need for separate classes. I made the agent a regex for this very reason.
Created attachment 239024 [details] [review] server: Accept invalid seek requests for some devices
It appears that this used to work fine in combination with XBMC 11 and before, with XBMC 12 however I see these Invalid seek requests popping up and XBMC telling me the stream can not be played. In the XBMC logfile I can see an error stating it can not get the file. Wget does work and streaming to a different client works fine. Any ideas what to do? Apart from contacting XBMC offcourse.
yeah, got that on the mailing list as well; we already have work-arounds for xbmc in place so we could add that until we can convince xbmc not to do seeking.
It seems they changed the way media is resumed in 12.1. Apparently 12.0 did not have this problem but in .1 they introduced a seek that breaks compatibility with a number of DLNA devices. If and when it gets fixed I can only hope and guess. Will there be a .deb version of Rygel available with this workaround?
Pushed with additional fix new XBMC Attachment 239024 [details] pushed as 639ac7c - server: Accept invalid seek requests for some devices
Is there an Ubuntu build available, can someone build it for 12.04 or should I try and build it myself? I would like to give the fix a try.