Gstreamer (4097) HLS stream (Pluto) occationally hangs a few seconds after zapping when switching bitrate and never recovers

[defkev]

This pretty much started out of the blue and I haven't had time to debug it yet (maybe related to WEBVTT?)

Add service to bouquet:

....
#SERVICE 4097:0:0:0:0:0:0:0:0:0:http%3a//stitcher.pluto.tv/v1/stitch/embed/hls/channel/6565413e4261ca0008215320/master.m3u8?appVersion=DNT&deviceDNT=1&deviceId=DNT&deviceMake=DNT&deviceModel=DNT&deviceType=DNT&deviceVersion=DNT:Pickers & Pawn
#DESCRIPTION Pickers & Pawn

Zap to channel, it'll start at 639x360 (640930 bitrate) and eventually freeze instead of switching to the next higher bitrate. Sometimes it recovers, sometimes it doesn't.

Oddly enough, if you zap during a commercial break, which will always start at the highest bitrate (720p) the stream will consequentially work just fine.

[jbleyel]

This is probably a problem of Pluto and not of enigma. You can try 5002 and check if ffmpeg has a different handling of resolution changes.

[defkev]

Well it's not a problem with other Pluto streams which don't use WEBVTT for subtitles.

Furthermore using Gstreamer (4097) is already a workaround because extplayer3/ffmpeg (5002) doesn't like stream swapping either and occasionally hangs afters commercials when going back to the main stream (audio resume, picture does not)

Edit: After a quick search, I am vaguely confident this is indeed related to subtitles → https://github.com/xbmc/inputstream.adaptive/issues/1831

[jbleyel]

So you absolutely sure that the issue will go if you disable the subs?

[jbleyel]

The Kodi patch is probably the solution for Pluto on Kodi but this is completely different to gstreamer. I have no idea how to fix this issue. So we have only one option for now. Ignore webvtt for PlutoTV maybe via setting.