Hi Tom!
“Framerate to always” not yet, but i can test it at home and post a screen of my System and Playback Settings in Kodi!
But Wuschel_Wuschel test to play a file from an usb stick and haven´t frame skipping problems with it, only when it plays over the network, so i think that the vero has an issue with that?!
My first test for today: https://paste.osmc.tv/juketehesi - 1080p24 screen setting enabled and framerate adjustment set to off. 107 skips, 0 drops. Skips happened randomly across the video, but a bunch right at the end of playback (about 30). Played back with normal SMB share, so that only one setting was changed compared to the original state.
Before having the player setting set to adjust framerate at start/stop (see below), I had it set to always and then I first noticed the problem. So, it definitely seems to happen no matter what framerate adjustment setting is enabled…
My video player settings currently (when not testing stuff):
My screen settings under settings/system:
What I’m going to test now: first I’ll have a test with nfs sharing. My NAS has a public nfs share that I’ll use - to setup everything for a priviliged nfs share, I’d have to dig deeper into how-tos and stuff, so I’ll keep it simple. Afterwards I can think of one last possibility that I could test: disable passthrough under audio settings while streaming from a simple SMB share from my NAS.
Will report then…
I have the same Kodi Settings then Wuschel_Wuschel…
Test with my unpriviliged nfs share: https://paste.osmc.tv/imemipafut - Only skips and drops occured at the beginning and end of the playback. No skips or drops during playback! Same behaviour as it was playing back from USB drive.
All settings as described in post #43. I added the nfs path of my NAS as a nfs source and played it right through the file manager. So, didn’t do any mounting via fstab…
So, I’d say, there’s a problem with SMB shares no matter whether added as a normal kodi source or mounted via fstab. NFS seems to solve the problem, but it shouldn’t be this way. @MikeDelta Hope, you can confirm what I found out.
I’ll set up priviliged, proper nfs shares now and test again, just to be sure.
Ok, thanks for this important news - i will to try nfs at home, have to check that the Emby Server, which is my Backend Database for kodi does full support for nfs…
Bad news… The test before seems to have been coincidence: https://paste.osmc.tv/monabojemo - 130 random skips (of which 9 happened at the beginning of playback and 35 happened at the end), 1 drop. So, nfs doesn’t seem to solve the problem either.
My last test I can perform, will be disabling audio passthrough and accessing the file via SMB again. Let’s see.
Any other ideas what I could test or even what the problem could be at this point, @sam_nazarko, @Tom_Doyle?
Disabling passthrough looks promising so far on this test run. I’ve always wondered, why the fps always fluctuate between about 8fps and the maximum of 24.4fps during playback. With passthrough turned off, the framerate fluctuates between 23.4 and 24.4fps so far, meaning it sticks to the 23.967fps of my file. I’ll wait for the file to have played till the end, but so far, no skips during playback… And this is all via SMB.
I’ll repeat the test via nfs and USB drive afterwards, if this test turns out to be without random skips or drops.
This is very strange and for test purposes it may be help for finding the reason of the issue, later it´s not an option, without passthrough we have no hd audio… so when i´m at home later this day the question is what i can do to help so nfs doesn´t work…
But if it’s related to passthrough when streaming from a network source, this issue could maybe be fixed.
You’re right though. For me, audio passthrough including the HD formats DD+, Dolby TrueHD, Dolby Atmos, DTS-HD and DTS:X was the single reason to upgrade from my RPi3. I’m not using 4k right now… But, let’s wait for the tests to be finished. 
First test run via SMB without passthrough enabled: https://paste.osmc.tv/yokifosaja
Second test run via NFS without passthrough enabled: https://paste.osmc.tv/xubafuzuwi
Third test run via USB drive without passthrough enabled: https://paste.osmc.tv/sohiqebupe
Result of all this: The skips have nothing to do with audio settings, they have nothing to do with network or USB drive playback and they have nothing to do with the way network shares are accessed or mounted. The problem definitely lies within the Vero 4k itself and seems to be tied to the framerate fluctuating quite a lot during playback every now and then. As long as the framerate stays within the “normal” fluctuation between 23.4fps and 24.4fps for a 23.976fps file, everything seems to go fine and without skips/drops.
For now, I can’t do any more testing after two nearly straight days of testing…
Please fix this issue soon as it affects the core abilities of the device itself! I hope, my logs can be of help. And please give some feedback on whether there are already ideas what could be wrong, @sam_nazarko, @Tom_Doyle.
Hi,
What was adjust frame rate set to during these tests?
Thanks Tom.
It was set to framerate adjustment at start/stop.
As I said… all settings were original (see post #43) except the ones I had to change for every single test. Framerate adjustment set to off didn’t change anything (also see post #43) and always was the setting when I first noticed the problem. So, it doesn’t have to do anything with framerate adjustment. Any idea why the Vero 4k has such a fluctuating framerate every now and then during playback? I guess, that would be the problem…
Hi,
To be honest I’m not sure whats going on here. I’ve had no issues playing anything on my vero4k, (including 1080p). My setup vero4k connected straight to tv, for audio no amp. adjust rate set to always, passthrough disabled and the interface at 50 hz. Like I say I’ve not seen any issues. You’ve flagged Sam on your last results, so hopefully he will have some insight.
Regards Tom.
My setup is as follows:
Vero 4k > Denon AVR-X4300H > Panasonic TX-P42STW50
As my problems show up with USB as well as network playback, it should tell us that the network definitely is no issue.
It’s very strange that @MikeDelta and me seem to have this issue, but you don’t… Maybe it is some setting, but which?
Hi,
my settings are defaults, except I’ve changed adjust frame rate to always.
Would interesting to know, just for testing. If you can reproduce the issue, if you bypass the AVR and connect the vero4k directly to your TV.
Thanks Tom.
I´m at home now, cancel the nfs binding so it doesn´t resolve the issue - if is anything i can do please let me know but i think we need the help from @sam_nazarko - at the moment i must use the Q10 for watching my media… 
Thanks a lot @Chillbo for this excessive testing!
Test again the same file from yesterday (yesterday via smb / fstab, now via smb / kodi) and noticed 60 Frame Skips in the first 6 minutes, then i break the playback!
Hi,
20:24:50.060 T:4107915264 NOTICE: Display resolution ADJUST : 1920x1080 @ 50.00 - Full Screen (22) (weight: 0.000)
20:24:50.060 T:3686790128 NOTICE: EMBY.database -> opened: /home/osmc/.kodi/userdata/Database/emby.db - 3612431952
20:24:50.279 T:4107915264 NOTICE: VideoPlayer: OnLostDisplay received
This is the first reference the frame rate adjusting back to 50 fps, and I can see about 5 others; all around the time emby.db is accessed.
Is it possible to temporally disable the emby plugin and test playback again?
Thanks Tom.
Hi Tom!
I test the same file yesterday with smb via fstab and without the emby plugin, see post 26 - many frame skips occurs…
Hi,
Apologies I missed that. In that log I see:
20:39:53.850 T:4115304448 NOTICE: Display resolution ADJUST : 1920x1080 @ 24.00 - Full Screen (23) (weight: 0.001)
20:39:53.850 T:3696751600 NOTICE: EMBY.kodimonitor -> Could not retrieve item Id
20:39:54.035 T:4115304448 NOTICE: VideoPlayer: OnLostDisplay received
an issue with emby.kodimonitor, appears to causing OnLostDisplay to be sent.
Also:
20:39:53.561 T:3696751600 NOTICE: EMBY.database -> opened: /home/osmc/.kodi/userdata/Database/emby.db - 3570393696
Which ever plugin which is accessing emby,db was still active.
Thanks Tom.