I have those too. But not only limited to HDR content. When I skip forward or back a few times, screen turns green everytime I play videos from then on.
I don’t have that file on my system. How can I then provide you with some useful logs for the problem?
Just issue that command here:
cat /sys/class/video/dump_reg
and then upload the logs. That ‘dump_reg’ isn’t a file per se, it’s a node which gets created when the Vero boots.
Thing is empty after the green screen appears.
That’s intended. The output is directly written to the kernel log. So I you post the log the output will be part of it.
Ah, got it. Log is here: https://paste.osmc.tv/ovetoyaqel. Might be a bit messy cause I spammed that cat command quite a few times.
That’s ok. The only important thing is that you spammed it while you had that green screen. Can you reboot and then play that movie again? I hope you don’t get that green screen then. And while it is playing issue that command again and post the logs. That way I can compare the ouput of the two cases (one time where it failed and one time where it succeeded).
@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).
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.
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.
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.
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!
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.
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