so to prevent FS corruption you need to either
- shutdown the RPi (system will umount all mounted disks)
or
- in an terminal run "umount /var/media/*" or better "sysnc && sync && umount /var/media/*"
before unplugging the disk.
Or just use the "remove media" option from the context menu in the video files view.
so long,
Hias
Booting is handled by the bootloader in the RPi's EEPROM.
You can configure where to boot from (SD, USB, network) and then it'll search on these devices for a FAT partition (on SD/USB) containing firmware files (http://start.elf/fixup.dat).
So if you don't have a FAT partition on your 6TB the RPi won't boot from it - the bootloader will scan through the USB devices and spin it up though (to read the partition table).
cmdline.txt on the boot partition then determines which partitions LE should use for boot/flash (pointing back to the boot partition) and storage - by default these will be the ones from your LE installation (eg on SSD).
During bootup LE will then scan for all USB devices and mount all partitions (except boot/flash and storage, which are already mounted) in /var/media so you can access them - here your 6TB HDD will get mounted.
so long,
Hias
You could try using the official RPi imager tool to write RPiOS or LibreELEC to the SD card, IIRC it will do a verify pass after writing the image to SD card
Other disk imaging software might have a verify function, too, if yes use it to verify if the SD card is actually OK (SD card, card reader on your PC could all be faulty meaning you would be chasing a ghost searching for an issue on the RPi side).
so long,
Hias
Just run pastekodi again, sometimes the paste-site has hiccups (I've seen that lots of times myself).
Black screen can have lots of causes, just do a forum search and you'll find plenty of hints and/or answers.
so long,
Hias
Broken RPi, SD-card reader or SD card are all possible causes for the symptom of not blinking ACT LED.
An easy standard thing you could try is inserting and removing the SD card a couple (10 or 20) of times - that'll clean contacts and it might start working again.
Also make sure the SD card locks in nicely, the spring-loaded SD card slot on RPi2 was a PITA and often failed.
Trying with yet another SD card, also with RPi OS, would be another option.
so long,
Hias
This sounds like the RPi can't read from the SD card - see here for more info
STICKY: Is your Pi not booting? (The Boot Problems Sticky) - Raspberry Pi Forums
so long,
Hias
I have a similar issue on a Rpi3. I have stutter, no video when playing back X265 files using kodi matrix 19.4. I was sure I had viewed the videos previously, so I dug out an older version. This works flawlessly. Don't know if this is a OS or kodi issue, but reverting back to kodi 18 sorted me.
That's a different issue, accelerated H265 decoding is no longer available in LE10 on RPi2/3 - see the release notes
LibreELEC (Matrix) 10.0.2 - LibreELEC
so long,
Hias
Please read the OP before replying with an answer.
I have read your post and the linked thread, please read my posts as well and try what I suggested.
First of all the first thread you linked to is rather old, and while systemd-inhibit can still be used it's recommended to configure that via logind.conf.d
There are actually two different things in play: one thing is system(d) handling of power/sleep/... buttons the second one is how kodi should handle those.
You need to solve the systemd handling first. stop kodi (systemctl stop kodi), run evtest (from system tools addon) to find out the input device of your remote and then run evtest --grab /dev/input/eventX (replace eventX with the one matching your remote) and press the power button on your remote - this will tell you if it's sending KEY_POWER or KEY_SUSPEND or something else.
Then setup logind.conf to ignore that key. Reboot, stop kodi again and verify that your system does not power down when you press the button.
Once you got that working you can start configuring kodi.
so long,
Hias
CvH is there a guide somewhere on how to update to current Kodi master branch version when building LE for RPi?
In theory that would be really simple (change version to latest kodi githash and update or comment-out the SHA256 line) but with recent kodi versions there will be a conflict with the PR20006-gbm-colorspace-and-bits-per-pixel patch which needs to be updated (I can have a look but not before next week or so).
so long,
Hias
why the smart-assed comment from a Dev? It seems inappropriate, regardless of what poster says
I have no idea what you mean.
But I can tell you that not every remote sold as "MCE" is adhering to the original Media Center Remote standard - the well known Ortek / Hama remote for example and there's numerous others.
"MCE" has become a generic term nowadays and the OP hasn't told us yet which specific remote and IR receiver he's using.
And I can also tell you that you may need to ignore suspend/sleep/power handling in systemd in such cases and that matches the symptoms the OP described. So it's well worth a try checking that.
so long,
Hias
On a second thought BT.601/709 handling should be fine:
For YCbCr planes kodi sets the COLOR_ENCODING (601/709/2020) and COLOR_RANGE (limited/full) properties so the YCbCr conversion to internal RGB (where plane composition is performed) should be correct.
If the output connector Colorspace prop is set to Default the driver chooses the RGB->BT.709 matrix if YCbCr output is enabled. This can happen with 10bit 1080p output on a HD TV.
Usually we'll output RGB though so no conversion will be applied at the output stage and C0=0, C1=0 correctly indicate the RGB colorimetry (C0=1 or C1=1 would be invalid for RGB output)
We might have a theoretical problem though if we would output YCbCr at an SD resolution (where HDMI default is BT.601 but the driver would apply the BT.709 matrix) but that would be a rather rare corner case:
You need to play 10bit SDR content and have the display resolution set to SD in combination with a TV/monitor that doesn't support 12bit RGB so the driver chooses YCbCr 4:2:2.
so long,
Hias
That's now made me question how Rec 601 output is handled (given the very different RGB<->YCbCr matrices that Rec 709 and Rec 601 have) wrt 'default'?
Phew, that's indeed a tricky question. Maybe popcornmix can give some more detailed info (or correct me)?
If I understood CTA-861 correctly "default" (i.e. C0 and C1 both zero) means SMPTE 170M/BT.601 for SD and BT.709 for HD resolutions. But I'm not sure what exactly happens when RPi upscales SD video to HD - the SD video probably would be BT.601 but the output then HD BT.709.
The video plane usually is in YCC but internally it gets converted to RGB before it's being mixed with other planes (eg overlay), then an output conversion can get applied (eg to again convert it to YCC).
Dave fixed the various conversion matrices in this commit https://github.com/raspberrypi/li…b3a04238134aace PR discussion is here https://github.com/raspberrypi/linux/pull/4932 but it doesn't seem to mention BT.601 and SD->HD upscaling so I can't tell if this is handled properly (my guess is outputting SD content at SD resolution should work).
so long,
Hias
See here: RE: Remote power off button is different at kodi 17 then at kodi 18 whe using LE
Your NUC, running X11, works differently than RPi and most likely you are using a remote with a receiver which "looks like" a keyboard to the system. You have to configure systemd to ignore it, otherwise both it and kodi will react to the (sleep?) button. On RPi also keyboard-like devices get grabbed exclusively by kodi so systemd doesn't "see" the button press at all.
so long,
Hias
Out of interest is bit-depth checked irrespective of EOTFs - i.e. does a 1080p50 10-bit HEVC SDR Rec 709 file get output in a 10-bit or 12-bit mode?
Yes, this is done independently.
The logic inside kodi is quite simple:
If the video driver supports the colorspace property it'll set it to "BT2020" for BT2020 videos or "Default" (i.e. usually BT709) for other content.
HDR metadata is handled in a similar way (set if driver supports it and we have it, unset or untouched otherwise).
If the video bit depth is higher than 8bit and the video driver supports the max_bpc property it'll set it to 12 - so you'll usually get 12bit RGB or YCbCr 4:2:2 both for SDR and HDR 10bit content.
By default (eg in GUI) max_bpc is set to 8 so we get 8bit RGB output (YCbCr 4:2:2 won't be considered by the RPi video driver as it's a 12bpc mode).
The Kodi PR that adds this logic is in LE RPi builds but still under discussion at Kodi side - see https://github.com/xbmc/xbmc/pull/20006 - so there might be changes or extensions in the future.
The various video drivers work slightly differently or don't support all combinations (eg due to hardware limitations/bugs).
For example Intel doesn't support YCbCr 4:2:2, only RGB, YCbCr 4:4:4 and YCbCr 4:2:0 so it might be an option to set max_bpc to 10 to get 10bit output or don't set it at all (IIRC Intel defaults to 12) to let the driver choose some supported format.
Or, eg on RPi, maybe an option to always keep it at 12 to avoid mode switches between GUI and 10bit video playback.
I guess in the end we might see some config setting to control behavior, similar to "adjust refreshrate on playback".
so long,
Hias
If you are concerned about security and you want to run kodi then it might be best to think about running it on a completely separate system.
Why? There are numerous issues in media decoders and kodi bundles an outdated ffmpeg version which might have various security issues. In addition to that media decoders like h264 and hevc run in kernel space and are likely to contain security relevant bugs, too. In that case a container won't help you much if you find a way to trigger a kernel bug via some (streamed) media file.
As RPiOS is a bit slow with kernel updates it's also not the best choice if you are concerned about kernel security problems - distros following mainline kernel (eg Debian) will be a lot faster shipping security patches - but of course they won't contain the not-upstreamed media codecs so are not a good choice for Kodi on RPi.
LibreELEC will be even worse as kernel updates are shipped as part of the system and can't be upgraded - and LE10 uses kernel 5.10 which is now on bare life support from RPi.
And, there may be another practical argument for running RPi with kodi on a dedicated system: performance. RPi4 is pretty much at the limit with H264 1080p60 and HEVC 4kp50/60 decoding and output - containers running in the background might ruin your movie evening.
so long,
Hias
We have nothing planned/decided yet.
And as it's holiday season and lots of us (and most likely also Team Kodi) are traveling and/or spending time with their families it's unlikely we'll do a LE10 release within the next few weeks.
so long,
Hias
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
