I played Avatar way of water from beginning to end with no desync, stutters or crashes. A big detail I realize I’ve neglected to mention is that playing movies from beginning to end in this fashion is typically smooth. It’s when the movie is paused, seeked, or not played from the beginning that the problems begin to crop up for me.
I get this as well occasionally with 3D mvc.
Hi
There are a couple of desynchronisation issues we are aware of.
We are working on them and it’s independent of 3D MVC playback.
With regards to the crashing and locking up, can you reproduce it with playback on a 2D TV? The reason I ask is that 3D resources (time) are limited right now. Our resident expert of 3D @tanio99 is stretched thin and my access to 3D equipment is limited at the moment.
If it can be reproduced on a non 3D display I can look further.
Cheers
Sam
Great, lets hope you can get to the bottom of it.
It will be a difficult adventure since the V hard locks and I get no debugging info out. So need to use try and error to see what change has an influence and what not. Does that issue really only happen when playing 3D MVC content?
I’m not sure I’ll have to test further - do you only get it with MVC?
Until now: yes.
I also sometimes see MVC buffering when seeking which I don’t see on any other files.
There are many reasons why you get buffering. For instance, networking issues, or its more likely to get buffering when playing ISOs over the network. It’s also possible that the decoder is temporarily running out of resources which can also trigger A/V or lipsync issues. Or simply “bad timing” in Kodi …
I don’t see the buffering issue when playing anything other than MVC so I guess its related to that. I don’t seem to get any A/V sync issues though - maybe because I’m bitstreaming rather than Kodi doing the decoding?
Kodi doesn’t do any decoding. Decoding is done in hardware (kernel). And whatever your source is, it ends up at the hardware MVC decoder in the kernel.
I played a 2D blu-ray .mkv file I created from a disk via dvdfab, skipped a few times and experienced the same crashing I’ve seen with 3D content, proving the likely cluprit is due to the file size, not whether it is 3D or not. In the past I would usually compress 2D content while keeping 3D large, so I assumed the problem was exclusively with 3D, which may not be the case in reality.
logs in case you want to see, though they might not show much due to the hard crashing:
https://paste.osmc.tv/unapecedut