#14204 closed Bugs (fixed)

breaks compatibility with DLNA DMS tuners such as HDHomeRun

Reported by: sd-jafa Owned by: alcoheca
Priority: 4 - Normal
Component: Streaming (Local) Version: 15.1 "Isengard" RC1
Severity: Normal Keywords: dlna tuner range hdhomerun
Cc: alcoheca, ulion, arnova, wsnipex Blocked By:
Blocking: Platform: All

Description

The HDHomeRun is a DLNA certified network attached CableCARD TV tuner / video gateway that streams live cable TV to DLNA players.

Works well with XBMC 12.0.

A change in 12.1 systematically adds a RANGE tag to the video HTTP-GET request which breaks operation with non-seekable (live TV) DLNA DMS devices.

DLNA requires that a DMP (XMBC) *not* send a RANGE request to the DMS if the protocol info does not indicate the stream is seekable. The seekable-ness of the stream is detected by the presence or absence of DLNA.ORG_OP=xx. (If the stream is seekable the OP value will be non-zero. If not seekable the OP tag is absent).

Admittedly this is a brain-dead requirement because HTTP RFCs allow a server that does not support RANGE to ignore it... the problem is that DLNA certification process requires that a DLNA DMS reject any HTTP-GET request containing a RANGE tag when non-seekable content is selected (ie live TV).

So net result - 12.0 works well with the HDHomeRun, 12.1 does not play video, and the HDHomeRun must reject the 12.1 HTTP-GET request in order to maintain DLNA certification.

The fix needed is to detect the DLNA.ORG_OP=xx tag in the CDS protocol info... if OP value is present and non-zero then send a RANGE tag in the HTTP-GET. If the OP value is not present or 00 then do not send RANGE tag in the HTTP-GET and don't allow seeking.

Nick - Silicondust (makers of the HDHomeRun and DLNA member)

Change History (37)

comment:1 Changed at 2013-03-22T05:13:34Z by sd-jafa

I believe it was the following patch that broke things: https://github.com/xbmc/xbmc/commit/169d21d99a3be2091625b874792cb93734a763f0

Nick

comment:2 Changed at 2013-03-22T05:25:55Z by sd-jafa

To clarify... the patch is good for content where the protocol info field from CDS indicates DLNA.ORG_OP=<non-zero>... ie the RANGE tag should be sent as per the patch.

The problem is that the sending of the RANGE tag needs to be conditional on the DLNA.ORG_OP tag - if the DLNA.ORG_OP tag is not present in the CDS protocol info then the RANGE tag must not be sent in the HTTP-GET request.

Nick

comment:3 follow-up: Changed at 2013-03-23T04:12:00Z by Ned Scott

I can confirm this on 12.1. An interesting note, Gotham nightly builds do not have this issue. Gotham nightlies are able to use the UPnP/DLNA connection to the HDHomeRun just fine.

comment:4 Changed at 2013-03-23T04:12:49Z by Ned Scott

  • Cc alcoheca added

comment:5 Changed at 2013-03-23T12:11:08Z by alcoheca

  • Owner set to alcoheca
  • Status changed from new to assigned

Thanks for the head's up

I can presumably fix this by not allowing seeking at all on these ORG_OP=00 files. I'll have a look at it this afternoon

comment:6 Changed at 2013-03-23T12:11:32Z by alcoheca

  • Status changed from assigned to accepted

comment:7 in reply to: ↑ 3 Changed at 2013-03-23T16:04:58Z by alcoheca

Replying to Ned Scott:

I can confirm this on 12.1. An interesting note, Gotham nightly builds do not have this issue. Gotham nightlies are able to use the UPnP/DLNA connection to the HDHomeRun just fine.

That throws me a little bit.

Also the problem is the RANGE header is being set even when not seeking AFAICT. Grabbing the DLNA_ORG.OP tag is no bother, but CurlFile will need to be a little bit cleverer.

comment:8 Changed at 2013-04-06T21:43:53+01:00 by alexvanniel

Interesting (for me anyway) to know is that this does not only cause problems for the HDHomeRun but also for a lot of other DLNA certified hardware and software. One of them being Rygel, the DLNA Server software. It seems that providing this range while starting to play a stream that can not be seeked, Rygel rejects the request and XBMC never get's the file and is unable to play the stream. So essentially this seems to break compatibility with any software or device that provides non-seekable content.

comment:9 Changed at 2013-04-08T18:08:17+01:00 by alcoheca

