Get recording length from stream

[skogl]

sub: You have a PM!

[skogl]

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.

[sub]

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?

[sub]

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?

[mvallevand]

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

[mvallevand]

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

[skogl]

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.

[sub]

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.

[sub]

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.

[mvallevand]

Didn't that buggy byte range apply to the recording_id too which is why fred250 needed f= with his Samsung app.

Martin