That's interesting, according to the tests this is supported.

I think the issue comes in rygel-http-get.vala:

    private async void handle_item_request () throws Error {
        var need_time_seek = HTTPTimeSeek.needed (this);
        var need_byte_seek = HTTPByteSeek.needed (this);

        if ((HTTPTimeSeek.requested (this) && !need_time_seek) ||
            (HTTPByteSeek.requested (this) && !need_byte_seek)) {
            throw new HTTPRequestError.UNACCEPTABLE ("Invalid seek request");
        }

HTTPTimeSeek.needed (this) would be false, I assume, perhaps because this is a video item?

    public static bool needed (HTTPGet request) {
        return request.item is AudioItem &&
               (request.item as AudioItem).duration > 0 &&
               (request.handler is HTTPTranscodeHandler ||
                (request.thumbnail == null &&
                 request.subtitle == null &&
                 request.item.is_live_stream ()));
    }

The test code only attempts an audio item, not video.

No, VideoItem is derived from AudioItem. It might be special to the GstPlugin though in a way that we currently can't know if it's Audio or Video and just treat it as an generic item.

An audio test source does work, last I tried.

Can you paste the config you're using?

I've been grabbing packages off of http://packages.debian.org/experimental/rygel because I haven't been able to get all the dependencies to build yet.

So, unfortunately it's difficult for me to build, otherwise I'd hack on it.

How about these suspect lines in the video item constructor that aren't in the audio item?

        this.thumbnails = new ArrayList<Thumbnail> ();
        this.subtitles = new ArrayList<Subtitle> ();

Unless request.handler is HTTPTranscodeHandler, this could cause the failure.

Created attachment 198350 [details]
config

Ah. It doesn't have a duration. We need to special-case that "give me everything" here then.

Created attachment 200023 [details] [review]
Preliminary patch fixing npt=0- issue.

Should ntp=0- be treated as no seek request at all? If so, attached patch does it, but only for time seek requests. I haven't touched byte seek requests.

Created attachment 200239 [details]
Generated C file with patch applied.

(In reply to comment #9)
> Created an attachment (id=200023) [details] [review]
> Preliminary patch fixing npt=0- issue.
> 
> Should ntp=0- be treated as no seek request at all? If so, attached patch does
> it, but only for time seek requests. I haven't touched byte seek requests.

You have to since we need to add something like

(rygel:20961): Rygel-DEBUG: rygel-http-get.vala:166: TimeSeekRange.dlna.org : npt=0.000-6839.999/6840.000

in the response when know the duration. But we still do that apparently. :)

Original reporter: Does it work for you when you replace the attached C file?

Review of attachment 200023 [details] [review]:

First line of the commit message is too long

::: src/rygel/rygel-http-time-seek.vala
@@ +100,2 @@
     public static bool requested (HTTPGet request) {
+        string? seek_request = request.msg.request_headers.get_one ("TimeSeekRange.dlna.org");

a) Line is too long (>80 chars)
b) no need for nullable string here, you mainly need them for parameters and as a hint in return values; also use "var", see https://live.gnome.org/Rygel/CodingStyle (I forgot to give you that link previously, sorry).

@@ +103,3 @@
+        if (seek_request != null)
+        {
+            return seek_request != "npt=0-";

Strictly speaking whitespace is not allowed in "npt.." but I wonder if we should ignore them for the sake of interoperability

Created attachment 200345 [details] [review]
Preliminary patch fixing npt=0- issue, 2

Updated coding style.

I will check it out and see.  It will be a few days before I can look at it.

Well now I'm confused.  Granted it's been over a month since I reported the issue, and my TV's software rev hasn't changed, but I'm having trouble getting my TV to request a time seek!  It has done it a few times tonight, but has never been repeatable.  The videotestsrc is just working right now!

With that said, the proposed patch does not work.  It trips up the case where there is no time seek header and causes it to fail.  Something more like 

return seek_request != null && seek_request != "npt=0-";

would fix that.  I'll keep testing and see if I can get it to fail, not sure how long that will take...

Review of attachment 200345 [details] [review]:

::: src/rygel/rygel-http-time-seek.vala
@@ +102,3 @@
+                                        ("TimeSeekRange.dlna.org");
+
+        return seek_request != "npt=0-";

Ok now, apart from the fact that the check for != null is missing now.

Created attachment 201807 [details] [review]
Preliminary patch fixing npt=0- issue, v3

Yes, I was confused a bit about those nullable types.

Pushed with minor formatting fixes

We need to find another solution for this, this breaks DLNA test 7.3.33.4

Additionally VLC likes to request resources with "bytes=0-" so we need to gracefully handle that as well.

*** Bug 671193 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 674736 ***