HLS live TV not working, recording seems fine

[sgilani]

(this is separate from my previous thread which was fixed by an incorrect timeshift setting)

For HLS streams, live TV doesn't seem to work. I get no picture, and a short blip (~500ms) of audio, and then nothing else. I've detected that NextPVR v5 is making dozens of requests per second to the server (I guess looking for more chunks?), if that is a clue. This worked fine in v4, and it did not have excessive requests either.

The buffer file grows as expected and plays back just fine. Recordings are fine too.

Logs and map file attached, thanks!

p.s. on a related note, I noticed that TS streams with the MIME type video/m2ts get needlessly transcoded through ffmpeg. Could this be changed? It seems like only video/mp2t is left as-is.

[mvallevand]

Are your sure that your video/m2ts files are h264/aac format?

Martin

[sgilani]

Are your sure that your video/m2ts files are h264/aac format?

Martin

Yep, they are. I brought it up because this service provides either HLS or m2ts. I had always used HLS for this service in v4 so I tried that in v5 and got this issue. Trying m2ts works but with transcoding that pegs the CPU quite a bit. Doesn't seem like we have configure the backend transcoding or else I could try doing a quick repack with -vcodec copy -acodec copy as a hack.

[sub]

If you open the channel in VLC, through NextPVR, does it play? ie, using a URL like this:

http://localhost:8866/live?channel=123

[sgilani]

If you open the channel in VLC, through NextPVR, does it play? ie, using a URL like this:

http://localhost:8866/live?channel=123

I get an initial frame of video and again a short blip of audio, and then nothing else.

If I leave it for 10 seconds, I get another frame and another blip of audio.

[sub]

HLS streams seem to be working ok here.

In your logs it looks like you're using some local IPTV service? http://192.168.0.113:6969

[sgilani]

HLS streams seem to be working ok here.

In your logs it looks like you're using some local IPTV service? http://192.168.0.113:6969

Yes, it's a proxy that exposes the underlying service, has been working fine for years in v4. I can share details with you privately if you'd like to recreate.

If we could prevent the m2ts transcoding, that might fix this issue as I could switch to that.

[sub]

Yes, it's a proxy that exposes the underlying service, has been working fine for years in v4. I can share details with you privately if you'd like to recreate.

Nah, i'm not doing that

If we could prevent the m2ts transcoding, that might fix this issue as I could switch to that.

I dont understand what you mean - are you receiving an IPTV stream that is using m2ts? I've never seen a provider doing that. (or do you m3u8?)

[sgilani]

If we could prevent the m2ts transcoding, that might fix this issue as I could switch to that.

I dont understand what you mean - are you receiving an IPTV stream that is using m2ts? I've never seen a provider doing that. (or do you m3u8?)

Yes, I can get either HLS or m2ts from the provider.

I used HLS before in v4, but it's not working here (the issue here in the thread).

I tried using m2ts in v5, and it causes v5 to transcode the stream even though it is already h264/aac. The only reason I can think of is that its of type video/m2ts and not video/mp2t. If we could prevent transcoding of video/m2ts (or do some sort of fast repack of the container), then I could use that and avoid HLS altogether.

[sub]

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?