[NiKRuLeZ]

Hey all

I'm using WebDAV to access a network share to play mkv files. I have a 250 mbps bitrate 4k test file that I'm trying to stream to the nvidia shield through wifi. When I play this file it doesn't playback smoothly at all ... very jittery and choppy. Now in comparison to playing this same stream file through VLC for Android (using WebDAV) ... it works perfectly and the playback is so smooth without any jitters whatsoever. This proves that there aren't any network bandwidth problems as the stream works fine! I've also done a speedtest using iperf and the nvidia shield can achieve a nice high speed of 300 mbps. This now really eliminates any network bandwidth queries.

I also replicated this using Kodi for windows on my laptop which was also connected wirelessly ... no issues playing the 250 mbps bitrate file stream on there via WebDAV ... played smoothly.

What is it about Kodi that causes the stream to lag? This is not using SMB, it's using WebDAV which in comparison should be much more efficient/better.

Anyone shed any light on why Kodi on android specifically struggles with large bitrate files vs VLC for Android/Kodi for Windows - all via WebDAV?

Kodi version: 21.0

TIA

[fritsch]

Yes, kodi's FileCache is not optimized by default for such bitrates as of now in the default settings. It cannot react fast enough (means Cache is not big enough to bring on the next data chunks). I think you can easily fix that - and that you can change luckily in the gui settings now - by increasing the Cache. I would suggest to increase it to roughly 200 MByte, that should make this testfile playable. Combine this with a larger readfactor and increased chunksize as the adaptive one might choke with such high bitrate files. Chunksize of 128 KB or something should help on top (not too sure for webdav, though).

Does that help?

Hint: The OSD shows the cache level when playing those files. Please post some screenshots and additionally a Debug Log if possible, then the optimal values can be suggested.

[jogal]

Maybe its not related to FileCache at all: after all Cache code is the same on all platforms: Windows/Android.

If this doesn't change by changing the cache parameters or even disabling the cache completely, then it's unrelated.

This can be another case of Shield high CPU usage due a combination of multiple factors: Wifi packets - high bitrate - maybe file is DV ?

Possible tests:

• Disable Cache --> GUI settings > Services > Caching > Buffer mode > No buffer
  
• Test with Shield Ethernet (and turn off Wifi)
  
• Test with build from here --> https://forum.kodi.tv/showthread.php?tid...pid3195455
  

WebDAV is HTTPS ?

HTTPS --> more CPU usage

[NiKRuLeZ]

Maybe its not related to FileCache at all: after all Cache code is the same on all platforms: Windows/Android.

If this doesn't change by changing the cache parameters or even disabling the cache completely, then it's unrelated.

This can be another case of Shield high CPU usage due a combination of multiple factors: Wifi packets - high bitrate - maybe file is DV ?

Possible tests:

• Disable Cache --> GUI settings > Services > Caching > Buffer mode > No buffer
  
• Test with Shield Ethernet (and turn off Wifi)
  
• Test with build from here --> https://forum.kodi.tv/showthread.php?tid...pid3195455
  

WebDAV is HTTPS ?

HTTPS --> more CPU usage

This file is not DV. It's this file to be precise: jellyfish-250-mbps-4k-uhd-hevc-10bit.mkv from http://www.larmoire.info/jellyfish/

And it's WebDAV over HTTP not HTTPS.

Just to add, I have this file locally (on a locally attached usb flash drive) and it plays without any stuttering/buffer issues.

