@grahamh and @sam_nazarko, I realise y’all have been pretty busy with Buster issues the past few weeks, but might you have time to look at this again at some point? This was the thing of adding an option in the UI to force “weave” deinterlacing during playback (to bring the Vero in line with the Pi). As previously discussed, it’s now working very nicely for VC-1 videos, but there’s still a need for it on MPEG2 (e.g. DVD remuxes) and also h.264 (e.g. TV broadcasts in Europe).
1 Like
I’d echo the request above from @angry.sardine to add a “force-weave” option for mpeg2 and h264.
Since this feature became available for VC-1, the picture quality I can now get out of the Vero for the first Matt Smith Dr Who series on bluray is outstanding, a vast improvement on 3.14. But as a large amount of made-for-TV drama in my collection is 50i-progressive, and much of it isn’t VC-1, it would be great if the Vero could be levelled up with the Pi in this department, and able to render a completely clean 25p output. I appreciate that this could be difficult or even not possible, but if it could stick around on the development roadmap that would be something.
3 Likes
If it was as easy as finding the bit in the code where it said ‘weave’ and turning it on it would be done by now. But there’s no such switch.
We haven’t given up.
3 Likes
I think only two people on the forum have even raised this, so it says something for the OSMC team that you’re working on it. Not sure I can think of another platform that has this quality of support.
1 Like
I agree! 
Although, to be fair, I think Sam & co. have always felt quite strongly that the Vero 4K should offer reference-quality video and audio - a very laudable goal!
1 Like
Just a quick update: AMLogic are now able to reproduce the 3D issues when playing MVC content such as Gravity.
We are discussing getting it resolved. It is going to take some time to investigate and involves getting the VSLI team involved.
13 Likes
That’s very good news indeed, but if it gets solved even better :-). Thank you for the continuous support to get this working perfectly.
By far the best support you can find on a product of that kind nowadays. Period.
Very promising news Sam, thanks for sharing.
So the green video on play has happened to me again. Stopped it, torned on debug logging, then run the cat command, then started the video, run cat again, then grabbed logs, here they are:
https://paste.osmc.tv/azejikedef
And then rebooted with debug logs still on, then started the same videos for comparison (no green video after), dumped regs and grabbed logs again:
https://paste.osmc.tv/novivofado
I hope I did not forget anything this time and you have all you need to compare and figure out what causes the green video playback…
-
we need to see the output from cat /sys/class/dump_reg. Please post it here.(my bad - output is printed to the logs.) - You issued
grab-logs -a. It should begrab-logs -A
Thanks for sticking with it!
unfortunately, the logs you’ve posted above do neither contain the kodi log files nor the kernel logs 
What about the logs I posted earlier on this issue. Were they of any use?
@tanio99 @grahamh can reproduce the green screen. What do you need? Can I upload logs via My OSMC add-on? ssh in and use cat? Cat while screen is green and cat while screen is on normal playback?
Do we send also the output of …
cat /sys/class/video/dump_reg
… along with the log?
cat command will just display the contents of dump_reg right? Or will it append to log?
Can you reproduce it easily?
That cat command doesn’t output anything. It writes its output to the kernel log. So we need the kernel and kodi logs. The Kodi logs can tell us what you did, and we can use them to correlate with the kernel logs. So just send us the logs via MyOSMC or you can also use the grab-logs -A command.
Exactly. We want to compare the logs to find out what differs.
Regarding that ‘green screen’ issue:
we’ve already got some logs. They were helpful, and we were able to exclude some of the usual suspects. But we still don’t know what’s causing that green screen. It could help to get some more logs.
But the best thing would be if someone out there could find out how that issue could be reproduced.
When I encounteted this issue with the usb test builds I was able to readily reproduce by simply skipping forward a few times in the file. More specifically using a remote button which I’ve mapped to skip forward 250 secs i.e. Seek(250).
I’ll pm you details for the uhd hevc file i was having issues with.
1 Like
thanks, @tanio99!
They’re very easy to reproduce for me. I just need to skip forward or back a couple of times. And it happens to a lot of the videos I watch. I’ll take a swing at the logs today.
Ok, good to know. I think I’ll start skipping around today 
.
1 Like