Posts by mitzsch
-
-
Do I understand correctly - if on current LE master you remove nvidia-ng from options then it works ok?
Yes, exactly.
No frame skips when GUI is opened.
Once opened, everything is fine. The "opening" process causes a massive frame drop.
Here is my (working) build with nvidia-ng removed...
<download removed, no longer needed>
I will try the "Generic image" from Chewitt.
-
As the title says, opening the playback ui (hitting enter) or the playback info (pressing o) is not smooth and causes massive frame drops on a system with an AMD GPU since build 13.0-nightly-20260517-7374d38. The last working build is 13.0-nightly-20260516-ba37c30.
My system:
Ryzen 5 5600x | 16Gb Ram | RX 6600 | 16Gb Optane M10 boot disk
First, I thought it was due to a Kodi change, so I compiled myself different versions of LE with different Kodi commits from May 16 and 17 with the latest set of LE patches.
All showed the same behavior. I then compiled the Kodi version (c685f9c0efe9439f16018d450a78aa7ed25c2b8a) that comes with the last working build on top of the latest LE patches. I expected perfect results, as I thought it must be a Kodi issue... but also with that build, I also experienced the mentioned issue. So, no Kodi issue but a LE one?
I checked the commit history on what has changed between May 16 and May 17. The most obvious was the inclusion of NVIDIA GBM drivers. (which also made the image size 200mb bigger)
So I compiled a version with the latest Kodi and with nvidia-ng removed from the "GRAPHIC_DRIVERS=" OpenGLES option, and now it's smooth again. I don't know why excluding drivers that aren't even loaded fixes the issue... Or are they loaded??
I also added the logs from the official LE builds
-
Nothing specificially targetting the unknown problem.
Hm, okay, I also just tested the latest build (17/04/26 - fresh install) and both the issue with the LPCM wrong channel mapping and hbr passthrough persist. Hopefully, they can get sorted out.
About HDMI 2.1 - now that AMD wants to upstream HDMI 2.1 bits into the mainline kernel - this could open the gates for (rk) HDMI 2.1 open source implementations legally.

