I was running one of the Feb test builds, and with some tinkering the chapter skip playback on 4k mkv’s was fine. I’ve monitored buffering by pulling up playback stats and found that even with 4k, after a short period the forward buffer was at the 180MB level. Today I installed the official March release and I now find that after a chapter skip, the buffer is sometimes not recovering, it’s down at the low kb level. Have only tried a couple of 4k mkv’s so far. Will do some more testing and come back with a log, but wanted to flag that there may be an issue with chapter skipping.
Which test build were you using?
There haven’t been changes to buffering behaviour in this update but there are some planned
I was running a test build that had broken UHD chapter-skipping completely, but by changing the value of a system parameter (I forget which, it’s in the thread), chapter-skipping playback was recovered. To be fair, I had not tested that build extensively so it may be the issue I’ve seen today has been lurking around.
In case it’s to do with variation in my network I have tested and re-tested several titles. Some are fine, but with Start Trek 2009 I can induce a reproducible playback stutter by starting playback from the beginning, skipping to chapter 3, and then playing until the bar fight breaks out. At this point, lip-sync and juddering become an issue, as I think the buffer has not reestablished itself. Yet in other circumstances the Vero quickly reestablishes its buffer. Not sure if this log helps.
The dynamic_buffer_margin parameter was adjusted for HEVC. You could try adjusting that. This resolved hangs when playing clips such as John Wick 2 and Serenity.
You seem to be using NFS via Kodi which won’t have the same level of readahead as say, an fstab based mount.
Yes, but for some titles a chapter skip has buffer recovery to the ~180MB level quite quickly, whereas in this scene the buffer almost flat-lines. So the Vero/Kodi-NFS combo can perform well (and for me has been performing well until now). I guess we can see if this is a general issue, e.g. if others can test the same title. I’m ok to go back to an older version of OSMC if that helps with testing.
If you want to buffer and skip ahead in 4K content, you should be using an fstab mount
You can adjust the buffer margin to see if it helps. This is the only thing that has changed
Can you offer any suggestions re values to try?
What is the %difference in bandwidth between Kodi-mounted NFS and fstab? I just monitored the network load on my Synology NAS, and with the problem chapter it’s pushing a steady 11MB/s to the Vero, peaking at 12.9. How much better than that is fstab? I wonder if starting a scene via chapter skip with such a high steady rate is the real issue here?
Switching to fstab would be quite a pain as I would need to sort out path substitution for my central database, and generally have more library management hassle.
So if there are buffer improvements on the way, I’ll wait for those.
As my 4K mkv’s are not currently indexed in my central SQL library, I figured I’d try out an fstab mount for the nfs share. But I have an odd problem: I can mount, initiate playback, and then the Kodi Remote app on my iPad loses connection with the Vero, and then after a while it comes back. I’ve never experienced this behaviour before, but happens with each file I play via the fstab mount, and makes the iPad app a bit unusable. Here is the line I have added to my /etc/fstab file, and in /mnt I’ve created a 4K_fstab directory.
IP:/volume1/video/4K /mnt/4K_fstab nfs noauto,x-systemd.automount 0 0
CEC control with my TV remote is fine, and as soon as I stop playback with my TV remote, the iPad app resumes its connection as well. iPad working perfectly with Kodi-mounted nfs share.
This has fixed the problem chapter in Star Trek. The playback stats show a completely different profile for buffer recovery compared to the Kodi-mounted version. For most chapter skips the Kodi mount is fine, but on this one it choked. However, as per post above, playback from the fstab mount is breaking the connection with my iPad.
Regarding broken connection with my iPad Kodi remote app when initiating playback via fstab source, here is a log in case helpful.
I moved the mount to my /home/osmc folder as that seemed a better place to have it, but fstab playback still breaks the iPad connection. The connection resumes the moment playback is stopped via my TV remote, and nothing else so far in my use of OSMC has created this kind of problem.
You need to do some network testing. Sound like your network is getting saturated when skipping.
Moving the actual mount point will make no difference.
You have a Kodi-based NFS link to the 4K videos directory:
and an fstab entry to the same source:
10.0.1.216:/volume1/video/4K /home/osmc/4K_fstab nfs noauto,x-systemd.automount 0 0
You should remove the Kodi source.
Which post are you replying to? The chapter skip issue (which was rare), has been fixed by fstab mounting. But now fstab has broken the link to my iPad. It breaks instantly, but also resumes the moment playback is stopped. No other sources induce this behaviour.
Already tried that, made no difference.
Well, that’s not what the log shows. When did you try it? Did you reboot the Vero4K having made the change?
Having NFS client access simultaneously via libnfs (Kodi) and the kernel (fstab) seems like it might be a recipe for complications.
I know that’s not what the log shows. I’ve tried it with and without the Kodi-mounted NFS source being active. The log happened to be submitted with the Kodi-mount in place. I can provide another log if that helps.
New log, clean reboot, no Kodi mount of the 4K folder, fstab only. iPad remote breaks/resumes on start/stop of fstab content.
A few questions:
Is the iPad being used to view video material, or just being used as a remote control?
Are you trying to use the IPad immediately after you start a video on the Vero4K? In other words, are you allowing the Vero4K time to fill its video cache before using the IPad? It’s very possible that it will saturate the connection while this is happening - and the higher the bitrate of the video, the longer this will take.
Both your logs are showing some MySQL errors that could indicate network saturation:
18:42:26.899 T:3864179456 ERROR: Unable to open database: MyVideos107 (Lost connection to MySQL server at 'reading authorization packet', system error: 2 "No such file or directory") 18:42:26.899 T:3736072960 ERROR: Unable to open database: MyVideos107 (Lost connection to MySQL server at 'reading authorization packet', system error: 0 "Internal error/check (Not system error)") 18:42:26.901 T:4078662400 ERROR: Previous line repeats 4 times.
just as a remote.
You may be on to something here. What’s happening seems to be an extreme lag effect, which is not present with Kodi-mounted nfs. After initiating playback, eventually playback responds to a remote request, but after that request, it will wait for quite a while before it responds to the next remote request. So even if I wait a while, the remote is still pretty unusable. With Kodi-mounted NFS, I can use the remote continuously and it’s always responsive, right from the start.
I’ve only looked at fstab because so far I have found one chapter skip event in my modest 4K library that caused Kodi to choke, so overall Kodi mounting is perfectly fine. My network infrastructure is very robust, it severs multiple Kodi clients simultaneously without breaking sweat. At present fstab is not essential for me, but if I find that changes, it would be nice to get the iPad remote working.
In this case the more efficient fstab read-ahead might be working against you.
But it might also be possible to open a second interface on wifi that you use for your iPad app. OSMC seems to be able to support both wifi and wired simultaneously if you have this line in
(it’s normally set to internet,wifi). It certainly works on my Pi3.