Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 47

Thread: Get recording length from stream

  1. #21
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    sub: You have a PM!

  2. #22
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    Yes, but I'm not using ffprobe. If reading stream from beginning to end it's probably working. But the way I was thinking was to send a range request and directly start reading from end, but that does not seem to work.

  3. #23
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    90,856
    Quote Originally Posted by skogl View Post
    sub: You have a PM!
    Thanks - I'll take a look at it.

    Just to confirm, was the player VLC? and what was the server you used in this case?

  4. #24
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    90,856
    Ok, it looks like that was exoplayer. That's fine, we can focus on exoplayer for a bit.

    I guess we can work on the assumption that it's a limitation VLC, that it can't do durations of .ts files played over http?

    First thing I notice about your wireshark capture from exoplayer, is the mime type is 'video/mpeg' not 'video/MP2T'. Is it actually a .ts file you're playing?

  5. #25
    Join Date
    May 2006
    Location
    Canada
    Posts
    28,890
    Ok the other way to play a file is with the f= and the filename

    Playing your file (I renamed it to play as a recording) with ffplay (which doesn't read the whole file either) gives the correct time

    Input #0, mpegts, from 'http://172.16.3.2:8866/stream?f=K:/NBA+Basketball/NBA+Basketball_20190409_22300100.ts':
    Duration: 00:12:59.78, start: 75861.826589, bitrate: 3575 kb/s

    Maybe check that.

    Also in config.xml turn on extend logging to see more info on the range requests.

    There is also a nuiance with /stream?f= mode you proably want to add &http=true to get really accurate responses to the range requests.

    Martin
    Last edited by mvallevand; 2019-04-12 at 05:50 PM.

  6. #26
    Join Date
    May 2006
    Location
    Canada
    Posts
    28,890
    Testing in VLC, I see that non of those modes work in getting the location, here is the extended logging

    Code:
    2019-04-12 13:47:46.332	[DEBUG][20]	partial file: bytes=348222288-
    2019-04-12 13:47:46.332	[DEBUG][20]	Reponse header:
    HTTP/1.1 206 Partial Content
    Server: N-PVR
    Accept-Ranges: bytes
    Content-Range: bytes 348222288-348472287/348472288
    Content-Length: 250000
    Content-Type: application/octet-stream
    Connection: close
    
    
    2019-04-12 13:47:46.332	[DEBUG][20]	RollingFile.Seek(348222288)
    2019-04-12 13:47:46.332	[DEBUG][20]	bufsize: 200000
    2019-04-12 13:47:46.332	[DEBUG][20]	about to read 200000 from location 348222288  (current length = 348472288)
    2019-04-12 13:47:46.343	[DEBUG][20]	++++200000
    2019-04-12 13:47:46.343	[DEBUG][20]	Sent: 200000 bytes
    2019-04-12 13:47:46.343	[DEBUG][20]	about to read 50001 from location 348422288  (current length = 348472288)
    2019-04-12 13:47:46.343	[DEBUG][20]	Not all bytes read@2
    2019-04-12 13:47:46.343	[DEBUG][20]	Read() didnt get all bytes. Got 50000 of 50001 bytes requested.
    2019-04-12 13:47:46.343	[DEBUG][20]	++++50000
    2019-04-12 13:47:46.344	[DEBUG][20]	Sent: 250000 bytes
    2019-04-12 13:47:46.344	[DEBUG][20]	RollingFile.Close()
    This shows the extra 1 byte issue that I was talking about. User fred250 knows more about this issue, I think it is the range request are zero based, so position 348472287 is the last byte in the file and NextPVR is just logging something wrong.

    Martin

  7. #27
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    20
    Sub: All your assumptions are correct. It's exoplayer, I also Believe that Vlc has these limitations and it is a .ts file I'm playing.

  8. #28
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    90,856
    Can you try to get another wireshark capture of exoplayer to the file on apache? Confirm it reports the duration. I'll check the mime type and other headers.

  9. #29
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    90,856
    Quote Originally Posted by mvallevand View Post
    This shows the extra 1 byte issue that I was talking about. User fred250 knows more about this issue, I think it is the range request are zero based, so position 348472287 is the last byte in the file and NextPVR is just logging something wrong.
    It's probably not worth adding this other /stream?f= call into the mix. (since it will just complicate the discussion, given the buggy byte range and needing http=true). This is not an issue on the original call he was looking at.

  10. #30
    Join Date
    May 2006
    Location
    Canada
    Posts
    28,890
    Didn't that buggy byte range apply to the recording_id too which is why fred250 needed f= with his Samsung app.

    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
  •