Posts by S80_UK

    I would suggest to avoid AMD for this. Intel, Gemini Lake is working well with test builds. I use Pentium Silver N5000 in an MSI Cubi N box with available test builds. Some newer devices are also working will in Intel NUC boxes, but even Gemini Lake is sufficient for the normal 4k MKV rips that I take from my UHD Blurays. I have no experience using Atmos, but I think that is now also supported.

    See this thread... LE11 HDR builds for Intel and AMD

    The mainstream builds from the LE download page are not yet supporting HDR on x86 platforms.

    Only thing is there is an occasional audio dropout when I bitstream- every so often I get a "source is too slow" message when I try to stream off my NAS.

    I see this message too, but without any dropout. For LibreELEC I am using MSI Cubi N with a Pentium Silver N5000 (Gemini Lake) with 8GB RAM. I generally get this message when the 4k video file is already in cache in the NAS (my Unraid server on a gigabit LAN connection). If playing a file for the first time then the message is seldom seen. If I stop playback after a minute and then play the same file again from the beginning, the message will then pop up. It's almost as though the file data arrives too quickly. To me this suggests a possible arithmetic error in the source speed calculation caused by the data for the initial buffer fill operation taking very little time to arrive.

    I bought a Noritake VFD GU140X32F. It can by used with serial or parallel interface and it's HD44780 compatible. I use it with an level shifter (3.3V-5V) and an converter (i2c - parallel).

    Hi. I also have that exact display available from an old project. I would be curious to try to get this working as well. Do you have a link for the I2C to Parallel converter that you are using?

    Celeron j4125 is fine, although I cannot comment on those particular boxes. I even run a Celeron N3060 in one system, which is significantly less powerful, and it has no trouble with 1080p or even 4k, but that older generation won't handle HDR. Note that HDR is not yet supported in the standard LE releases for x86, but there is a series of test builds being worked on over here... RE: Intel true 10bits/HEVC/HDR support... ?

    Not sure why that spec page says HDMI 1.4. Gemini Lake SoC has a built-in HDMI 2.0 controller. HDR is not possible with HDMI 1.4.

    I read about this with other boards that should support HDMI 2 but don't and believe it's a BIOS limitation (possibly set to save compliance testing cost?). HDR does work well, however, and triggers the HDR status icon on my LG OLED TV.

    There's a thread about HDMI compatibility and some systems not supporting 2.0 when they could here... HDMI 2.0/HDCP 2.2 motherboard verification - testers needed : htpc

    AMD G-T52R - CPU Passmark = 177....

    I haven't seen such a slow CPU since the single core Atom 270 back in 2009... You might JUST manage to get LibreELEC to run on a single box as a stand-alone device (forget streaming from another machine), but it would be hopelessly less capable than something cheap and simple such as a Raspberry Pi 3 or 4.

    The graphics is apparently Radeon HD6310 which is of similarly low performance by todays standards.

    If they work, great. If not, then it's probably time for the e-waste recyclers.

    To rule out problems with the power supply, I replaced the 3A USB C power supply with the USB C charger from my notebook. Doesn't make any difference either.

    That may not prove anything. Most notebooks' USB-C power supplies only provide limited power at 5V. They use the smart capability of USB-C to change voltage and may then switch up to much higher voltage and current. I don't think that the Pi does this smart voltage changing, and so it might still be constrained by limited power availability unless the 5V capability of your other supply at least matches that of the Pi power supply. Certainly your screens shots suggest a hardware or power related issue.

    I can pop this in the update folder and have it update without wiping all my settings right?

    I would always recommend a backup of settings before trying a new build. That backup can be to local storage, a USB drive, or whatever, often it only takes a few seconds. It saves a load of time if you need to downgrade to an earlier version. Sometimes when you downgrade, some settings may get lost, and a quick restore works wonders. You will also notice that each backup is time and date stamped within its filename, so I often keep several backups going back in time made using various test versions and official builds.

    There are still test builds being provided in the thread that I linked to in my previous post (directly above yours). Since this is still being worked on, no-one can guarantee the performance with your hardware (especially from an unknown brand bought from AliExpress). My advice would be to take a backup of your current settings so that you can reapply them if you need to reinstall your current software version, and then give one or more of the test builds a try. Most x86 users are using Intel platforms (but some are using AMD), so any additional testing and feedback would be helpful to developers

    Yes, I can also reproduce this on my Gemini Lake box. An issue with subtitle rendering.

    Confirmed - I have the MSI Cubi N 8GL with Gemini Lake Pentium Silver N5000, so I am also dipping in to try out these builds from time to time. This artefact is not present in the regular x86 LE 10.0 beta 1 build here... LibreELEC (Matrix) 10.0 BETA1 – LibreELEC

    I assume this bug is probably specific to the HDR adaptions, although it is seen when playing 4K HDR as well as regular 1080p Blu-ray rips with subtitles.

    LPCM and the HD audio formats are effectively the same thing (once the later is decoded) :)

    I would agree - but what's being discussed is the benefits of different decoders in different locations (at different points in the signal chain). In the AVR at least, there is generally a highly capable DSP largely dedicated to the task. I am not such a critical listener, but I also generally choose to have the AVR doing the decoding. I do know that I am very sensitive to any glitching in the audio. Perhaps the difference comes down to the re-timing of audio to maintain synchronisation when the decode is handled by Kodi...? (just a hunch - I am not the expert here).