Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 47

Thread: Get recording length from stream

  1. #31
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    I can confirm that apache is working but it's a bit hard for me to give you a wireshark capture from it. If you must have I can get it but do you really have to?

  2. #32
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    91,213
    Quote Originally Posted by skogl View Post
    I can confirm that apache is working but it's a bit hard for me to give you a wireshark capture from it. If you must have I can get it but do you really have to?
    I don't really have much to go on otherwise. Sorry!

  3. #33
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    91,213
    Quote Originally Posted by mvallevand View Post
    Didn't that buggy byte range apply to the recording_id too which is why fred250 needed f= with his Samsung app.
    Not that I'm aware of. /live?recording=xxxx should be entirely standard http, and should work with anything that can play a file over http. (if you think that is not the case, let me know, and I'll absolutely fix this call)

    The f= call was originally created for the MVP playback, and had a bug right since it's beginnings, but the MVP worked fine with it, so we never changed it. Later when we started repurpose the call for other stuff, we had to add a "http=true" parameter, so that it could be used with things expecting the standard http type responses (while retaining the original bug without http=true, so that it continued to work the way MVP playback expected).

  4. #34
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    Have you found anything from the captures I sent you?

  5. #35
    Join Date
    May 2006
    Location
    Canada
    Posts
    29,174
    I don't what kind of app you are developing but the duration of all recordings is available via the recording api.

    Martin

  6. #36
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    I know that, but I need to get it from the actual stream data. I have sent wireshark capture data to sub where this is possible from another pvr and apache with the same file. So there's something different in NPVR http server, maybe it can be fixed or maybe I can fix something in my end.

  7. #37
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    91,213
    Quote Originally Posted by skogl View Post
    Have you found anything from the captures I sent you?
    I had actually replied to your PM, asking a question.

  8. #38
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    91,213
    Better to keep the discussion here, rather than PM, so here was what I had replied to you:

    ----------------------

    Quote Originally Posted by skogl
    Hi, just checking to ser that you got my last PM about the apache wireshark capture. Lost a bit momentum when I had trouble getting that capture…

    / skogl
    I've just been looking at it now. I can't see any obvious difference to the response headers from apache

    HTTP/1.1 200 OK
    Date: Sat, 13 Apr 2019 11:26:38 GMT
    Server: Apache/2.4.25 (Raspbian)
    Last-Modified: Thu, 28 Mar 2019 16:12:01 GMT
    ETag: "14c543e0-58529d074c2cf"
    Accept-Ranges: bytes
    Content-Length: 348472288
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: video/MP2T
    This is pretty similar to NextPVR, with the exception of NextPVR not including "Accept-Ranges: bytes"

    Is there an easy way for me to reproduce this? Are you using an 'Exoplayer' Android app? (I've got a dusty tablet I'm charging up)

  9. #39
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    91,213
    Quote Originally Posted by skogl
    Quote Originally Posted by sub
    Quote Originally Posted by skogl
    Hi, just checking to ser that you got my last PM about the apache wireshark capture. Lost a bit momentum when I had trouble getting that capture…

    / skogl
    I've just been looking at it now. I can't see any obvious difference to the response headers from apache

    HTTP/1.1 200 OK
    Date: Sat, 13 Apr 2019 11:26:38 GMT
    Server: Apache/2.4.25 (Raspbian)
    Last-Modified: Thu, 28 Mar 2019 16:12:01 GMT
    ETag: "14c543e0-58529d074c2cf"
    Accept-Ranges: bytes
    Content-Length: 348472288
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: video/MP2T
    This is pretty similar to NextPVR, with the exception of NextPVR not including "Accept-Ranges: bytes"

    Is there an easy way for me to reproduce this? Is Exoplayer an Android app? (I've got a dusty tablet I'm charging up)
    Anyway, yes, you can clone latest exoplayer from github and run "demo app". You don't even need a pad, you can use the emulator since you are not interested in actually looking at the recording but just want the duration.

    "Accept-Ranges: bytes" does sound related to the issues I'm experiencing. The feeling I'm having is that the range-request does not return the correct bytes.

    Let me know if you need any pointers of how to setup exoplayer environment.

    / skogl
    I just tried playing http://nextpvr.com/test.ts file (apache web server), and exoplayer on my Android tablet is just reporting 'sorry, file format not supported'. Does it play for you and give a duration?

  10. #40
    Join Date
    May 2006
    Location
    Canada
    Posts
    29,174
    Last week I tried his file on your officail Android app and it played fine with ExoPlayer and it used the API for the duration. That is why I asked about what kind of app he is developing he could do the same thing.

    It is going to boil down to the h/w profile for the Android device.

    Martin

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •