Frankly, raid isn't going to help you with data loss. RAID is not a backup,
That's totally not true. I had two HDDs with mirroring raid configured in the past, where the primary HDD died, and I spent about just 5 minutes recovering the whole system (swapping the dead HDD, making the second HDD the primary).
frakkin64 Please read again my post #13 . My point was we have potentially many more people than 20. Here's the "use-case" that happened personally to me: my hard drive died - all data were lost. I have no intention/interest in having NAS in my apartment. I'm not forcing you or anybody to use this feature; in fact, this could be disabled by default. What I'm saying is that it would be cool to bundle the tools with the image so that people who are interested could use it. Judging from sky42 commit diff, it's not a lot of new dependencies
where does it stop though?
It stops after raid support. It's up to the devs to decide how this will be implemented and how to make it simple to fit into a "Just enough OS" approach. We, users, can just share our thoughts on what we'd like to see, but in the end, it's up to the devs to make the final decision
sky42 shares images that have all the RAID modules/tools and encrypted disk stuff included. Last time I looked there were ~20 active users...
With due respect to everyone, that's because most of the users prefer to use the official builds since a) typically, we want to be able to upgrade from LE instead of the manual process, b) most importantly, usually, the devs of custom builds tend to release their build for some limited period of time, and after that, they just disappear (which is entirely ok, don't get me wrong).
I'm actually surprised as well that LE does not support simple raid 1 (mirror). Although I understand the "Just enough OS" approach, I think raid 1 and partition encryption sound like a basic/essential requirement. Anyway, this is my imho
hey guys, so this is it, the dist is dead 
Does anybody know by the chance is it possible to upgrade from this distribution to another, or will it most likely get broken?
I guess if this would be a common problem many users would complain about it
But that's what I'm trying to explain, by default this is disabled . If you didn't turn it on, it's disabled for you, same as for many users.
When this is disabled you don't care about 23.xx Hz media because automatically that becomes 60 (or whatever your kodi defaults) Hz media. By enabling the option video plays even more smoothly, so I like to use this option.
Well it's an Arch image for PCSX2 not for any other purpose. If you want to use a Docker image for building purposes then you should have a look at
ah, I see. No, what I meant is to build a docker image with LibreELEC to test stuff, not the opposite 
. So let's say I'd like to bundle my own package to LibreELEC build and I also want test it. It's kinda time consuming to deploy the image to a device after each compile procedure, would be cool to make docker image instead to plug the image with docker and test a package right away.
You have to consider that escalades build was LE 8.2.x + Kodi 17.6 and mine is based on LE 9.x + Kodi 18.1
Yeap, I do keep in mind that. In fact, first thing I was checking is Kodi as there's different major version, but my search brought me to what I've shared.
I use the variable refresh rate on all of my systems so ARM & Intel based systems and some with AVR and had no problems as far as is can tell.
So, you're saying you have this enabled on your x86_64, and you don't experience any audio delay for 23-24 Hz media? 
5schatten I'd like to bring up one more thing to discuss.
I spent like a day to figure out why my audio is out of sync with video, delay is ~200ms (at some point I figured out it's actually 175ms, *sigh*)
This happens only when "Adjust display refresh rate" is enabled, so I'm guessing that's why we don't really have a lot of complaints. This was not the case in escalade's build.
I found a solution online to create advancedsettings.xml with some settings, tho I didn't like this approach so I decided to ask this question at Kodi forum. Mr fritsch pointed me to check advancedsettings.xml, I was sure the file was not created......I was wrong *sigh* . It's actually packaged.....in here "/usr/share/kodi/system/advancedsettings.xml" .
Then I was wondering why escalade's build was ok, and I found this . Apparently this audio delay fix is obsolete and now it causes this issue.
Do you think it's worth to merge the escalade's commit or at least give some notes at the first page. Thanks
I've updated the Docker images
how did you build a docker image with LibreELEC and all dependencies? I've been trying to find this for awhile, so far found zero informations in LibreELEC docs.. 
Basically this needs to be added
yes
did you run any benchmarks with these settings
I ran some benchmarks in past, not in LibreELEC tho. As I said this is really application dependent, means no sense to run 3rd party benchmarks. I haven't found any native kodi benchmarks, still trying to figure out the best way to test it. Probably also worth to test with Dolphin, haven't found how to do that but this article.
If you have an EFI system, the file should be /flash/EFI/BOOT/syslinux.cfg
that just an example, the actual commit is here
Anyway at least this paper outlined a poc where a malicious java script is able to read cached passwords from the webbrowser. So it's probably a problem too if you use Chrome though I don't know if this normally expects sandboxing.
Both Firefox and Chrome made Spectre/Meltdown attacks via JS impossible quite a long time ago.
Pretty simple -> if you apply some kernel switches can you give a brief summary what you've added to disable them? Or are you going to disable them in the kernel config?
So my current setup is:
# cat /proc/cmdline
root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1 BOOT_IMAGE=/KERNEL boot=UUID=5C89-FBCB disk=UUID=16a7ebdb-fbf2-40e6-af03-a812e8cd0864 quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
# ls -1A /sys/devices/system/cpu/vulnerabilities
l1tf
meltdown
spec_store_bypass
spectre_v1
spectre_v2It's done by
# cat /flash/syslinux.cfg|grep APPEND
APPEND boot=UUID=5C89-FBCB disk=UUID=16a7ebdb-fbf2-40e6-af03-a812e8cd0864 quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrierSome related articles can be found here, and here .
Some mitigations were not disable because I didn't do microcode rollback, too much hassle I guess...
A note here, in case if discrete GPU is present, it's probably useless to spend time on this ^^, for LibreELEC purposes...
btw,
5schatten escalade I've found interesting article: FFmpeg Has Seen Some AVX2 Optimizations For VP9 Decoding .
but afaik it's partly about isolating memory content from access of other software so i.e. one website shouldn't be able to read your protected account data from another one
not really, well kinda... those vulnerabilities are dangerous for multi-user scenario, something like: lets say there's some machine with root user and some unprivileged users (no sudo/root access), so by using the vulnerabilities the unprivileged users can access content in the memory that does not belongs to them and technically they can steal sensitive content from root, also in most cases they can get root access. Now just think about those guys like for example AWS EC2 or Google GCP. They provide a set of virtual machines (VMs) and containers (maybe better term is paravirtualization here) that are running on a single machine (hypervisor). So attacker can use these vulnerabilities to steal data from neighbors or even to get access to neighbors environment. Now back to LibreELEC topic, we have just a single user aka root, so potentially if somebody will steal your credentials to ssh under root to LibreELEC - this person basically already will be full privileged user, he don't need to apply these vulnerabilities since full access is already granted.
Anyway those patches are included in bios updates, kernel firmware and finally in in the kernel itself. If you think it's worth it then feel free to disable them, I'll stick to the LE upstream kernel as far as possible.
So let's make it clear, I'm talking about kernel space.
If you pay close enough attention you find a switch. There's a switch which disable these patches, so why do you need it? Yeap, because of performance issues. At this point I don't understand LE upstream committers. There's no point to use these patches at LibreELEC, it slows down the system. I have a feeling that they just too busy with other things or just not fully aware concerning this situation, and these patches are enabled by default, for security reasons,... which is not the case for LibreELEC as mentioned above. 
And now comes the question! 
What the level of regression.... for let's say Kodi and related libs? This is highly application/code dependent. For MySQL myisam the level of regression is 40% (just en example), there're apps where regression is just about 5% .
Some more benchmarking can be found here .
This is just fyi, to bring some clarity into this, I work as a system engineer and have some knowledge
For sure I will disable this for myself, tho some people might ask a question like: why my 4k blu-ray/mkv(whatever) movie of jellyfish has some frameloss, it was not the case few kernels ago,..... or maybe not 
Btw. a lot of lr cores like mame2010, scummvm, yabause etc. already use -O3 as GCC optimization so I hardly doubt you'll see any crucial performance improvements.
I feel like now everything loads much faster, but I'm pretty sure it's a placebo effect .
if you have to tweak GCC optimize options to make things run properly you better think about upgrading your hardware
I have skylake arch, i5-7260U . It's more like for fun, to activate all force of the cpu 
I remember we did some tests at work and we found some applications perform much better on non-standart compile flags, tho an environment quite different.
just made a build with march skylake and -O3 optimization, so far everything looks good, wondering what the best option to benchmark it
5schatten, a though concerning Spectre & Meltdown vulnerabilities... It's a known fact that related patches for the vulnerabilities are slowing down an OS.
I know those patches are crucial for hosting companies for obvious reasons. As for LibreELEC we basically have just root user so I feel like it's useless to have them enabled.
Well I've talked about that with sky42 in the past and he provided some patches in his git repo. I have only basic knowledge about that topic but it could be possible to implement that with some help & beta testing
Sounds good, I'll take a look into this, will try to help you guys
few questions... did you try to compile with native march flag? Just wondering is it going to work, something like:
sed -i'.original' 's/$TARGET_CPU/native/g' config/arch.x86_64
PROJECT=Generic ARCH=x86_64 BUILD_PERIODIC=RR BUILDER_NAME=5schatten BUILDER_VERSION=XXX make image===
For now I'm just playing with it, trying to compile this at a machine with glibc 2.27 installed... do you think should not be any issues on a target with glibc 2.29?
Also I'm getting this
Successful build, creating image...
depmod: ERROR: fstatat(6, nvidia.ko): No such file or directory
depmod: WARNING: /home/stan/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel/image/system/usr/lib/kernel-overlays/base/lib/modules/4.19.27/nvidia/nvidia-uvm.ko needs unknown symbol nvUvmInterfaceDisableAccessCntr
depmod: WARNING: /home/stan/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel/image/system/usr/lib/kernel-overlays/base/lib/modules/4.19.27/nvidia/nvidia-uvm.ko needs unknown symbol nvUvmInterfaceChannelDestroyI don't have nvidia kernel module installed, tho wondering if this is normal behavior