Im not sure if reboot update can give default boot to ce on sd card, will try later!
Plugin method log, bit set correct to 8-bit: removed
Direct URL method, bit set incorrect to 12-bit:
removed
Confirmed by running the below during playback
cat /sys/devices/virtual/amhdmitx/amhdmitx0/config
Attention, plex tokens in log
Edit: @Portisch I can’t post more than 3 replies because I’m a new user (wtf), so editing this post for now:
Is there any way to find out what causes the delay? Could I optimize the playback logic of PM4K so that the timing issue goes away?
We listen to the player events, and start a monitor thread. I don’t know how/why that would affect the player, though, honestly; it shouldn’t.
Edit 2: Hmm no, this shouldn’t be an issue that can be affected by other non-player-related threads. We (PM4K) don’t change anything with regards to the media file, so it should detect DV.
I fetched it and removed the links.
@liquidion did you also try to set GUI to 1080p?
Same issue? I don’t see any difference in kodi.log.
If yes make such log for each playback again:
dmesg -c
echo 3 > /sys/module/amdolby_vision/parameters/debug_dolby
-> start playback in kodi and stop it again after 2-3s
dmesg | paste
1 Like
An idea (dunno if stupid/naïve):
As a workaround, could the video stream handler force <setting id="coreelec.amlogic.limitcd">1</setting> when it detects a DV stream, as DV is always tunnelled in 8-bit RBG anyway? (And revert to what it is actually set to afterwards, of course.)
When GUI-scaling is disabled, playing DV-files half of the screen stays blank, when scaling is enabled it´s working fine. Should be an easy fix?
1 Like
The easy fix is to keep scaling on as there is no benefit to having it off.
Well text and everything is just sharper. I can see it. 
1 Like
I’ve verified that setting my GUI to 1080p has no impact. In both of the below tests, my GUI is 2160p @ 60hz.
The incorrect 12-bit case:
https://paste.coreelec.org/71H2k7
And the correct 8-bit case with plugin handler:
https://paste.coreelec.org/RDJYJq
Verified the color bit during playback for each of the above tests.
It’s a knowing timing issue. Not sure yet how to solve it…
When it works:
kernel knows it’s DV, set display mode 0.5s after that → 8bit
When it does not work:
kernel does not know it’s DV, set display mode, kernel knows 0.5s after it’s DV → to late → 12bit
1 Like
Is RPU the part that affects the dynamic brightness? I was thinking that if devices mentioned in this thread work but others are still mostly DoVi wise broken, if I should wait for the fixes to end to -ne or just get an -ng supported box. My own DoVi encodes for media player use are P8, I would rarely need the FEL support.
Testing on a Homatics, I couldn’t see any difference with various clips. DoVi mode is switched on in the TV but looks more or less like fallback HDR10 
Yes the RPU is the dynamic meta data - this allows better (dynamic) tone mapping to the capabilities of the display device (TV) on a frame by frame or scene by scene basis rather than fixed for the complete film to one (static) tone mapping.
Note: This is similar though not the same as the capabilities of the rival standard: HDR10+ Metadata.
The RPU in your P8 encodes - presuming the P8 is sourced from a P7 - will be identical to the P7.
As you have seen well produced HDR10 will look good already, to a point it may not be obvious the difference - if you want to see the difference more clearly I would say get the Spears & Munsil Benchmark Discs to compare, if there is no difference that you like then it is all really moot - just go with what you have.
If though you then want to have P7 FEL where the RPU is passed to and processed at the TV, then only the devices here do that (outside of BluRay Players) and are -ng devices.
Bottom line it needs a combination of:
-
Software
OpenSource drivers available for the hardware (amlogic linux)
DoVi linux module available
CoreELEC to bring it all together with a Kodi front end and fix issues on the OpenSource side. -
Hardware
Two HEVC hardware decoders
DoVi Licence enabled
For all this to work.
Even given all the right ingredients it does not just then happen by magic it needs lots of effort to then make it all work together; maybe tomorrow a -ne device will be ready that does that and the software all ironed out - maybe that happens in another 6 months, I am not part of the CoreELEC team but the way I see it is this is a open source project - there is no planned product road map to be releasing such a device, it arrives when it does when all the pre-requisites are ready and the software has been built to make it all work together.
My advice is - if sticking with P8 then you have a lot of choice for the player, it really depends if you place any value on P7 FEL.
FYI - there are P7 FEL out there with very high bitrates in the FEL layer talking up a large proportion of the UHD 100 GB available, not all the benefit of that can be unlocked with current displays but there certainly are current benefits and as displays evolve more to come.
1 Like
Thank you for the compehensive answer, highly appreciated!
One more question regarding performance, I asked earlier about 4K AV1 software decoding, which was not feasible with these boxes. Has there been any tests with 1440p (2560x1440)? In AV1, I guess tiling will also help with multithreaded decoding.
Created another test build - based on latest CE21
new parameter to clear out the colorimetry flag for DoVi tv-led.
Edit:
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
Edit:
echo N > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
This overrides the existing bt2020 paramerter, can use combinations of both to check all three flag settings:
BT.2020nc
BT.709
(No Flag) - will say Default in Kodi overlay.
1 Like
would it be possible (and hopefully not too much of work) to integrate a menu setting to set this flag fixed (maybe at the same place where the option for player led/tv led is)?
Thank you for this.
I have installed your tar file upon my CE21 latest nightly.
Then I have used both your ssh commands (one at time) and no difference with the CE21 nightly.is observed. BT709 flag is always there in any combinations of your commands. Both Panasonic info and CE21 info show BT709 flag.
Did late last night (my time) and put a typo in the command - try the below (should be parameters with an s)
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
As well as the screen can also use the following command line to see the current AVI Info Frame settings in detail, along side other Info Frames / Packets:
cat /sys/kernel/debug/amhdmitx/hdmi_pkt
There it will say:
colorimetry: disable
I think it is doable, but not too sure on the benefit, probably not something I will look at unless find myself with lots of free time, and done the other things I want to get done
Others please feel free to add.
FYI, I will likely submit a PR for the command line parameter to get this into the mainline later on.
it works perfectly. Applying the first command Panasonic info no longer displays BT709, no flag as the ATV 4k and the sony x800m2… The second command gives a lot of info including colorimetry disable. Thank you.
After rebooting the box returns in the previous state and displays again BT709 flag.
May be it is autosuggestion but to my eyes the video looks a little better with no flag status. I believe to my eyes and to my ears too, so I ask you if this change (no flag) can be made permanent and there is no necessity to apply the command every time the box is rebooted.
Many thanks @cpm
1 Like
Would you be able to add equivalent parameters for clearing color depth and chroma subsampling flags?
Ugoos in contrast to x800m2 certainly sends color depth (Sony OSD: Ugoos = 8bit, x800m2 = empty).