I thought all DV is an extention to HDR10, where it includes the dynamic metadata that define the aspect ratio and adjust the picture based on a display’s capabilities etc. This is to keep the backward compatibility. Is it not the case for profile 5?
No HDR fallback in P5
okay, 
You should be good to go.
It includes all the changes needed for tv-led.
There maybe some benefit for some more flag changes in LLDV need to test more for that.
1 Like
@millercentral You don’t have to do anything manually on our nightly builds, it should work out of the box. Just make sure you have the DoVi conversion set to Lossless in player settings.
@MacUsers As others have noted, Profile 4 and Profile 5 media doesn’t have HDR fallback, so they play in SDR with wrong colors. P7 is equivalent to P4, but has HDR fallback, same for P8 and P5.
You can use an app called MediaInfo to see what the type of file you’re trying to play.
Also, if you use Yatse or a keyboard (O key) you can open more info about the playback config during playing the video.
3 Likes
0317 nightlies will make it easier to copy dovi.ko to your device.
Additional folders you can now put it in are /storage/.config - via SMB share \\YOUR_DEVICE\Config and /flash - connect the USB/SD card to the computer, and copy it to the root folder.
So the dovi.ko should always in /storage directory?
Its valid for CE install on internal emmc and usb/sd card?
Yes that is correct
1 Like
Dune is actually a strange title in regards to this problem. So many other movies, and I haven’t seen this behavior yet, until now 
When it properly triggers you see this in the logs of my test build (added kernel logging for debugging, just calls out what was reached in the code):
[ 4914.623103@0]- hdmitx: EOTF_T_DV_AHEAD - line 693
[ 4914.623105@0]- hdmitx: RGB_8BIT - line 698
[ 4914.623106@0]- hdmitx: RGB_10_12BIT - line 700
[ 4914.623108@0]- hdmitx: hdmitx: display colour subsampling is auto set to YUV444 (VIC: 93)
[ 4914.623110@0]- hdmitx: EOTF_T_DV_AHEAD - line 743
[ 4914.623112@0]- hdmitx: RGB_8BIT - line 748
[ 4914.623114@0]- hdmitx: hdmitx: display colourdepth is auto set to 8 bits (VIC: 93)
[ 4914.623136@0]- hdmitx: video: already init VIC = 0 Now VIC = 93
Somewhat rarely for only Dune so far (maybe 1 in 5 resume attempts) however, something appears to glitch, and Kodi somehow thinks it’s basically an HDR10 title:
[ 4945.709368@1]- hdmitx: hdmitx_set_current_vmode[5911]
[ 4945.709371@1]- hdmitx: system: recalc before 2160p24hz 2997 125, frac 1
[ 4945.709374@1]- hdmitx: system: recalc after 2160p24hz 2997 125, frac 1
[ 4945.709376@1]- hdmitx: set_disp_mode_auto() called - line 5637
[ 4945.709379@1]- hdmitx: system: get current mode: 2160p24hz
[ 4945.709381@1]- hdmitx: system: update physical size: 1600 900
[ 4945.709391@1]- hdmitx: hdmi_current_eotf_type is default - line 722
[ 4945.709393@1]- hdmitx: hdmitx: display colour subsampling is auto set to YUV444 (VIC: 93)
[ 4945.709395@1]- hdmitx: hdmi_current_eotf_type is default - line 785
[ 4945.709398@1]- hdmitx: hdmitx: display colourdepth is auto set to 12 bits (VIC: 93)
[ 4945.709422@1]- hdmitx: video: already init VIC = 0 Now VIC = 93
Also I seem to only be able to experience this on a movie resume. Seems to work every time if I start from the beginning Though I think this may actually be related to the logic that determines MEL/FEL and in conjunction with the wait delay. On titles heavily dependent on that, that logic somehow gets missed on a movie resume occasiionally, though I haven’t seen it happen if I play Dune from the start.
Do you recall what other movies heavily needed that delay?
Above post has a list of problematic films.
It is 100% for me on Dune it never triggers - never gets set to Tunnel.
My E8 is reporting dv version 1.
Looking at the logs - for the problem 12bit - it is because the auto resolve of the cd/cs has kicked in before the dolby processing has had a chance to flag the HDMI for tunnelling, once it does flag it is too late.
Hi, I switched to todays build from CoreELEC nightly builds
but I don’t see any of cpm’s changes? dolby_vision_flags is set to “5” and new parameters are not there. Actually, I don’t see the merges on github either.
By the way, for testing out builds I recommend using “ceemmc -x” on a spare SD card. It’ll copy your current installation and if you keep sd inserted, next boot will be from the sd card and you can do anything you want without touching your main installation.
The bits required for tv-led are there the others were in the process of trying to figure things out with test build and not required.
They will possibly be useful for LLDV, but for now all good for tv-led.
2 Likes
Oops, yeah. Should’ve checked some content too. Seems to be good so far, had to put “.nocompat” in “.update” folder to switch builds.
Did anyone notice a significent delay in playing DV material? For me, it starting a few secs later (after pressing play), audio starts, screen brights up, then it goes blank for few more seconds, audio stops at that point too and then it comes back.
@MacUsers
The detection delay for MEL movies has been recently increased to address the issue of these films being mistakenly identified as FEL, which was causing the picture to freeze randomly during viewing.
Just tried ce-21 and fel movies freeze during playback. It was the same when I tried a couple weeks ago, when the Dolby codes were synced between ng-dv and ng.
Juarassic world dominion and Saving private Ryan, both are FEL play without any problem here.
I’m seeing exactly the very same thing and IIRC, the playback is not that smooth on 20.5 either.
20.5 or 21? 20.5 is fine here.
@MacUsers
I’m one of the lucky ones to never have any stability issues on 20.4 and now 20.5.