I’m getting occasional jerky playback while watching an NTSC DVD remux of Star Trek: Voyager in software mode. I tried capturing some logs, but after the necessary double reboot, playback was mostly smooth, so there may not be anything useful in here:
https://paste.osmc.tv/pehucuquro
I suspect it’s going to be a pain to reproduce this. 
Happenes again. Left my Vero 4k on overnight with TV off. Switched on TV and no display again. Reboot doesn’t work but @tanio99 's advice to leave it on for a longer time worked.
My question: Anyone else experiencing this? Or is it just me?
I’m rather busy this week. I’ll come back to you next week.
Just bumping this, 4.9 Buster still has noticeable VC-1 video stutter. My test material is direct mkv import from blu-ray 1080/50i source. The stutter is not there on 3.14.
Also, I still find that a Pi with hardware playback and user-selected disabling of deinterlacing beats the Vero for resolution on native progressive material that has interlaced encoding.
Those that reported issues with LIRC / IR remotes should be able to update again and find the issue resolved.
Tested on Buster… working thx 
Tested on Vero 4K+ and working. Thanks!
I can confirm LIRC is now fixed on mine as well. Thanks!
I have found a problem with 3D Frame Packed output and 3D iso files that are encoded with VC-1 3D codec. I have the 3D Version of Clash of the Titans, and on playback with this upgrade, the 3d movies starts out okay, but any further command (such as chapter skip or restarting the movie) is executed only after a 40 to 50 second delay. Other NON-VC-1 3D files play fine. Has anyone else seen this problem?
Logs available at https://paste.osmc.tv/ihuqohupah
I’ve seen a very long pause after skipping on both “Avatar” and “Valerian and the City of a Thousand Planets”, but only when playing from an ISO, not from an MKV. Not sure if that’s the same issue.
I have those two movies also in 3D iso files and will test them out when I get the time tomorrow morning.
Just watched The Walk 3D and it was perfect. I have to say this is the best the vero4k has worked for me. Everything seems snappier. Especialy with the menus. So far so good.
Yes, it’s the same issue. I’ve already had a look at that problem. It’s not easy to solve and will need a bigger refactoring of how 3D ISOs are being played.
The problem is that currently the info about where a frame of the second eye stream can be found isn’t used. So if you skip then the stream has to be sequentially read until the correct location was found. And that takes time.
IIRC @angry.sardine has already verified that it doesn’t work on the Pi, too.
When zapping backwards the video decoder seems to crash and the video is replaced with green (fullscreen). You can stop the video and the gui still works but when you play a video the you only get the green screen again. Only a reboot brings things back to normal.
Until know I can reproduce it with two HDR UHD MKV files (created with 40.0). If this isn’t a known issue I can upload full debug logs later today.
I’ve been having some audio issues for the past few weeks: Dolby Atmos now plays back as DolbyTrueHD and multi-channel .DSF files have begun stuttering. I’ve made no changes to my settings, and all other formats are playing back as they should. I was hoping the latest update would have fixed it, but that’s not the case. Any ideas?
What version did you have when you first noticed the problems? Kodi 18.7, stretch I guess, but 4.9 or 3.14?
Logs would be useful.
Hi Graham,
Here’s the log: https://paste.osmc.tv/nehavovino
As it turned out, the Atmos was an AVR issue - my bad!
The .DSF issue persists, though… I’m seeing pretty high CPU usage (170 - 250%), if that provides a clue.
I’m on the 4.9 kernel. The problem started well after I updated to 18.7, so I’m not entirely who the culprit is!
TIA - I really appreciate your help!
The Vero can’t cope with DSD files, I would suggest you convert them to flacs, I did that with all and no problems since then.
The only issue I still have is with multi channel flacs in the summer, that takes alot of cpu as well and thus temperature hitting the max temp allowed.
It can. Or rather, it could
It’s been possible since 18.0
The file in the log played back perfectly until about a month ago. AFAIK, Kodi transcodes the DSD-stream to PCM, meaning there is no real advantage to the DSD/DSF formats, and trancoding could be an option, but it’s a lot of work and shouldn’t be nescessary if everything was working as it should…