IPTV channels freeze within a minute in Kodi

[sgilani]

My IPTV channels work great in the NPVR frontend. In Kodi, many of them freeze up in less than a minute and I eventually get the tuner not available message. Bringing up the buffer stats with Ctrl+Shift+O shows vq/aq pegged at 99 and then fall to 0, as if the stream dried up. Watching in NPVR or VLC is rock steady for hours on end though.

NPVR and Kodi logs attached.

sub, happy to share the IPTV credentials with you as well. Some of the channels work just fine through Kodi, but many others don't. Quite odd, but maybe you could see the difference between them.

running 4.2.2 and Kodi 17.6 stable, issue reproducible on Kodi in Windows, Linux, and RPi.

edit: The regular use case is running Kodi on the same PC as NPVR, so wired/wireless doesn't matter. FWIW, the same symptom exists on all remote RPi clients, both wired and wireless.

[sgilani]

Just realized I didn't include a kodi debug log.. whoops.

Full debug log attached. Here's a snippet of what happened when the stream died:

Code:

20:33:36.206 T:140506197636864   DEBUG: CPullupCorrection: detected pattern of length 1: 40000.00, frameduration: 40000.000000
20:33:36.708 T:140506189244160  NOTICE: CVideoPlayerAudio::Process - stream stalled
20:33:37.089 T:140506197636864    INFO: CVideoPlayerVideo - Stillframe detected, switching to forced 25.000000 fps
20:33:37.089 T:140506197636864   DEBUG: CPullupCorrection: pattern lost on diff 200000.000000, number of losses 1
20:33:42.227 T:140506197636864   DEBUG: CPullupCorrection: detected pattern of length 1: 40000.00, frameduration: 40000.000000
20:33:47.622 T:140508674139328    INFO: CheckIdle - Closing session to http://192.168.1.141 (easy=0x7fca20004d80, multi=0x7fca20018d00)
20:33:47.622 T:140508674139328    INFO: CheckIdle - Closing session to http://192.168.1.141 (easy=0x7fca4c125290, multi=0x7fca4c066460)
20:33:48.138 T:140508674139328    INFO: CheckIdle - Closing session to http://192.168.1.141 (easy=0x7fca457f9dd0, multi=0x7fca457e1060)
20:33:48.138 T:140508674139328    INFO: CheckIdle - Closing session to http://192.168.1.141 (easy=0x7fca8c05c8e0, multi=0x7fca8c01aae0)
20:33:55.888 T:140508674139328    INFO: CheckIdle - Closing session to http://192.168.1.141 (easy=0x7fca44031e90, multi=0x7fca4406b750)
20:34:00.431 T:140507319666432   DEBUG: Thread JobWorker 140507319666432 terminating (autodelete)
20:34:00.431 T:140506474465024   DEBUG: Thread JobWorker 140506474465024 terminating (autodelete)
20:34:00.431 T:140508201981696   DEBUG: Thread JobWorker 140508201981696 terminating (autodelete)
20:34:00.432 T:140507329570560   DEBUG: Thread JobWorker 140507329570560 terminating (autodelete)

Anyone have ideas here?

[sgilani]

Can this thread be moved into the Kodi subforum? This is looking more like a Kodi addon issue.

Some more data points: starting a recording and then watching the recording is just fine.. it's only live TV that is problematic. I tried changing the buffering settings in advancedsettings.xml but it didn't make any difference.

sub (or anyone else who has an idea), I'm happy to share credentials if you want to try this on your end. It does seem there's a bug in the Kodi addon but I don't know how to proceed further in debugging.

[sub]

IPTV data can be very bursty, like receiving 5 seconds of video, then 5 seconds of nothing, then receive another 5 seconds of video, and so on. It's possible Kodi doesn't like this. I'm not well placed to answer any questions about how Kodi behaves when the data arrives in this way though.

[sub]

If your primary viewing is going to be in Kodi, you're probably better off using .ts streams, rather than .m3u8 streams. A lot of IPTV providers give you the choice of either type, with a slightly different m3u url. The ts are just a continuous stream of data, and not bursty like m3u8 streams.

[sgilani]

They're TS streams already, so I was thinking they were "steady" streams already since other players like VLC and mplayer can play them back just fine too. The IPTV provider's own Kodi plugin also streams them fine.. it's only when going through NextPVR that the stream dies like this.

Is NextPVR just writing the TS to disk, or doing something else to it? If there's a way to force it to transcode, I'm willing to give that a try to see if it helps.

[sub]

Is NextPVR just writing the TS to disk, or doing something else to it?

Its just writing the data to disk as it arrives.

If there's a way to force it to transcode, I'm willing to give that a try to see if it helps.

No, not with Kodi NextPVR addon. You might be able to using the XNEWA addon for kodi, but it's not something I've tried.

[sgilani]

Interesting.. X-NEWA's timeshift playback seems to play the stream fine, and I see that it has a buffer setting. I left it at the default 4000, and I see from the Ctrl-Shift-O OSD that the vq/aq dips to the 70s before coming back up to 99. With the NextPVR addon, the vq/aq starts at 99 and then just falls and never recovers, as if the buffer isn't ever getting re-filled.

Is there a way to make NextPVR buffer the stream a bit more before kicking off playback? Maybe something isn't playing right when the stream isn't adequately buffered on disk as Kodi starts playback.

[sub]

The NextPVR Kodi addon isn't doing the playback itself. Its just passing the URL to Kodi, and Kodi takes care of the playback and buffering etc.

You could try the recent Kodi 18 builds, which do things a slightly different way.

[sgilani]

Just tried out Kodi 18 alpha 2, same issue unfortunately. All of this definitely worked fine in v4.1.0, btw. The problems started after I upgraded to 4.1.1.