MKV files will trigger DV.
Itās not supported by Kodi - Kodi is built around a single video stream (track) only.
DoVi UHD blu-ray have two video streams (tracks) - the first of the two can be used on itās own and is HDR10 - it is designed as a āfallbackā for equipment that do not have DoVi capability, combined together the two tracks provide DoVi.
MKV made from the blu-ray works around this problem by - in simple terms - multiplexing the two tracks into one single track, so it can be passed though kodi, the amlogic decoders kodi then uses reverses this process and de-multiples the single track back into two tracks and then proceed to process the full DoVi.
So basically I think you will only get the HDR10 track playing ISO etc.
If we want ISO capability in Kodi, the most likely approach would be to on the fly multiplex the two tracks together up front - though not a trivial task - maybe it will be added one day.
Ironically if you enable vrr which seems to be a prerequisite to enable 120hz and other features like low latency (ALLM), DV gets disabled completely for at least X85J TVs
I suspect the issue may actually lie in how itās being called, namely within INIT_DELAYED_WORK. Iām going to take a guess and say thatās probably an asymmetric callš¤
@cpm any idea why dv playback messes up sdr/hdr playback after i play a dv file if setting tone map sdr to hdr is enabled ? Same on booth Kodi 20,5 and 21
Player led and gui 4k hdr @ 50 / auto /auto
On boot all good
On sdr play all good
On hdr playback all good
On dv playback all good
But now sdr/hdr is wrong . Green / purple. Kodi gui is seams to in ādv modeā and doesnt switch back. After reboot all good again if i dont play a dv file . Problem also goes away if i disable the map sdr to hdr setting .
Would make sense yep, iirc there is quite a bit of locking going on to control the flow, I had tried to just call set_display_mode_auto again in hdmitx_set_vsif_pkt to try and force the issue - but that resulted in a kernel panic and lock up on an irq so probably good reason these commands are being delayed/sequenced somewhere.
Not something I have knowledge about - should bring to the attention of the kodi team e.g. @Portisch etc. they have more insight / can help troubleshoot.
Similar to the original workaround for MEL detection, is it possible to delay this call for few dozen milliseconds to compensate for the slower of the sourcesā¦ HTTP will be quite a bit slower than SMB.
Wouldnāt all issues involving MEL detection, 12-bit outputs, etc by rock-solid resolved by simply passing some of the file info from kodi down the chain and doing a single change of the hdmi mode?
Or does this just not make any sense from the way the code is setup?
thank you! makes perfect sense. I suppose Iāll keep the am6b+ for future potential. I was hoping to replace my current DIY setup where I have a linux kodi box as the frontend and installed scripts to send the playing file to my oppo 203, followed by a script to change hdmi ports on my receiver or LG tv. I just havenāt figured out how to switch back to the linux kodi box hdmi port after playback is stopped on the oppo 203.
Yes I would agree that is reasonable, but as you state it is likely more the structure here that causes these āanomaliesā, maybe can say logically it is a simple flow, but have two somewhat competing master trying to control the flow.
My thoughts: AMLogic open sourced their code for linux, but it is fundamentally an android solution (mbox - stb and embedded tv) and built for that, the AMLogic libraries and code can fundamentally do it all - they can do ISO, TS, ES, domestic broadcast standards etc. for example.
Kodi has been placed on top and it is that integration where things start to get complex, AMLogic really also wants to be higher up the chain and integrated more.
If someone want to deep dive the the auto call - where it is being done and why in real-world it is coming first, that would be a good starting point - my guestimation is it is kodi triggering not the AMLogic side.
AMLogic want to control the switching of modes including DoVI - actually it wants to do the āletās do everything through the DoVi engineā trick - like some other solution out there, kodi just wants to switch it on and off for DoVi only, and handle other content another way.
So, theoretically and probably with a lot of work, diverging the code away from kodi slightly, and relying more on the amlogic side would likely resolve all these issues and allow for new features like dual track dual layer playback?
FYI for MEL I leveraged quietvoidās work in the bitstream converter (to convert from profile 7 to 8), in there it was already finding the RPU of the frame and doing the necessary conversion. So just a matter of checking the RPU for MEL - which is also already in quietvoidās library as well - based on the Dolby definition.
So now it JIT checks the first frameās RPU whilst passing though the bitstream converter and then passes that down into the creation of the AMLogic processing - so it knows up front if it is MEL or FEL (which require different handling), before the data stream is then hooked up.
Ideally MEL/FEL should be metadata on the file, but is not - and still needs to be worked out from the content.
yep - it is more kodi limitation or maybe more politely the combo limitations.
Edit: kodi is based around splitting out the AV streams, video, audio etc and then controlling their playback together (after some possible conversion etc.)
Edit: should add also dependent on actually how much AMLogic have open sourced for the linux side - may still run into something missing - just FYI.
Hi PurplePlayer, thanks very much for your X85J advice yesterday. Based on your post I have now plugged the ugoos into HDMI 2 (Enhanced) leaving HDMI 4 open. This allowed me to properly load the dovi.ko driver and got the two required toggles. But unfortunately still got purple/red distorted video for all DV files using PM4K.
So I stuck a few of those DV files on a USB stick and stuck that directly into the ugoos and played them directly with Kodi bypassing PM4K and guess what? They finally worked! So this leads me to ask you what are you using to watch your DV content on your X85J HDMI Enhanced Port 2 if not PM4K?
Because to me (the noob) this rules out my purple/red DV problems being caused by either the SD Card, CoreELEC, Kodi, bad HDMI cables, and (maybe probably) the X85J TV. The fault should probably be something with PM4Kā¦ am I correct in thinking this? So before I start posting in the PM4K with this problem I thought I would ask you expert CoreELEC guys first 
I keep reading that all PM4K does is send the video file ādataā straight to the Kodi player but I guess I just proved this is not quite true because otherwise I wouldnāt be having this washed out red purple image with DV files only with PM4K
Hi doppingkoala, I would love to do that but I have no idea how to do any kind of ssh command, I donāe even know what that is. This is only my second day of using Kodi, so sorry. If itās not too difficult I could do it with detailed steps. However, as I wrote in the post above this one, I think the problem is with PM4K and not with CoreELEC itself. As playing the DV files from a USB stick thus bypassing PM4K they finally worked and I got DV without the purple screenā¦
Your probably right about PM4K being the problem.
FYI these instructions show how to get to a ssh terminal. Once you get to the end of those instructions - you would simply need to paste each of the ssh commands I gave into the window, press enter, and upload the text output that comes from each command (one at a time).
If your up for it, the results using a USB stick when connected to HDMI 4 (in both enhanced and enhanced w/ DV modes) would still be interesting to see
@andyxoxo44
I think it is true that PM4K does just send the stream and it is the same content - but there is an issue with Kodi during the switch into DoVi which appears to be sensitive to timing, the mechanism of content delivery could be impacting that timing and thus cause the TV to be put into the wrong mode even though the actual content is the same!
1 Like
Thanks for the info, I guess the only thing I can do is post my problem in the PlexMod4Kodi thread over at Plex Forums and see if the developer has any idea of what I can doā¦
Switch to SMB path substitution in the newest beta of PM4K or use PlexKodiConnect. Both will use an alternate delivery mechanism vs the default HTTP webstream.
In the case of PlexKodiConnect, it too actually passes the webstream into Kodi, but through the logs, you can see that the handler it uses is different. Probably because PKC is adding the files into the native Kodi UI.
Most people donāt use Plex, and will directly map the SMB for Kodi to scan and add into the library.