Just wondering when 10.0.3 will be out. Thanks.
We too 
Plan is/was to align with kodi release cycle and ship LE 10.0.3 with Kodi Matrix 19.5. But Kodi 19.5 is taking a lot longer than expected.
In the meanwhile feel free to use the latest LE10 nightly builds from here: https://test.libreelec.tv/10.0/ (just copy it to the update folder/share and reboot), they contain lots of bugfixes and also a recently updated kodi 19.5 development version.
so long,
Hias
The summary you posted is correct.
While there's some support for YCC4:4:4 in the video driver (I noticed a function checking if it'd be valid), it doesn't make use of it.
The linux drm subsystem is a bit limited in that regard, there's no connector property that would let you force eg RGB or YCC - it's all up to the driver.
The only drm connector property we can play with is the max_bpc which let's us limit component depth to max 8/10/12 bits per channel.
max_bpc defaults to 8 (so that on desktops you'll get RGB instead of falling down YCC 4:2:2, sharp text is usually more important there than 12bit which might not even be used by the software running on the desktop) and in LE/kodi on the RPi we lift that to 12bit in case of 10bit video content so we can make use of the higher output bit-depth (which is more important here than potential loss in chroma resolution - subtitles and GUI are usually up-scaled from 1080p anyways).
so long,
Hias
For 10bit content the driver will check in the order RGB 4:4:4 12 bit -> YCbCr 4:2:2 12bit -> RGB 4:4:4 10bit -> RGB 4:4:4 8bit if both the sink and the RPi support that format.
It takes max TMDS bandwidth, YCbCr 4:2:2 and 10/12 (30/36) bit flags from EDID and also max TMDS rate from RPi into account (4kp60 / 600MHz TMDS is opt-in in config.txt) and picks the first supported format.
so long,
Hias
Thanks for confirming!
I guess enabling 4kp60 might help on 10.0.2 but better keep using the latest LE10 nightly - it contains a couple more important fixes.
Just checked: The issue was caused by a bug in the video driver that was fixed after the 10.0.2 release - seems it didn't handle YCbCr limited properly... https://github.com/raspberrypi/li…b3a04238134aace
so long,
Hias
Can you please also test with the latest LE10 nightly? https://test.libreelec.tv/10.0/RPi/RPi4/
Would be good to know if it's fixed there, too.
so long,
Hias
Ah, and another thing: your edid shows you've connected the RPi to a Denon AVR.
Please also test with a direct connection from the RPi to the TV to rule out issues from the AVR (Denon AVRs have some history of doing strange things...).
so long,
Hias
mathmath51 can you test with hdmi_enable_4kp60=1 in config.txt (you also need to enable HDMI Ultra HD Deep Color support in your TV's setting - this is usually HDMI-port specific) on LE 10.0.2?
LE10.0.2 supports outputting at 10 and 12bit, LE10.0.1 only sent 8bit HDMI.
So on LE10.0.1 your 4kp23.97 file is transmitted as RGB 4:4:4 8bit, 10.0.2 without 4kp60 enabled transmits at YCbCr 4:2:2 12bit, with 4kp60 enabled it transmits RGB 4:4:4 12bit - all that could make a difference.
so long,
Hias
Provide a log from some legit media and ideally some short sample so we can reproduce the issue.
Not only we don't care about piracy crap but also there's just too many issues with bad rips/encodings etc.
Test with known samples, eg from 4kmedia.org on a clean LibreELEC installation without piracy crap and we can have a look.
so long,
Hias
Remove the piracy crap repositories and addons and post another log when you have issues with legit media - you are violating forum rules that you agreed to when signing up here.
so long,
Hias
It's available as an addon in the Tools section of the LE repository.
so long,
Hias
I'd recommend also monitoring signal strength / quality at both ends.
On the RPi you should have a bar indicator roughly showing it, and your AP/router may have that, too (my OpenWrt router shows link quality of each connected wifi device).
5GHz wifi has benefits if your device is near the router, but if there's a wall in between things can change drastically and 2.4GHz may be the better choice (so that's not actually a workaround but a wise decision based on physical facts - higher frequencies are affected more by obstacles like walls than lower frequencies).
so long,
Hias
Cris_ the hint is/was in the crash dump:
At the very beginning it says it crashed in thread 1:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xf7853198 in strlen () from /usr/lib/libarmmem-v7l.so
[Current thread is 1 (Thread 0xc8cfc240 (LWP 1657))]Then a bit down look at the backtrace of thread 1 and you see it crashed in pvr.iptvsimple - that's the offender
Thread 1 (Thread 0xc8cfc240 (LWP 1657)):
#0 0xf7853198 in strlen () from /usr/lib/libarmmem-v7l.so
#1 0xe56ce2c0 in ?? () from /storage/.kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.20.3.1
#2 0xe56cd0f0 in iptvsimple::utilities::FileUtils::CopyDirectory(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) () from /storage/.kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.20.3.1
#3 0xe56a91e4 in ?? () from /storage/.kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.20.3.1
#4 0xe5678b80 in ?? () from /storage/.kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.20.3.1
#5 0xe567af48 in ADDON_Create () from /storage/.kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.20.3.1
#6 0x00a94db8 in ADDON::CAddonDll::Create(KODI_ADDON_INSTANCE_STRUCT*) ()
#7 0x00a95358 in ADDON::CAddonDll::CreateInstance(KODI_ADDON_INSTANCE_STRUCT*) ()
#8 0x00a9574c in ADDON::IAddonInstanceHandler::CreateInstance() ()
#9 0x00d4da20 in PVR::CPVRClient::Create(int) ()
#10 0x00d57704 in PVR::CPVRClients::UpdateAddons(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#11 0x00d7e630 in ?? ()
#12 0x007e54bc in CJobWorker::Process() ()
#13 0x0085e640 in CThread::Action() ()
#14 0x010b9d08 in ?? ()
#15 0x0085bc94 in ?? ()
#16 0xf4e9d8bc in ?? () from /usr/lib/libstdc++.so.6
#17 0xf503224c in ?? () from /usr/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)so long,
Hias
The log shows several wifi disconnects and reconnects. Got a new neighbor or one of them switching APs maybe? Unfortunately these things are kind of normal with WIFI, best solution is you switch to ethernet LAN or powerline (the latter can be a bit unreliable, too though, but is in general far more reliable than wifi).
so long,
Hias
"m" means the driver is built as a module (which will be loaded on demand, if the device is present) whereas "y" means it's baked into the kernel so the driver code will occupy RAM on all machines, even those that don't have the device and don't need it.
so long,
Hias
If you get the issue with latest LE10 nightly as well then please post a debug log - mediainfo of a problematic file and a sample could be useful too.
Another thing to try would be overclocking the RPi (RPi2/3 h264 decoders are clocked a bit low and struggle with higher bitrate/fps videos), eg try adding these settings to config.txt
core_freq=500
h264_freq=500
over_voltage=6so long,
Hias
For Generic/x86 the kernel config is located in projects/Generic/linux https://github.com/LibreELEC/Libr…nux.x86_64.conf
so long,
Hias
No need to reinstall everything, just build the image, copy the tar file from the targets folder to the update directory/share of your LE installation and reboot - this will do a normal update.
so long,
Hias
It's highly unlikely you'll damage your monitor if you select a resolution listed in it's EDID.
Damaging monitors was an issue with CRTs some 30+ years ago if you exceeded the specs - later CRTs were clever enough to check the signal and show a warning in that case.
It's quite common that computer monitors with HDMI inputs also support SD resolutions so you can hook up eg a DVD player.
BUT: computer monitors often have rather poor scalers, so in that case you might get better picture quality by letting LE do the SD->HD upscaling - I see NUC mentioned in your sig, that should be able to do high quality scaling.
In that case only enable the native resolution of your monitor in the whitelist at all refresh rates (except 25 and 29.97/30Hz as mentioned in the wiki) or the commonly used higher consumer resolutions (eg 1920x1080 and maybe 1280x720). If you use eg a 1920x1200 monitor it may only support 60Hz at the native resolution but offer 1920x1080 at 50 and 59.9x Hz as well.
So, you'll have to check yourself which combination gives the best picture results.
so long,
Hias
