Mine’s an LG C8 but my Ugoos box goes via my Sony STR-DN1080 AMP. Some of the other profile 7 files like the test clip work fine, I can see the logos etc. mixed in with the moving colours. I haven’t had a chance to try CE21 yet though, just using CE20.5 stable.
C8 doesn’t support cmv4, I think @cpm owns that tv.
Can you try it without amp?
Is the difference where it says “Mastering display color primaries: Display P3” versus “Mastering display color primaries: BT.2020”? I don’t otherwise see any differences between a video that works and a video that doesn’t.
Have you tried the skin itself? Because it looks like the amlogic specific fields (the ones I had to add for AZR) are already in the relevant xml file:
Don’t believe it is no matter how files are played from PM4K. I haven’t tried SMB substitution paths but someone mentioned still bad colors.
Only seems to be an issue on Sony TVs though. LGs are fine in TV-led anyway. Also on Shield the bit is set correctly.
Was reading through some Kodi 21 commits the other day before deciding on submitting a bug and found this tidbit:
Supposedly one of the driving factors for redoing the cache code is that is before Kodi 21, SMB config had a fixed, hard coded chunk size of a puny 64KB and even trying to set this in advancedsettings.xml was ignored. Apparently SMBv1 requires 64KB but newer versions you can set this for better performance and lower overhead. I imagine 2MB is too high for general purpose usage of that protocol but given we’d almost entirely be transferring huge files contiguously for extended periods of time, that setting would be ideal here to squeeze out throughput?
I also historically had a lot of issues with SMB performance in Kodi (largely why I’m using WebDAV rn). But given this bit of information I’m tempted to revisit SMB…
1 Like
Hdmi setting 8k enhanced on my MARANTZ CINEMA 70s gave me issues , had to change to 4k enhanced . But still have issues with setting tonemap sdr to hdr enabled ( gives wrong colors after first dv file playback) . Disabled for now …
Any chance you aren’t using an HDMI 2.1 cable? One thing I learned a little while ago when dealing with HDMI: is never use an older, pre-HDMI rated cable if something in your setup can handle the higher bandwidth 
Nope , dont think so
High Speed with Ethernet, 2160p, 3D, UHD 4K×2K @ 60 Hz, DTS, ARC Hdcp 2,2 , should work right ?
For slow connections you can change the cache readfactor so it fills the cache faster.
By default it allocates to 4x of the content bitrate as the available bandwidth but you should set that to Adaptive or a higher multiplier so you ensure it’s using all of the 300Mbps you have available to you.
I don’t believe the 12-bit bug is fixed. It still sets incorrect color bit depending on the videoplayer’s handler.
I won’t be redundant, but this post captures the bug:
Both are webstream links pointing to identical content But one gives the URL to the plugin handler, no color bit issue. The other directly passes the URL to the VideoPlayer, then color bit issue.
I found this info too while pulling my hair out over the stuttering I was seeing. Was very happy to see they added the settings to the GUI. It made such a huge difference jumping to SMBv3/1MB chunk size. I could watch the video queue drain to 0% once the movie bitrate went north of 60-70Mb/s, at which point it would hard freeze for a few seconds. Now it fills the queue nearly instantly when I skip around in the file.
Good to know! I’ll keep that in mind if I see the issue resurface.
Is it possible to fake dv edid on CE for playerled/ lldv to use with non dv capeable projector?
Do you know what this would be in the Keymap Editor? I hate having to pull my keyboard out to do this.
Edit: Nevermind the second after I posted this I found it.
At the moment, all we know is that it’s reproducible using PM4K. The other instances it appeared seem to be addressed. Right now we’re not “chasing” it but maybe someone that uses PM4K can catch the bug.
When I use this, every single 4K movie I have shows 8bit BT.709, and I know that can’t be right. I have no idea why that is the case though.
Thank you. I saw those items, but I thought you had added some extra info maybe 
Hey, author of PM4K here. The thing is, I don’t have any control over the video stream, bitdepth, or even about how the video is handled at all (or I’m not aware of it).
We pass the playback URL (or path) to xbmc.Player() and that’s that.
The plugin:// route and playback directly from Kodi works for DV on non LG TVs with these boxes, via the xbmc.Player() python hand-off route, it doesn’t set the correct bitdepth.
2 Likes
Do you mean for DV content? Currently the code is set by default to not set the colorimetry flag for TV-led DV and if so it’ll show BT.709 in the player process info. There was quite a bit of back and forth about whether should be set to BT.2020 or not set at all. If you want to set it to BT.2020 (that’s what I’m doing and personally I think it’s the correct approach) there’s a kernel module flag you can set and put in that in the autostart script.
1 Like