5.0.6 running mpegts stream through ffmpeg needlessly

[mail@hillers-it.de]

My version is the 5.0.7. Fresh install yesterday.

[mvallevand]

If you used the dll in this thread on 5.0.7 even worse. Run the update again to fix it. If that doesn't work create a new thread in the linux sub forum and attache the zipped logs.

Note if the only original problem was high CPU note that the web client and the RPi aren't a good mix you will need to test with another client like Kodi.

Martin

[sub]

As the guys suggested - get back to 5.0.7 as a first step. Using an older version of NShared.dll will possibly break things, or make them worse.

Once you're back to 5.0.7, reproduce the error, then post the logs.

[mail@hillers-it.de]

I have the dll from the 5.0.7
at 14:15-14:20 & 14:25-14:30 two recordings (of Wilmaa). In both recordings ffmpeg started.
On the third recording at 14:35-14:40 (also HD) no ffmpeg and minimal CPU usage.
Live TV over Kodi the same behavior.
I hope someone can help me.

[Graham]

I have the dll from the 5.0.7
at 14:15-14:20 & 14:25-14:30 two recordings (of Wilmaa). In both recordings ffmpeg started.
On the third recording at 14:35-14:40 (also HD) no ffmpeg and minimal CPU usage.
Live TV over Kodi the same behavior.
I hope someone can help me.

Did you attach NextPVR logs as described at ... https://github.com/sub3/NextPVR/wiki/get-help ... The zip file might be in the Downloads folder on Linux.

The forum software silently drops attachments that are more than 2 Meg

[mail@hillers-it.de]

ok, next try. my first time to write in a forum.

[mvallevand]

For IPTV, if NextPVR can't determine that the URLs in the m3u8 can download ts streams that can be played directly it will use ffmpeg. From your description I found a link on the internet to wilmaa.com, they have many programs streams. I suggest you PM sub with a link of the m3u8 you are using and he can investigate.

Martin

[mail@hillers-it.de]

Thanks, i will do it.

[sub]

Thanks for the example streams. In this case, it was valid that NextPVR was falling back to using ffmpeg because this was a type of stream it couldn't handle natively. Most m3u8 streams are transport stream based, and NextPVR handles these natively. In this case, they were using the less common mp4 based m3u8 stream, which use separate streams for the audio and video, and NextPVR was unable to handle it natively, so had to rely on ffmpeg converting it to format it could use.

The easiest solution for you is probably switching to another IPTV provider.

[sub]

Unfortunately even ffmpeg doesn't like some things about the way these stream are done, and it takes a very long time to start producing data....like 25 seconds, so even a fast machine isn't coping very will with these.