But I mean for Shield high CPU usage due a combination of multiple factors: Wifi packets - high bitrate ... this has no impact on VLC for Android ... it just plays the file flawlessly. It does get stuck at the start for around 3 seconds (I'm guessing to to loading things in / buffering), but after this it will just play it normally and smoothly. As for the bugfix RE: high CPU usage ... I don't think this issues is related to that as from the point I made above ... the file plays smoothly when attached to local USB flash drive.

It's boiling it down to a network + kodi on android (64 bit) issue.

Also a little extra to add ... playing the 140mbps test file sees no issues ... flawless playback ... Playing the 160mbps test file is when it starts to stutter constantly.

I'll give the above recommendations a try!

[jogal]

It's this file to be precise: jellyfish-250-mbps-4k-uhd-hevc-10bit.mkv from http://www.larmoire.info/jellyfish/

For reference 300 mbps file (jellyfish-300-mbps-4k-uhd-hevc-10bit.mkv) plays fine on my Shield with Cache enabled and also disabled using 1Gbps Ethernet.  Files are on NAS Synology - NFS v4.0

[NiKRuLeZ]

It's this file to be precise: jellyfish-250-mbps-4k-uhd-hevc-10bit.mkv from http://www.larmoire.info/jellyfish/

For reference 300 mbps file (jellyfish-300-mbps-4k-uhd-hevc-10bit.mkv) plays fine on my Shield with Cache enabled and also disabled using 1Gbps Ethernet.  Files are on NAS Synology - NFS v4.0

Interesting ... whats the performance like using WebDAV?

Also the 300mbps plays on my one using NFS too. It's easy to think that the 300 mbps bitrate video plays normally over NFS but if you compare the playback of that file from a local source (play it from usb flash drivee attached to the shield) you'll see the actual smoothness of the video ... what I saw was jitteryness over NFS 4.0. Can you confirm first playing the file locally and comparing the smoothness (actually how it should be) to it being streamed over NFS and confirm if both have the same smooth playback please.

[NiKRuLeZ]

Also FYI: Screenshot of the data rates (taken from the NAS) for the various protocols all on Kodi streaming the 250 mbps 4k bitrate file.

[fritsch]

Also FYI: Screenshot of the data rates (taken from the NAS) for the various protocols all on Kodi streaming the 250 mbps 4k bitrate file.

Did you change the settings I hinted to? 300 MB FileCache and Readfactor of 4? Combined with higher chunk size?
Does it make a difference?

[NiKRuLeZ]

Also FYI: Screenshot of the data rates (taken from the NAS) for the various protocols all on Kodi streaming the 250 mbps 4k bitrate file.

Did you change the settings I hinted to? 300 MB FileCache and Readfactor of 4? Combined with higher chunk size?
Does it make a difference?

I haven't tried that but just checked and the cache values for memorysize, read factor and chunk size are exactly the same on windows as they are on kodi on android ... smooth playback on Windows as how it plays when playing from a locally attached usb flash drive.

[fritsch]

Also FYI: Screenshot of the data rates (taken from the NAS) for the various protocols all on Kodi streaming the 250 mbps 4k bitrate file.

Did you change the settings I hinted to? 300 MB FileCache and Readfactor of 4? Combined with higher chunk size?
Does it make a difference?

I haven't tried that but just checked and the cache values for memorysize, read factor and chunk size are exactly the same on windows as they are on kodi on android ... smooth playback on Windows as how it plays when playing from a locally attached usb flash drive.

Windows is not Android. Single Thread Performance is way better on a Windows PC (not due windows being better, the opposite, but as the CPU who runs the thread is most likely a multi GHz intel / AMD CPU). Kodi's FileCache is filled by single thread and therefore limited by a single ARM-Core. Depending on Scheduler switching times, it might be too late, if someone in the middle synchronizes things due to too much App global interaction ... not better.

Most likely this gets 100% CPU load already on this thread. And yeah - the rest I told above ...

So, please change the settings if you want to test that and also check kodi's CPU load / cache values via the OSD. We have all the information there to optimize the settings.

Also comparison between wired network and wifi is not of much value, as wired network has very low handhsake time, has a very stable roundtrip time and therefore has very good throughput even with low chunks. For Wifi this is the opposite, combined with an Interrupt-Happy driver - and the way how kodi decides to read / when to read ...

I don't try to say that user has to go through that, as VLC seems to work out of the box on your box - I just tell you, that we have some design decisions inside kodi (from default queue sizes in MB or time) and 250 Mbit/s files are not the majority inside this equation, additionally we have to cope with very slow ARM devices on top ... where simply downloading 250 Mbit/s would kill the entire box or even box not capable to do that ...

So try it and see if it helps.

[NiKRuLeZ]

Did you change the settings I hinted to? 300 MB FileCache and Readfactor of 4? Combined with higher chunk size?
Does it make a difference?

I haven't tried that but just checked and the cache values for memorysize, read factor and chunk size are exactly the same on windows as they are on kodi on android ... smooth playback on Windows as how it plays when playing from a locally attached usb flash drive.

Windows is not Android. Single Thread Performance is way better on a Windows PC (not due windows being better, the opposite, but as the CPU who runs the thread is most likely a multi GHz intel / AMD CPU). Kodi's FileCache is filled by single thread and therefore limited by a single ARM-Core. Depending on Scheduler switching times, it might be too late, if someone in the middle synchronizes things due to too much App global interaction ... not better.

Most likely this gets 100% CPU load already on this thread. And yeah - the rest I told above ...

So, please change the settings if you want to test that and also check kodi's CPU load / cache values via the OSD. We have all the information there to optimize the settings.

Also comparison between wired network and wifi is not of much value, as wired network has very low handhsake time, has a very stable roundtrip time and therefore has very good throughput even with low chunks. For Wifi this is the opposite, combined with an Interrupt-Happy driver - and the way how kodi decides to read / when to read ...

I don't try to say that user has to go through that, as VLC seems to work out of the box on your box - I just tell you, that we have some design decisions inside kodi (from default queue sizes in MB or time) and 250 Mbit/s files are not the majority inside this equation, additionally we have to cope with very slow ARM devices on top ... where simply downloading 250 Mbit/s would kill the entire box or even box not capable to do that ...

So try it and see if it helps.

Thanks for that detailed advice, I'll give it a try.

Just to add further ... I've got a Samsung S23 256 GB device and I installed Kodi on there and played the 250mbps bitrate file over WebDAV (HTTP) and it plays flawlessly on there with the default cache settings!

[fritsch]

Yeah - that's what I meant ...

1x3.36 GHz Cortex-X3 & 2x2.8 GHz Cortex-A715 & 2x2.8 GHz Cortex-A710 & 3x2.0 GHz Cortex-A510

It most likely smokes your Shield CPU wise ... and that is exactly the CPU which gets overloaded in the filecache thread. We have seen this especially on FireTV devices, which - in the meantime on the CPU are as fast as the Shield, but still we pull it to 100% limites in the way we are downloading stuff. Would be good, if you could veryfix this with the debug osd. One thread on your Shield should be pinned to 100% always.

Still what I told before: More things are relevant for such bitrates, wifi drivers, the chunk read policy, etc. VLC might simple be able to read with much less CPU than we do, might not constantly while loop over the "does another chunk fit in" or dynamically grow the cache ...

So please do the tests and verification if you can.

[NiKRuLeZ]

Yeah - that's what I meant ...

1x3.36 GHz Cortex-X3 & 2x2.8 GHz Cortex-A715 & 2x2.8 GHz Cortex-A710 & 3x2.0 GHz Cortex-A510

It most likely smokes your Shield CPU wise ... and that is exactly the CPU which gets overloaded in the filecache thread. We have seen this especially on FireTV devices, which - in the meantime on the CPU are as fast as the Shield, but still we pull it to 100% limites in the way we are downloading stuff. Would be good, if you could veryfix this with the debug osd. One thread on your Shield should be pinned to 100% always.

Still what I told before: More things are relevant for such bitrates, wifi drivers, the chunk read policy, etc. VLC might simple be able to read with much less CPU than we do, might not constantly while loop over the "does another chunk fit in" or dynamically grow the cache ...

So please do the tests and verification if you can.

on the OSD, I see:

Screen resolution
System rendering speed
System memory usage

But no System CPU usage

Any ideas on how to get this to appear?

[fritsch]

adb shell with top?

What about the cache values? Staying high enough? Changed values make a difference?

[Hitcher]

Turn on debugging.