In order to get this fixed for a 12.2 release can I ask for some help? Can Nick and Alex try with a nightly build / compile master from source. That way we can confirm that the problem only exists in 12.1 - there was a commit 0bfc272b91137d7690bc5f20f94daa37b05a6905 which modified the behaviour. Can you check whether HDhomrun & Rygel streaming works after (and if not, check before) this commit.

Thanks.

If you're feeling particularly helpful then build xbmc/Frodo if streaming works fine with that branch then we don't have to do anything, the fix is going in.

comment:10 Changed at 2013-04-08T18:52:50+01:00 by alexvanniel

I just installed the latest nightly from the PPA/nightly sources for Ubuntu 12.04, fired up Rygel added the UPNP source in XBMC and opened up one of the streams in XBMC and it still gives me an "Invalid seek request" unfortunately.

To try and be more helpful, this is the nightly I installed: 13.0~git20130408.0201-e56dd63-0precise

I am trying this out on a secondary PC so I could compile from source but don't have the time right now so that will have to wait for later. What branch would you like me to download and try and compile? Not sure if I will be succesful in compiling since I hardly ever compile anything, but it is worth a try to help you fix this problem.

comment:11 follow-up: Changed at 2013-04-08T19:32:38+01:00 by alcoheca

I see this behaviour with Rygel and master branch too. Thanks for trying the nightly out Alex. Hopefully we can figure out a fix for this.

comment:12 in reply to: ↑ 11 Changed at 2013-04-08T21:26:37+01:00 by alexvanniel

Replying to alcoheca:

I see this behaviour with Rygel and master branch too. Thanks for trying the nightly out Alex. Hopefully we can figure out a fix for this.

If you háve a fix and want me to try it out, please let me know. I am more than willing to help you figure this thing out.

It would mean I can play Spotify or any other audio/video related stream on the one PC and have it's output run through the other PC with XBMC that is connected to my TV and stereo system. Even though there is a project going on to bring Spotify to XBMC, it is not really usable for me since it on a regular basis corrupts my skin and all the settings with it. Not really something I enjoy.

comment:13 Changed at 2013-04-09T12:11:30+01:00 by ulion

this currently can be workaround in the add-on source, add a protocol option 'Range=' to the final url, e.g. 'http://xxx.xx/xxxxx?xxxx&xxxx=xxx|Range=&User-Agent=xxxxxx', the key is the 'Range=' part, which will erase any Range request in the http request, but this workaround maybe not clean, because xbmc still does not known the url does not support seek, it will still try to seek but indeed it won't send out Range request for the seek, so if it does not report error by lib curl, then xbmc will got wrong data. but maybe not, so worth a try.

if above workaround not work, then we had to wait 12.2 to fix this. in 12.2 we has 'seekable=0' protocol option, which will tell xbmc won't seek on the stream. and we still need some work to stop send Range when seekable=0 set for the initial request, will soon in frodo.

comment:14 Changed at 2013-04-09T20:15:27+01:00 by ulion

oh, seekable=0 as a feature maybe not in 12.2, but we will try to fix this in 12.2.

comment:15 Changed at 2013-04-29T13:43:19+01:00 by Mike Pisano

Also effected by this one, Just upgraded my ATV's and Windows machines to nightly XBMCSetup-20130427-041c822-master.exe as part of 12.2 pre testing and confirm the Silicone Dust prime will no longer play after added as UPNP source.

Hope your able to fix this soon - Let me know if I can help.

Kind Regards, Mike

comment:16 Changed at 2013-05-01T09:47:56+01:00 by alcoheca

@alex & mike can you try this patch https://github.com/xbmc/xbmc/pull/2675.patch and report back if it fixes the problem. There is a very short deadline to getting this into 12.2 so if you can do it quickly, all the better.

comment:17 Changed at 2013-05-01T10:14:18+01:00 by alcoheca

I've triggered a win32 test build which will complete in about 3 hours if that helps

comment:18 follow-up: Changed at 2013-05-01T13:36:40+01:00 by alcoheca

http://mirrors.xbmc.org/test-builds/win32/XBMCSetup-20130430-61dbc14-curl_range_rework.exe

there's a test build based on master branch & the patch, but should still allow to confirm the bug fix for Frodo

comment:19 Changed at 2013-05-01T13:46:18+01:00 by Ned Scott

Test build upload seems to be stalled. Shows as 0k.

comment:20 in reply to: ↑ 18 Changed at 2013-05-02T13:25:56+01:00 by alexvanniel

Replying to alcoheca:

http://mirrors.xbmc.org/test-builds/win32/XBMCSetup-20130430-61dbc14-curl_range_rework.exe

