Yesterday I watched a 1080p movie and during action scenes the buffers and my bandwidth were obviously insufficient.
It would be nice to have some verbosity on the buffers during play, such as in the info screen under the ‘hamburger’ key on the remote (showing cpu etc.). This would greatly help identify and tackle bandwidth issues.
Also, after I paused the movie to let the buffers catch up, often audio could be seconds off sync and stay happily off sync, with good picture. Pausing a few times again would usually help. Is that a Vero or a Kodi issue?
You should see Buffering when the video playback is struggling
Pressing hamburger and OK should show you VQ and AQ stats: a low %age means the buffer isn’t full.
We’re improving buffering for videos. It is sometimes hard to work out the buffer size, because if it’s too large videos take an unnecessarily long time to start.
Are you using passthrough?
Can you upload a clip that causes the problem so I can reproduce it locally and fix it?
I have a similar issue. I am getting 200+ Mbps from my NAS with iperf3 over 5 GHz. I can even copy a file from the NAS to /dev/null on the Vero4k using scp with 145 Mbps. However, during playback of a Bluray rip over nfs the player can’t keep up. Using the stats info during playback it is clear that whenever the video bandwidth peaks above 60 Mbps the buffers drain and the video stalls. I increased the buffer to 500 MB but it simply never fills. When I pause the playback, the buffer fills and I can watch without problems until it is drained. Looking at the network stats Kodi is reading with 20-30 Mbps at best.
I did some timing with mounting the nfs share on the Vero4k and cp a large file to /dev/null, and I get 160 Mbps (120 Mbps with CIFS). So the network performance seems fine. Why can’t Kodi keep up though?
That’s good but you didn’t say how big the file is. It really needs to be BIG. [quote=“RichieB, post:4, topic:37113”]
I increased the buffer to 500 MB but it simply never fills.
[/quote]
Why not run a shell script that checks your buffer usage every second and saves it to a file? If you then graph it, you might see some kind of pattern occurring. The script could also ping at the same time. Perhaps you might see the pings suddenly slow down.
You also don’t say if you’re using NFS over TCP or UDP.
Edit: Expanded the post a bit now caffeine has kicked in.
Thanks! That solved the issue for me. My 4k Bluray rip now plays flawlessly! Now I also understand why the cheap Android media player I tried before had the same issue.
I used a 2GB file, should be plenty. It transferred in about 2 minutes indicating good enough network performance.
Excellent idea. How do I get the Kodi buffer usage from the command line?
When using fstab nfs it is using nfsv4 over TCP. I tried to force it to UDP to see if it makes a difference but I was not able to get this to work.
I did notice a slight improvement but it still stalls at the same spot.
Right now I turned off buffering alltogether which ironically seems to be rather promising.
I’m up for any testing and lab-bunny things
//EDIT: It does seem like I get steady 60-90mbps now. I wonder if a USB3.0 Gbit adapter could be useful. Now I know that USB doesnt do Gbit but it does do a bit more than 100mbps, so that’s a win right?
Okay, I’ll send you a PM shortly. Trying with the adapter would be interesting; but we should be able to get things to work with the integrated adapter
Yeah though USB2.0 by the spec should get me around 200mbps. The spec goes up to 460mbps throughput.
Now I add some USB protocol overhead to the thing, but even with huge 50% overhead I should still be at something between 150-200mbps. Actually anything more than 100 would solve my buffering issues.
The speed will depend on how much offloading the adapter does. @f0o I don’t remember if I asked; so forgive me, but have you confirmed that playing from a USB HDD does indeed solve the issue?
Sadly I dont have a USB-HDD around, only very shitty USB-Thumbdrives.
From comparisons between various cache settings and turning off cache at all it showed me that the shuttering happens almost at the same spot. In the case where cache was turned off, the NIC was peaking at 98mbps over the course of 3-5 seconds.
I think that particular spot must have a huge increase in bitrate which wouldnt fit into the buffers and also couldnt be streamed over 100mbps nics.
I ramped up an old laptop (Thinkpad x220) to have something to compare it and installed kodi over a debian 8, just by the books nothing fancy.
I then hooked up the NIC (Intel 82579LM using e1000e) to the same switch and tried watching it from there and it worked fine. The CPU was freaking out obviously.
At the shuttering-spot the laptop’s NIC was doing around 125mbps and it passed it fine.
Bursts like that, such as the HBO logo make it difficult to predict (and buffer accordingly).
Does this high bitrate portion of the clip occur early on? I believe if you set the buffer high enough it would fill it; but might need to pause it for a few sec as soon as you press play.
For this particular case it happens after 4 minutes into the series.
The camera man is very epileptic so they’re many cuts with little to no recyclable pixels.
Right now I’ve set 500MiB as cache size, it takes about 2 seconds from pressing play to seeing content which is fine for me. With this setting it stalls only once and catches up rather quickly afterwards.
I’m tempted to go higher but I think I’ll be in unstable waters soon