-
-
-
thanks!
Just two more questions about (the future of) the rk platform.
- Is the memory cap "fix" still needed?
- The rk3588 has an HDMI 2.1 out port. Will we ever see HDMI 2.1 being supported by that platform? I have seen that there have been some HDMI FRL patches made, but with the HDMI association blocking all HDMI 2.1 work and implementations on Linux ( at least with AMD and Intel..), will we ever get HDMI 2.1?
-
-
For anyone interested.
While testing the custom EDID, I found that Kodi in its "default" version does not accept those custom 23p modes due to the calculation done by the Kodi code.
I made a fix and opened a PR, there I also explained the problem in more detail => https://github.com/xbmc/xbmc/pull/28080
With that fix applied, Kodi now "accepts" new custom modes.
I'm currently testing an EDID created with CRU with a slightly altered 23p mode.
This site is very useful for custom mode timings => https://www.monitortests.com/pixelclock.php
I noticed how important the blanking values (horizontal and vertical) are... Vertical above 80 and horizontal above 180 for audio passthrough to be working fine...
-
With the build from 22.02.2026, HBR passthrough works on my end with DTS-HD and TrueHD, with the already mentioned dropouts. However, the channel mapping issue with PCM audio is still present.
I watched a whole movie (with passthrough on) and only had one skipped frame in a runtime of about 90minutes... (and this one could have been triggered by me opening the debug info overlay). No idea what was wrong with the earlier build on my setup...
However, at the end of the movie screen output crashed somehow. Audio was running, the screen was black, but the TV signaled that the link was still active. Here is the (truncated? => the same outlines again and again spammed the output so I just copied that part that I was able to grab) dmesg output... (dmesg1.txt)
After exiting playback, the UI came back on, but after selecting a different movie file, the screen was all black again and would also not come back on exiting playback...
dmesg2.txt => Unfortunately, also just a snippit - that's all I could grab...
-
oke, update - I just tested the latest build (21/02/2026) and audio passthrough of at least Dolby Digital works fine (dts untested); however, with my UHD bd rip streamed from a smb share, I had some severe frame dropping. Multiple frames at a time...
I will retest with some more time, with passthrough enabled and without...
What I also noticed, was pcm output seems wrong in regard to channel mapping. The center channel was played by the right channel speaker.
-
Thanks for your response!
I have adjust-refreshrate enabled with all the modes I need selected... LE/Kodi also switches to them just fine... but while playback is running, it drops frames constantly. Audio (with passthrough) is not a problem... it's all about video framedrops...
I guess I need to tinker with modified EDID...
-
Thanks for providing all these builds chewitt!
I will need to test the latest build. Last weekend I tested the builds from 23/01/26 on my Radxa Rock 5 itx+, and playback was pretty good... and HDR worked perfectly (so far)! I rechecked with my HDfury Aracana to see if all HDR metadata values are transmitted correctly, and they are! The bt.2020 flag was correctly set, min/maxLum was transmitted, maxCll,maxFALL, whitepoint, and content mastering colorspace were also correctly transported! ... and all that with a 10Bit HDMI link and HEVC hardware decoding.
PCM audio was also working remarkably better than before... At that pace of developement the rk3588 could become a pretty decent media playback powerhouse soon. The only thing left for me would be HBR audio passthrough support.
The HDMI timings, however, do still seem a bit off - my AVR still cannot overlay its info screen... not an issue though.
About HEVC decoding and your problematic files... Are those publicly available? Or could you explain what is broken with them? chewitt
I'm also collecting such samples to test any kind of hardware...
-
I'm currently running a Dg2 (Arc A310) system with LE 13, and it works pretty well. HDR and audio passthrough works! (... with the HDMI 10-bit max patch applied)
But I have an issue where the playback of 23.976p 2160p HDR content drops frames (= av corrections) pretty constantly every 12 to 18 minutes. The hardware is more than capable of decoding even AV1 8k60 hdr content, so it shouldn't be a hardware "is too slow" issue.
The logs also do not indicate anything wrong. The 23p HDMI mode, "3840x2160 with 3840x2160 @ 23.976025 Hz," looks good.
I know with passthrough enabled, Kodi is not able to resample the audio on the fly to accommodate for drifting due to framerates not matching (content =/= display). But is this even a thing on the hardware? I was under the impression that Intel (and AMD) have pretty good HDMI timings, so a frame-drop-less playback is pretty much plug and play. Whereas Nvidia needs hdmi clock tunings...
Did this change? Is this different on Linux?
Is there anything I can do? It drops frames regardless of the audio codec used for passthrough.
Does the setting "maxpassthroughoffsyncduration" help?
Or is the only thing i should test an EDID mod with different HDMI timings?
Any help is appreciated! Thanks!

(The attached log is with playback through a plugin (pm4K) - however, the dropped frame issue also happens with playback through Kodi without any plugin in the chain. It was just the log that I had flying around.)
-
-
I tried the (awesome) build on my Radxa Rock 5 ITX board. Install was flawless... Overall performance is pretty nice. On my 4K TV set - the GUI runs buttery smooth (at 4K60!)...
However, I noticed some wonky things, besides the known ones (no passthrough, no HDR)...
- Audio drops out irregularly while watching (48khz and 192khz content)
- 192KHz Audio is not played "cleanly" - you can hear a popping/hissing/clicking
- Dropped frames even though the video is decoded via hardware - is there something I can do about or is this known?
- Video HDMI timings are odd - the OSD of my AVR (Marantz Cinema 70) is not shown - I only had this with a pc where I altered HDMI timings... - Running ARMbian (with vendor kernel and closed source Mali Valhall or open source panfrost driver) the OSD is shown perfectly
If needed, I can send the sample file that I use(d) for testing audio things (it has different audio tracks, stereo, 5.1, 7.1, 16bit, 24bit, 48khz,192khz)
Question:
hw decoding of h264 and HEVC work fine - so are the hw decoding bits from here - that are sent upstream (https://gitlab.collabora.com/hardware-enabl…nline-status.md) already in there?
thanks!