HLS live TV not working, recording seems fine

[sgilani]

I'm not sure you're right on that one. Usually you'd be able to get HLS or ts from a provider, not m2ts. m2ts is typically only used on dv cameras and some blu-ray stuff.

I tried using MPEG2 TS in v5, and it causes v5 to transcode the stream even though it is already h264/aac.

Can you supply a log showing an attempt to directly access the stream?

I've attached two sets of logs:

hls-logs - attempting to directly access the HLS stream (no proxy involved)
2ts-logs - attempting to access the m2ts stream.

Perhaps the provider is returning the wrong MIME type then, not sure. I ran wget against the stream URL and got this:

Code:

HTTP request sent, awaiting response... 200 OK
Length: unspecified [video/m2ts]
Saving to: 'test.2ts’

test.2ts       [      <=>                                                         ]   5.70M  1.84MB/s

ffmpeg reports this on the saved file:

Code:

Input #0, mpegts, from 'test.2ts':
  Duration: 00:00:12.02, start: 35898.019000, bitrate: 3977 kb/s
  Program 1
    Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 119.89 tbc
    Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 126 kb/s

Link to that file: https://drive.google.com/file/d/1teu4B5R...sp=sharing

[mvallevand]

Do you give NextPVR a .ts file or a .m3u file to play?

Martin

[sgilani]

.m3u8, loaded in in the settings under IPTV device.

[sub]

2ts-logs - attempting to access the m2ts stream.

Perhaps the provider is returning the wrong MIME type then, not sure. I ran wget against the stream URL and got this:

Code:

HTTP request sent, awaiting response... 200 OK
Length: unspecified [video/m2ts]
Saving to: 'test.2ts’

test.2ts       [      <=>                                                         ]   5.70M  1.84MB/s

ffmpeg reports this on the saved file:

Code:

Input #0, mpegts, from 'test.2ts':
  Duration: 00:00:12.02, start: 35898.019000, bitrate: 3977 kb/s
  Program 1
    Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 119.89 tbc
    Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 126 kb/s

Link to that file: https://drive.google.com/file/d/1teu4B5R...sp=sharing

I downloaded the file and took a look. It's just a regular transport stream (188 byte packets), rather than a m2ts (192 byte packets)

[sgilani]

I downloaded the file and took a look. It's just a regular transport stream (188 byte packets), rather than a m2ts (192 byte packets)

Ah, okay thanks for checking that. I guess the MIME type is set incorrectly by the provider then--do you think that's what is confusing NextPVR and causing it to transcode?

[sub]

Unfortunately your nrecord.log is cut short, so doesn't have the snippet of code I really wanted to see. Can you try again? Leave it trying a bit longer, and make sure you use the 'log files' button in the web app, so that it flushes the log files to disk.

[sub]

I downloaded the file and took a look. It's just a regular transport stream (188 byte packets), rather than a m2ts (192 byte packets)

Ah, okay thanks for checking that. I guess the MIME type is set incorrectly by the provider then--do you think that's what is confusing NextPVR and causing it to transcode?

If I can get a slightly longer nrecord.log, I'm pretty sure I'll be able to tell why.

[sgilani]

I downloaded the file and took a look. It's just a regular transport stream (188 byte packets), rather than a m2ts (192 byte packets)

Ah, okay thanks for checking that. I guess the MIME type is set incorrectly by the provider then--do you think that's what is confusing NextPVR and causing it to transcode?

If I can get a slightly longer nrecord.log, I'm pretty sure I'll be able to tell why.

np, attached.

[sub]

So is this some proxy thing you've written? The easiest fix would be if the url could replace the "/mpeg.2ts" bit with "/mpeg.ts", then it'll work without transcoding it.

Since it's not finding this ".ts", it's then proceeding to check the mime type, which your server is incorrectly reporting as "video/m2ts", which then forces it to transcode.

[sgilani]

So is this some proxy thing you've written? The easiest fix would be if the url could replace the "/mpeg.2ts" bit with "/mpeg.ts", then it'll work without transcoding it.

Since it's not finding this ".ts", it's then proceeding to check the mime type, which your server is incorrectly reporting as "video/m2ts", which then forces it to transcode.

I haven't written it--it's from the provider. It's written in Python though so I went poking around and got it to accept requests to /mpeg.ts instead. For these mpegts streams, the proxy is sending a 302 redirect back to a dynamically generated link on their server. That url is /mpeg.2ts, nothing I can do about that I'm afraid.

No transcoding this time, but it fails quickly with "Unable to find available capture device". I've attached the nrecord.log.

If there's another way other than a 302 that NextPVR would be happier with, tbh I can just hack that into the proxy.