Received my Ugoos AM6b+ today and have some questions. So, please go easy, I have not read all of these pages, but have been following closely.
First question, from these instructions >>
7. Copy dovi.ko to the root of your COREELEC flash drive.
8. Copy remote.config to the root of your COREELEC flash drive.
I don’t understand what the root is?? Do I copy those files to the micorSD card as soon as Etcher completes the creation of the bootable disk?? Or do I copy those files to the “configfiles” folder?? I have done both, but the remote does not work.
Also, how can I tell if CE is using the dovi.ko??
thanks
You can see that the EOTF is DV, so you configured the dovi.ko correctly.
Not sure about the remote, sorry.
I believe the remote is a combo IR and Bluetooth… No script for the IR part of the remote?
You did the dovi.ko part right. That should exist in the root folder of the flash disk after your image is written successfully. It’s not an issue if it also exists in the configfiles folder.
Remote.conf should be put into the configfiles folder for IR.
Thank you, I will do that for the remote. Also, I was reading on here about NOT booting back into Android or I lose the dovi.ko?? Is that true?? So, no dual booting or lose the real Dolby Vision???
Edit: I rebooted the box so the remote could take affect after I added the remote to the correct location. Not sure what I did, but it booted into Android. Rebooted again and it booted back into CoreELEC. I tested the player led and TV led, both worked perfectly…
FANTASTIC!!!
of course remote still did not work, but not an issue since I have other RF remotes that I used.
It needs a code change to clear the flag (not so simple to limit that to just DV and put behind a parameter - so I just had my own test build), or you can use something like an HDFury to alter the AVI InfoFrame to clear the flag.
Is there any way to make ugoos box boot to CE on sd card without toothpick method? My box always boot to CE on internal memory!
My experience was if you install the dual boot firmware it always boots to the internal emmc by default. If you use the plain android firmware then it boots to the SD card first once you’ve done the first toothpick reset. So I went back to the normal firmware so I could test different version with an SD card swap.
I believe a reboot update in CLI will trigger boot via SDcard/USB?
@allanp81 honestly this sounds similar to the phantom issues I have experienced that would eventually resolve itself after restarting, power cycle, reconnecting etc. What I suspect are all related to HDMI handshake issues.
As for booting to NAND inadvertently. I more or less “fixed” this by removing that option in the power menu for the AZR skin I’ve been recently using. 
As for remote.conf I put that in /storage/.config but that’s also because I added a second remote (Dune HD “Premium”) as my primary and the UR-01 with a few remappings for power control.
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 