Posts by rooty

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?

Quote from 5schatten

rooty

libreelec-generic.x86_64-9.1-rr-20190327-59f53c8.tar

works like a charm! thanks

Quote from 5schatten

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.

Quote from 5schatten

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.

Quote from 5schatten

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.

Quote from 5schatten

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

Quote from 5schatten

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..

Quote from 5schatten

Basically this needs to be added

yes

Quote from 5schatten

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.

Quote from escalade

If you have an EFI system, the file should be /flash/EFI/BOOT/syslinux.cfg

that just an example, the actual commit is here

Quote from 5schatten

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.

Quote from 5schatten

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_v2

It'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_barrier

Some 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 .

Quote from 5schatten

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.

Quote from 5schatten

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

Quote from 5schatten

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 .

Quote from 5schatten

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.

Quote from 5schatten

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 nvUvmInterfaceChannelDestroy

I don't have nvidia kernel module installed, tho wondering if this is normal behavior

Hey 5schatten, do you think it will be hard to implement dm-crypt into LibreELEC RR? Pretty much this is the only thing which prevents me from switching my current dist to LibreELEC RR

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?

Thanks

5schatten, nah, I wish. The Add-on:Transmission - Official Kodi Wiki is just a front-end (UI) for the actual transmission daemon. It talk to transmission rest api. I also thinking about just to use a docker container as an alternative for this.

Quote from 5schatten

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.