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
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.
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:Shell-Script
- # 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
It's done by
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...
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:
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 thisCode
- 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 nvUvmInterfaceChannelDestroy
I don't have nvidia kernel module installed, tho wondering if this is normal behavior
hey escalade , could you please share how do you make a build with avx2 support? Haven't found anything related in here https://github.com/escalade/libreelec.tv/blob/le82/projects/generic/options , do you have some separate branch for that?
Not really since I don't use it myself Maybe if sky42 will build some stuff for LE9 I'll can "copy paste" it
5schatten I'll try to bundle bittorrent to the dist then if you don't mind (if you do please let me know, haha). Should be pretty easy as soon as I understand how to build this stuff
Few questions tho.
Are the build commands up to date: GitHub - 5schatten/LibreELEC.tv: A bit more OS for KODI ;-) ? This is pretty much what you use, correct?
How do you usually test an image (build), do you use virtualbox or something?
By disabling hardware acceleration (VAAPI) I was able to get rid of artifacts, of course there're consequences: my CPU load bumps up to 80%. Trying to dig more.