IPTV stream stops in browser

[VCR58]

From the browser I started streaming a live IPTV channel in v5 and within a minute or so the image freezes. I changed the default streaming profile to 240p from default to try to reduce the load on the CPU in case that was the issue. In this example I'm using my Linux setup but I see the same issue on my Windows 10 v5 setup which has a much faster CPU. Also, it doesn't seem to matter what channel I watch the stream always freezes soon after starting. 

It's only in the browser that I have seen this, Kodi and Nlite work fine with IPTV.

[sub]

Post the logs and I'll take a look.

[VCR58]

Post the logs and I'll take a look.

Oops! Forgot to hit the "Add Attachment" button.

[sub]

How is the CPU usage at the time?

[VCR58]

How is the CPU usage at the time?

According to the Linux task manager the CPU usage spiked to 15% but it mostly was less than 10%. I don't see much change to the CPU when streaming is running or not.

[sub]

When you stream a channel to the web browser it creates a temp file with an the ffmpeg logging. On Windows it's in c:\users\public\npvr-data\web\. I can't remember where it is on linux. Maybe /var/opt/nextpvr/web/?

[mvallevand]

It would have been better if you posted all the logs, this just shows one problem area and not the start of transcoding or when the pkt->duration = 0 error might have started.

Martin

[VCR58]

It would have been better if you posted all the logs, this just shows one problem area and not the start of transcoding or when the pkt->duration = 0 error might have started.

Martin

This time I restarted the server, started the IPTV channel stream, then hit the log button after the stream stopped. The Web/Temp files were not included using the log button so I manually added it.

[mvallevand]

Did you try using vaapi transcoding?

Martin

[sub]

It's because the IPTV stream took too long to deliver new data. I've made the timing a little more flexible for the next build, which will hopefully help.

If your IPTV provider has ts streams instead of m3u8 streams, you may find these are better, since the data arrives at a consistent pace, rather than chunks every 10 or so seconds.