[little-endian]

On the occasion of the current FIFA WM, it would be interesting to stream the UHD-version which is offered by the Austrian broadcaster "ORF". Nominally free, but limited to Austrian IP address ranges and also encrypted (DRM).

Using the following -

Hardware: Amazon FireTV Cube
Kodi: 20.0 BETA1 (19.90.801)
Add on: ORF TVthek 0.12.6 
InputStream Adaptive 20.3.1

the usual and thought to have been fixed/improved meanwhile issue arises that the used buffer of only the infamous 8 or so seconds is by far too little to cover temporary inflow variations in the broadcaster's CDN - VPN/Proxy - ISP - chain leading to a flabbergasting bad performance despite a nominal average data rate available way exceeding that of the to be streamed content in question.

However, no matter what I set in the plugin - assured buffer, maximum buffer, adaptive selection, and whatnot, the buffer remains as always and Kodi stumbles on every so slight data rate constraint within seconds. Hence I am confused whether this still hasn't been fixed/improved or occurs now in particular with this Kodi plugin which unfortunately seems to be required as the m3u8 playlist probable can't be passed on for DRM-compatible decryption otherwise.

[glennguy]

What buffer are you giving the stream itself - how far away from the live edge are you playing? If the timeshift buffer window is a minute long and you're having the 'now' time sit around the 50 second mark, then you can only ever buffer ~10 seconds of content.
In other words, rewind by 20 seconds and see how you go. I have found that official apps often play a reasonable amount behind the live edge (eg. 30 seconds). By default inputstream.adaptive does around 12 iirc.

[little-endian]

Hi glennguy,

the master of streaming and buffering itself replying, many thanks!

"What buffer are you giving the stream itself - how far away from the live edge are you playing?"

That is a good and valid question indeed which I am unfortunately not able to answer for sure as I don't now where the "zero point" of that ORF stream actually is. Compared to other streams showing the same game (such as the German broadcaster "ZDF"), it is at least 20 seconds behind, but that includes any embedded "delay" of the ORF stream itself of course.

Skipping back after playback started doesn't really seem to help and is extremely laggy and error-prone in Kodi anyway. Often enough, the playback instance is entirely with the demand of skipping a bit through a video.

As for the setting of the plugin itself, I've tested everything so far ("Test" with that amount of segments, "ask quality", etc.). In the section where the 60 seconds of buffer and 120 total are the default values, it feels like I can enter whatever number I want without making even the slightest difference, just like with the attempt to edit the infamous advancedsettings.xml, a popular trap of hope which many including myself use(d) to fall in.

All I still get is that mediocre few seconds buffering which is highly sensitive to any transmission fluctuations between the CDN, VPN, ISP, etc. without surprise.

I think the real best option would be to try those UHD-streams by yourself in conjunction with the TVthek plugin if you don't mind. Since most streams are geoblocked for Austrian IP-addresses, I'd be happy to provide you access to a respective VPN in case you don't have one at hand anyway already (feel free to send me a PM if interested). Would be the least from my side to finally get this horrible and annoying buffering in Kodi resolved* once and for all.

* Within the broadcaster's hold times of the segments on their servers of course. I am aware that this is a fundamental limitation which cannot be resolved by even the largest buffer if the data throughput is so slow that segments expire by the time they can be retrieved, but I don't think that it is that extreme in my case as I used to get way better results in conjunction with saving the stream first and playing it timeshifted with e.g. Streamlink. Unfortunately, since they all hopped on that stupid DRM train (which gets hacked by the pros anyway), this isn't an easy option anymore.

[wsnipex]

ORF is known to have occasional bandwidth issues for live 4k streams, I've had my share of unreliable and buffering streams even with the official android app without any VPN.
That said, I'll try to test again with kodi.

[glennguy]

@little-endian I guess what I meant about how far away from the live edge was from the way Kodi sees it.
Example:


In this case I will get max 1 or 2 segments buffer, provided the segments are available on the server.

I will try the addon here, I think I can get a VPN working. I'll let you know if I need your help.
If you're thinking that there's an issue with the buffering in inputstream.adaptive or the settings could use some clarification then please open an issue at https://github.com/xbmc/inputstream.adaptive . I do check on the forum from time to time but it's better to track these things on github, and easier to nag me

[little-endian]

Now I literally see what you mean. Okay, upon start of the playback, it seems to be about 11 seconds "behind" then.

ORF is known to have occasional bandwidth issues for live 4k streams

Apparently in general as their ~ 10 Mbps version in HD stutters often enough as well and of course none of their streams would be immune against shortcomings if it is indeed a limitation on their end depending on the users and total demand.

What rather speaks against this theory though is that the performance is often lousy as well even when the official FIFA World Cup transmissions have ended and the regular ORF program is shown on those streams (almost absurdly in then also better quality compared to the mediocre ~ 3-4 Mbps stream in 720p), as I cannot imagine that a lot of users will still request them, especially given the fact that they aren't visible anymore in either the TVthek or Kodi but only via the direct "mpd call".

