Posts by isamudaison

I've only been able to pull this off on *one* alder lake n-based mini pc. Of all the units that have dual HDMI outputs, only the Simodewa https://www.amazon.com/SIMODEWA-Mini-…y/dp/B0BZHKH2C5 (which amazon shows as currently unavailable) has worked for me. Not only is this the only unit I've gotten it to work on, you have to plug the display / AVR into specific ports, otherwise it won't work at all.

That said, the experience is truly enjoyable; mode changes on the display are instant, and the AVR 'locks on' to the audio stream with no issue, with the last caveat being the AVR can't be plugged into your TV (and therefore only supports 720p/1080p on the audio stream output).

Your other option is something like a VROOM device (assuming you also have gaming components you want to use).

I briefly tried the Mele Quieter 4C (N100 fanless) and had all sorts of issues, so try that one at your own risk.

There is the HUNSN BM34 that sky42 mentioned that I currently have as one of my boxes, which has two HDMI outputs. The only issue with this box is that 'HD2' HDMI output is wired/seen as a display port output (not HDMI), and you cannot get bitstreamed audio or proper BT.2020 colorspace output (from my searching there'd likely need to be some Kodi updates to allow the proper colorspace output over DP). HD1 output works as expected. I've not yet fiddled with wake from S3 on this box, but I do have an external pule8 CEC adapter hooked up, and will tinker with that shortly.

Just reporting that using sky42 's build above, my Sony TV no longer struggles to lock on to mode switches via an n100-powered Kodi. It seems the [email protected] mode is quite buggy on the intel side.

Thanks sky42 for your bt2020 builds... It's a little misleading to have 'HDR now supported under intel & amd' in the 11.0.4 release notes when the official builds don't trigger the bt.2020 colorspace, effectively making the HDR mode useless (although it does trigger HDR mode) *shrug*

Quote from DaisyF8

(Posting here because of mentions of refresh rate).

I'm using LE 12 nightly generic 20231206 on Intel HD630. HDR is working on my Sony.

I have an intermittent sync problem for pretty much every refresh rate/resolution combo. I think start of sync doesn't get reset to topleft when refresh rate changes. Not only when playing but also regular UI.

Is this a known issue?

I noticed this as well, but only on my newer Sony TV. My LG oled & A company that starts with an 'E' projector (I don't know why that is censored here) don't have the issue. I downgraded back to this build and the issue went away: nightly-20231103-a581fc8

Quote from w46n3r

[...]

Strangely enough, using 4k@24Hz seems to "solve" the audio dropout problem. I'm still testing to be fully sure of it and understand the implications, if any.

Not running at the native framerate (23.976) means you won't be able to properly bit stream the audio; it will get decoded and passed along as PCM/LPCM and (I believe) will avoid the issue... but you'll lose any Atmos/dts-x (3d surround) ability. Most likely there's some issue in intel's media-driver or firmware for the decode pipeline/hdmi transport (IIRC displayport doesn't exhibit the issue?)

Quote from w46n3r

I was thinking about getting a Beelink N100 myself due to the working BT.2020 triggering... but this HD audio bit got me worried. Isn't HD audio passthu working?

The only way I've gotten HD audio (TrueHD/DTS-HD/MA) to reliably stream without dropouts is to separate video & audio signals; This means you cannot have the AVR connected to your display ( otherwise libreelc will just 'clone' the signal out, causing the same issue) , and have to utilize both HDMI outs (one going directly to your display, the other going directly to your audio processor).

Thought I'd report that the 'last' nightly of v11 (LibreELEC-Generic.x86_64-11.0-nightly-20230519-c3ca265.img.gz) does not have the bt.2020 fix (not sure if this is intentional); Don't want to to regress it forward to the v12 builds.

I recently tried playing back a video with a resolution of 3828x1592. I would have though Kodi would try a UHD screen resolution with matching refresh rate, but instead it fell back to a 1920x1080 screen resolution:

2023-05-23 15:59:57.213 T:913 info <general>: [WHITELIST] Searching the whitelist for: width: 3828, height: 1592, fps: 23.976, 3D: false

2023-05-23 15:59:57.214 T:913 info <general>: Display resolution ADJUST : 1920x1080 @ 119.880127 Hz (35) (weight: 0.000)

I had to manually select a screen resolution of 3840x2160, and I don't have this problem with videos that have a width of 3840; Is there an advancedSettings entry I can use to define the 'cutoff' for screen resolution vs. video resolution (Yes all appropriate screen resolutions are whitelisted)?

Running nightly-20230514-e7ccb95 (Generic.x86_64) on an Intel n100 device I'm able to activate HDR correctly, connected directly to an LG C1. I've abandoned running video through my AVR as it had a lot of trouble 'locking on' to video mode changes / audio format changes (as well as intel's high resolution audio dropouts); luckily my device has dual HDMI outs.

Just an update here - I bought the cheapest USB bluetooth dongle amazon had ($5!) and it worked right off the bat... the UI for connecting is super broken so I had to do it via bluetoothctl in a terminal though, but otherwise it's working great now.

Unfortunately I'm 'stuck' on LE11 as there's a special build smp did to enable proper colorspace with intel HDR... I popped open the box and for some reason the wireless adapter is 'glued in' to the slot! - too bad as I have a spare ax210 laying around!

I have a newer n100-based miniPC that has the following intel wifi/BT adapter:

00:14.3 Network controller: Intel Corporation Device 54f0

It looks like this is a problematic piece of hardware (or at least a "too-new" piece of hardware):

While I wait for intel to add some better support, is there a 'tried-and-true' USB bluetooth adapter I can pick up in the meantime?

Thought I'd report in that using a Beelink n100-based mini PC and the latest build posted in this thread I am getting proper HDR10/bt.2020 triggering on my setup: Pioneer AVR to LG C1 TV. It's looking great!

I just recently picked up one of the new "Intel N95 alder lake" boxes (previously called Celeron, I believe - very low power draw, came with 8GB ram and a 256gb m2 drive installed); very inexpensive, unbelievably fast and I've confirmed it does full HW accelerated AV1 playback in the latest libreelec. Highly recommend (the box I got was off of amazon and some chinese brand I'd never heard of, so support is dubious at best).

Quote from powerarmour

You shouldn't need 10W+ to play media and run a pretty skin either, efficiency is king here IMHO

Currently I think an S905X3 SoC is tough to beat in terms of 'sweet spot' capabilities and efficiency.

Simply not my experience when you throw in LiveTV, and a media library of multiple thousands of objects...

Quote from chewitt

The x86_64 world is a little different to the ARM world. Intel/AMD standardised their hardware decoders around VAAPI so Kodi can call ffmpeg in a consistent way regardless of each, although at some point capabilities need to reflect which GPU/card and what the TV/panel supports. It all works reasonably well though advanced things like tonemapping still need to be plumbed in. Even nVidia finallly caved and added support for GBM/mesa to their latest drivers; and although Kodi does not support NVDEC (needed) someone wrote an NVDEC > VAAPI ship and we have a proof of concept implementation; although you need to run under Wayland which doesn't support fun stuff like "adjust-refresh" by design so it's not quite the solution nVidia users need (better than "no support" though)..

The ARM world is domainated by ARM Mali GPUs (well supported with FOSS drivers now) with separate vendor-specific decoders. These have a mix of "stateless" and "stateful" types under the V4L2 banner. The stateless V4L2 "requests" uAPI is stable and supports a good range of codecs upstream; it's still up to individual drivers to support them. The stateful "mem2mem" side is not declared stable yet, and with the dependency on vendor firmware blobs is generally a bit futher behind. There is a lot of collaboration happening on testing and upstreaming to the kernel - and LE is heavly involved in that (Kodi is a good test app).

On the userspace side most of the current activity on ffmpeg is focussed on making everything work. The process of usptreaming is looming on the horizon but it's still something to come. Again there's quite a bit of collaboration happening on this and we're involved.

Vulkan is an alternative to things like OpenGL/OpenGLES .. so "standards" .. https://xkcd.com/927/

Maybe a bit off-topic and maybe too philosophical, but do you see the vendor-specific ARM-based stuff as the 'future' of Kodi? I see distros like OSMC and (maybe to a lesser extent) ZDMC, et. all, supporting stuff more quickly simply because they pack the vendor-specific blobs in there and it 'mostly' works... I know HDR stuff in the Linux kernel/rendering pipeline has been a nightmare so far for generic stuff.

I ask mainly because I would love to build out another fanless x64 box for my home theater Kodi device (currently a Vero 4k+); I find the embedded systems to simply be under-powered.

I've noticed this 'sometimes' in OSMC's latest (Kodi v19) on the Vero 4k+ (UHD, HD content with a +100ms sync required), however it's completely inconsistent and doesn't seem to have a rhyme or reason... I've dealt with audio & framerate synch issues in the past and I'm over it these days Be warned it's a deep rabbit hole to go down!