I have Vontar X96Max_Plus2 (s905x3) - works well!
There was a problem with the last nightly build, which will be fixed tomorrow.
I moved the images in the archive folder back to the root folder.
Thank you, what’s the problem? I have a problem with going to sleep (from the menu), the device turns off and turns on only by disconnecting and turning on the power.
That’s true for HDR->SDR - but for SDR->HDR it’s possible to do a proper conversion.
The SDR (BT.1886) EOTF fits within the HDR10 (ST.2084) EOTF - and if you are also including Rec 2020 gamut for HDR and Rec 709 for SDR, then the Rec 709 gamut fits fully within the Rec 2020 gamut - so you can map Rec 709 to Rec 2020 without having to resort to tonemapping (because there is no need to clip either the EOTF or the colour space - the SDR content fits well within the HDR system).
HOWEVER - you do have decisions to make about how you do this and whether you make the SDR content remain looking SDR in HDR. For PQ HDR10 you can map 100% SDR peak white to 100nits (as per SDR specs) or you can use an algorithm to make the SDR look like fake HDR and map the brighter bits into the >100nit HDR range…
Similarly you can map the 100%R, 100%G, 100%B Rec 709 to the Rec 709 R,G and B primaries within the Rec 2020 gamut, keeping the Rec 709 looking like Rec 709, or you can widen the gamut, mapping the primaries to new values, and distorting the colour of the Rec 709 colour, making it look like fake Rec 2020 colour (but distorting it)
Whether the SDR->HDR approach taken by AMLogic is accurate 'Display Rec 709 SDR as Rec 709 SDR within a Rec 2020 HDR EOTF and gamut), or ‘Turn Rec 709 into fake HDR Rec 2020 looking content’ is a separate matter.
However it is not correct to say that you can’t display Rec 709 SDR accurately within a Rec 2020 HDR signal - you can (particularly if the Rec 709 source is 8-bit)
Of course the reverse conversion (HDR Rec 2020 to SDR Rec 709) is a much more complex process as neither the PQ HDR 10 EOTF nor the Rec 2020 gamut can be fully contained within a BT.1886 SDR EOTF or a Rec 709 gamut.
It was just a problem with the build server and not with the images. So your problem hasn’t anything to do with it.
I am still having issues with recent updates preventing power off from working, resulting in a reboot instead (A95X Max S905X2 NG builds).
I had thought that it was something to do with my TV tuner but I was incorrect.
After testing each update following 20200423 (20200430,20200503,20200506,0200509,20200513,20200520) I was unable to power off the box
So after some digging into the contents of updates and fresh install images I noted that the device tree g12a_s905x2_4g_1gbit.dtb was 2 bytes larger in 20200430 than it was in 20200423.
So I wrote a fresh install to an SD card using 20200430 as the reference, removed any USB devices from the box (save for a wirless mouse USB dongle), booted from it, making no changes and hit the power off system option, which resulted in a reboot.
I then wrote another fresh install to an SD card using 20200430 as the reference again but this time used the device tree file from 20200423 for dtb.img instead, booting from it and hit the power off system option, which resulted in a correct power off.
To further verify things I wrote another fresh install to an SD card using 20200503 and followed the same exact steps that I did for 20200430, with exactly the same results each time.
I also noted that the g12a_s905x2_4g_1gbit.dtb in 20200503 was a different size again from the previous two (20200423 - 67,580b, 20200430 - 67,582b, 20200503 - 67,578b)
So the evidence does seem to point to the device tree being the issue, the last working one being that from 20200423.
Please also do a dmesg log:
echo 8 > /proc/sys/kernel/printk
And then:
systemctl poweroff or systemctl suspend or systemctl reboot
Maybe it shows a kernel crash.
If nothing is visible may a UART log of the boot loader is needed.
Hi, I just installed the latest nightly and I see strange behavior when booting coreelec. After the Hardkernel logo, the purple screen appears, followed by the linux code, then the coreelec screen, which before the final loading of coreelec is distorted for a second. Screenshots below.
Can anyone else confirm that the screensaver addon ‘Turn Off’ is uanble to turn off the TV via CEC when a movie is paused?
Thanks for the nice descriptive report of the issue.
It is a known issue, and a fix for it will probably make it’s way into the nightly builds sometime in the next couple days.
Hi.
I’ve attached a short sample file (~45Mb, MP4, MPEG-4 Simple@L1) which have some video decoding problems when hardware acceleration enabled. Random color squares flickering or something, idk…
On my TX3 s905x3 box im using latest nightly build (20200523) but i have the same issue on released 9.2.2-ng. But 'cos its finalized i decided to report this here… 
Thx in advance.
PS. Have no any problems with this file on x96mini s905w @ CoreELEC 9.2.1 with hardware acceleration enabled tho.
sample_mp4, not found 404
I played your sample (it took ages to download 
on my N2. With hardware acceleration there is no picture at all, only “white snow”, as on analog TV channel without signal.
Without hardware acceleration it works OK. I guess the reason is the codec used: mp4v-20 which is not supported in hardware decoder.
If you want I can upload it to some cloud drive.
Do you know what is the situation regarding used mp4v-20 codec in that video:
Video
ID : 1
Format : MPEG-4 Visual
Format profile : Simple@L1
Format settings, BVOP : No
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : mp4v-20
Thank you, I got the sample already. Will see what I can find.
Don’t write PMs to team members, post in a relevant thread or open a new one if there is none.
Thx for confirmation and sorry for a shitty filehosting used for a sample. 
I guess too that its something wrong with codec used but the point is its played without any issues with hardware acceleration enabled on s905w@CoreELEC 9.2.1 as well as on s905x3@Android.
So looks like its kinda regression in CoreELEC-ng branch…
For users who use dvb part(on -NG builds): please test latest nightly to check if no regression to compare with previous nightly or 9.2.2 stable.
For other users: latest nightly include Kodi 18.7 and new kernel changes. Feel free to inform if you see some regression. It’s better to do it now than after next release 
1 Like