However, what I witness with Streamlink (unless that tool still is even more buggy than I think of this point), looks to be a way bigger challenge to any inputstream adaptive plugin for Kodi than just a larger buffer, I'm afraid -

because, even just writing the stuff into a file isn't successful in the long run as their streaming server seems to timeout on segment requests frequently with Streamlink losing one of the streams (sometimes audio, sometimes video) entirely so one ends up with either a still frame with only audio or vice versa a video without audio, even when hugely buffering by recording the stream and restreaming it with ffmpeg as HLS:

*******************************************************************************************************************************************************
[22:17:07.245791][stream.dash][error] Failed to open segment https://orfuhd.mdn.ors.at/orf/orf_uhd_50...46349.dash: Unable to open URL: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...46349.dash (404 Client Error: Not Found for url: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...46349.dash)
[download] Written 3.50 MiB to ORFTEST3014.ts (3m04s @ 14.66 KiB/s) [22:17:07.450212][stream.dash][error] Failed to open segment https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash: Unable to open URL: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash (404 Client Error: Not Found for url: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash)
[download] Written 3.50 MiB to ORFTEST3014.ts (3m04s @ 14.66 KiB/s) [22:17:07.645661][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:07.646509][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.50 MiB to ORFTEST3014.ts (3m05s @ 14.66 KiB/s) [22:17:08.152717][stream.dash][error] Failed to open segment https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash: Unable to open URL: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash (404 Client Error: Not Found for url: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash)
[download] Written 3.50 MiB to ORFTEST3014.ts (3m05s @ 14.66 KiB/s) [22:17:08.553648][stream.dash][debug] Download of segment: orf_uhd_50-audio_208482_deu=208000-80144170044943.dash complete
[download] Written 3.59 MiB to ORFTEST3014.ts (3m05s @ 19.02 KiB/s) [22:17:08.713462][stream.dash][error] Failed to open segment https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash: Unable to open URL: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash (404 Client Error: Not Found for url: https://orfuhd.mdn.ors.at/orf/orf_uhd_50...49949.dash)
[download] Written 3.59 MiB to ORFTEST3014.ts (3m10s @ 13.47 KiB/s) [22:17:13.655814][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:13.656630][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.59 MiB to ORFTEST3014.ts (3m12s @ 13.47 KiB/s) [22:17:15.194519][stream.dash][debug] Download of segment: orf_uhd_50-audio_208482_deu=208000-80144170332687.dash complete
[download] Written 3.68 MiB to ORFTEST3014.ts (3m16s @ 13.84 KiB/s) [22:17:19.666097][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:19.666915][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.68 MiB to ORFTEST3014.ts (3m18s @ 13.84 KiB/s) [22:17:21.706532][stream.dash][debug] Download of segment: orf_uhd_50-audio_208482_deu=208000-80144170620431.dash complete
[download] Written 3.77 MiB to ORFTEST3014.ts (3m22s @ 13.43 KiB/s) [22:17:25.676173][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:25.677196][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.77 MiB to ORFTEST3014.ts (3m24s @ 13.41 KiB/s) [22:17:27.295898][stream.dash][debug] Download of segment: orf_uhd_50-audio_208482_deu=208000-80144170908175.dash complete
[download] Written 3.86 MiB to ORFTEST3014.ts (3m28s @ 13.79 KiB/s) [22:17:31.686173][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:31.686807][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.86 MiB to ORFTEST3014.ts (3m29s @ 13.78 KiB/s) [22:17:32.690849][stream.dash][debug] Download of segment: orf_uhd_50-audio_208482_deu=208000-80144171196943.dash complete
[download] Written 3.95 MiB to ORFTEST3014.ts (3m34s @ 13.38 KiB/s) [22:17:37.696294][stream.dash_manifest][debug] Generating segment timeline for dynamic playlist (id=1))
[22:17:37.697122][stream.dash][debug] Reloading manifest (audio_208482_deu=208000:audio/mp4)
[download] Written 3.95 MiB to ORFTEST3014.ts (3m36s @ 13.38 KiB/s)
*******************************************************************************************************************************************************

Independently of the returned server errors which of course shouldn't occur in the first place, I question that very error resistance of both - Kodi/inputstream adaptive as well as Streamlink as either it fails completely (including Python errors which suggests immanent bugs) or only downloads one of the streams but restarting the stream manually almost always resolves the problem for a while so I wonder why those segments cannot be kept retrieving even if some of them fail. Aren't those entirely independent HTTP request?

[wsnipex]

indeed, looks very fishy.
OTOH, I watched about 15min of England vs Wales with the UHD 50p stream in kodi without buffering.

[glennguy]

Yes there's only so much that can be done from the player's point of view to 'tolerate' servers like this. We currently allow up to 10 retries for audio/video segments: https://github.com/xbmc/inputstream.adap...#L148-L162 which is more than enough. They should not be publishing segments in playlists that are unavailable for more than 10 seconds.