there's a test build based on master branch & the patch, but should still allow to confirm the bug fix for Frodo

Unfortunately the build is 0k and can thus not be tested. I have not been able to get a compiled version running, not something I do regularly so it is finding what I need and where to get it and THEN how to compile it properly... So if someone either can compile one for Ubuntu 12.04 64bit or for a Windows installation that would great. In the mean time I will try and get it compiled to test it.

comment:21 Changed at 2013-05-02T13:30:34+01:00 by alexvanniel

Noticed the backport window has closed. Wish there was a bit more time for things like this but then again, there needs to be a deadline at some point. I am still willing to test and see if the proposed fix actually works. Rygel 0.18 has a fix but does not really play well with XBMC afterwards it appears.

comment:22 follow-ups: Changed at 2013-05-08T10:27:26+01:00 by alcoheca

I managed to get a win32 build of the proposed fix working this time -

http://mirrors.xbmc.org/test-builds/win32/XBMCSetup-20130430-61dbc14-HEAD.exe

please test and report back if it fixes the problems

comment:23 Changed at 2013-05-11T01:44:46+01:00 by Ned Scott

I can't get my Windows install working. Any chance we can get Billy to make a Mac OS X test build?

comment:24 Changed at 2013-05-11T08:30:23+01:00 by alcoheca

I just triggered a osx build

comment:25 Changed at 2013-05-11T16:14:16+01:00 by Ned Scott

The test build works great for me. XBMC is now able to playback over UPnP/DLNA from the HDHomeRun Prime.

comment:26 Changed at 2013-05-11T18:35:02+01:00 by alcoheca

Great - hopefully we'll get one more confirmation before finally waving this bug good bye.

comment:28 in reply to: ↑ 22 Changed at 2013-05-18T16:48:24+01:00 by Weatherman

Replying to alcoheca:

I managed to get a win32 build of the proposed fix working this time -

http://mirrors.xbmc.org/test-builds/win32/XBMCSetup-20130430-61dbc14-HEAD.exe

please test and report back if it fixes the problems

I also tested this Windows build, and the HDHomerun Prime works perfectly again with DLNA!! Great job!!!

Any plans for a plug-in for a Guide using MC2XML data or something like that?

Thanks!

comment:29 in reply to: ↑ 22 Changed at 2013-05-18T17:21:48+01:00 by Weatherman

Is it possible to be able to use the HDHomerun Prime DLNA XBMC integration to go up/down channels and go directly to channels by number vs. scrolling?

If that functionality was possible + TV Guide from an XMLTV.XML source, this would be a great replacement for WMC (minus any PlayReady/encrypted channels).

comment:30 Changed at 2013-05-18T17:46:49+01:00 by alcoheca

  • Resolution set to Fixed
  • Status changed from accepted to closed

hi glad it's working for you, can you ask these in the forums, I have no idea about this

comment:31 Changed at 2013-05-23T17:46:12+01:00 by sho

  • Milestone changed from Future / Pending to 13.0

comment:32 Changed at 2015-08-04T16:05:38+01:00 by Ned Scott

  • Milestone changed from 13.0 "Gotham" to Future / Pending
  • Summary changed from 12.1 breaks compatibility with DLNA DMS tuners such as HDHomeRun to breaks compatibility with DLNA DMS tuners such as HDHomeRun
  • Version changed from 12.1 "Frodo" Bugfix release to 15.1 "Isengard" RC1

Looks like this same issue is back for v15. SiliconDust has confirmed that the HDHomeRun is required (for DLNA compliance) to reject these range requests: http://forum.kodi.tv/showthread.php?tid=232942

comment:33 Changed at 2015-08-04T16:06:07+01:00 by Ned Scott

  • Resolution Fixed deleted
  • Status changed from closed to reopened

comment:34 Changed at 2015-08-04T16:10:55+01:00 by Ned Scott

  • Cc ulion arnova added

comment:35 Changed at 2015-08-04T16:29:35+01:00 by Ned Scott

  • Cc wsnipex added

comment:36 Changed at 2015-08-04T21:51:49+01:00 by arnova

Don't know much about DLNA and the "DLNA.ORG_OP=xx tag" you mention. Is there simply some http header we could look for? If so, the fix is trivial.

comment:37 Changed at 2015-08-31T08:33:28+01:00 by arnova <[email protected]…>

  • Resolution set to fixed
  • Status changed from reopened to closed

In 669b80f0:

fixed: Enable retry without range set for e.g. broken HDHomerun servers (fixes #14204)

Note: See TracTickets for help on using tickets.