Posts by chewitt

Use the Generic x86_64 image .. shouldn't be any drama (famous last words)

G12A support (which is the target of commercially funded work) needs to reach the same level of incomplete as GX and then video work (which is largely common to both) can continue. There is already 4k 8-bit support, but as most 4K video uses 10-bit formats that's not so useful. Intel's HDR plumbing is also starting to fall into place so we've started to look at what Kodi needs to use it. There is also refactoring/rework of the ffmpeg stateful code as we learned lots from writing stateless support for Allwinner/Rockchip. It's all green-field coding so it's often a "two steps forwards, one step backwards" process. The nice thing is that we've successfully positioned Kodi (and LE) as the go-to demo application for a number of development efforts which is attracting some nice contribution from the wider Linux community - although a lot of the activity isn't public visible. GXBB devices like the WP2 have a few quirks that need to be ironed out (currently a bug in audio support) but we'll circle back on that generation shortly.

The X96 device tree describes the x96max remote, hence it works OOB. If you can point me at a working remote keymap for the Y5 we can create a device-tree that does that same thing.

Some comments:

WiFi on S905X2: may not be supported for a while yet, or at all. S905X2 has a design flaw in how the SDIO module is internally connected and while an egregious hack/workaround exists in Amlogic's 4.9 kernel it's looking unlikely that a cleaner solution acceptable to upstream kernel maintainers can be found. We might attempt a mainline kernel version of the egregious hack through a local patch, or since the majority of users stream media over Ethernet anyway, we might just leave it unsupported and avoid the support/maintenance work. The issue is allegedly resolved with the S905X3 chip which is already being sampled to manufacturers.

Device trees: The mainline kernel avoids the silliness of 1G/2G/3G variants needed on the legacy kernel which makes life easier, but we will still need to figure out (and then upstream) the device trees for popular devices. I'm keen that device trees are sent upstream so that devices can be uniquely identified by "compatible" strings in the device-tree, as this allows simple things like the remote control keymap (also sent upstream) to be described in the device-tree for a better out of box user experience. Submitting changes to the kernel is not the most straightforward process but if non-coding folk like myself can figure it out (my personal collection of one-line kernel changes is slowly increasing) the bar is not set impossibly high.

arm vs. aarch64: performance is marginally higher on aarch64 but arm allows us to support widevine drm (which is not available in 64-bit format) so arm is our preferred option and official nightlies and the Kodi binary add-ons to match them, once they start, will be arm only. Maintaining a single image for all Amlogic hardware (two images until panfrost evolves bifrost support) is a bigger win than the minor performance gain. On G12 hardware the future gain from running the CPUs at full speed (at the moment they are under-clocked) will dwarf the architecture difference.

Our packaging for Samba (where files live) is a little different to conventional distributions but we provide /usr/bin/smbpasswd so you can create and maintain a Samba credential file somewhere on /storage that's referenced from samba.conf. There shouldn't be any functional need to run Samba in a container at all if you use the right configuration. NB: You're straying firmly off the trodden path from an LE use-case perspective and should not expect detailed support for things like TimeMachine backups, but our Samba is just Samba and such things should be possible.

You're asking a relatively niche question so answers might take awhile. You need to be patient.

Docker (Community Edition) is the application that supports 'containers' from the linuxserver.io "docker repository"

Nope. Use the backup and restore feature in the settings add-on.

Quote from icefox

I've enjoyed LE but maybe key devs have moved on to this branch, like how they moved from openelev to LE.

Incorrect. It's not at all like the OE move where the entire team (literally everyone minus one) moved on to leave the single problem developer to work by themselves. Only the two developers that proved themselves unable to work to the standards set by the rest of the team moved on. The rest of the team are intact and the Amlogic mainline kernel change is our focus. The key developers and active contributors towards the future of Amlogic working on that are all here and things in the mainline camp are moving along quite nicely. There are event test images available in these forums.

GitHub - LibreELEC/service.libreelec.settings: the LibreELEC settings addon for KODI is the source code. It's possible to clone the add-on and run it under a different ID to the one embedded in the image (same as other Kodi add-ons) but remember that python code is compiled before it runs so you need to develop/learn a workflow of making changes, cleaning the compiled files out, restarting the service, test, etc.

"ThePlayersKlub" is a pirate IPTV service so you're asking for advice in the wrong forum.

I can't speak for Ubuntu (someone else's problem) but under LE we implement various "high quality shaders" to handle those functions. Some of them are configurable, others are not.

We validate the md5sum of the KERNEL/SYSTEM files in the .tar file, not the actual .tar file.

Images for G12 devices (X96/N2, etc.) are still rather "work in progress" in places. You only need to do "touch /storage/.update/.nocompat" but that will need another Linux device to mount the SD card from. It's probably easier to create a clean SD card.

A.S._id read the error message on the screen and do what it tells you (create .nocompat)

pan.rozowy mainline kernel images will not support SSV wireless chips due to the driver code being utter rubbish and SSV going bust in 2016 which all but guarantees nobody will update the driver code. We did have a go at updating the SSV6051 driver but ran out of enthusiasm due to it being such awful code. Use a wireless Ethernet bridge .. better performance and more future-proof than USB wireless dongles (beware that we are unlikely to add support for cheap Realtek WiFi chip devices due to Realtek code also being low-quality).

<profiles>
    <lastloaded>0</lastloaded>
    <useloginscreen>false</useloginscreen>
    <autologin>-1</autologin>
    <nextIdProfile>1</nextIdProfile>
    <profile>
        <id>0</id>
        <name>Master user</name>
        <directory pathversion="1">special://masterprofile/</directory>
        <thumbnail pathversion="1"></thumbnail>
        <hasdatabases>true</hasdatabases>
        <canwritedatabases>true</canwritedatabases>
        <hassources>true</hassources>
        <canwritesources>true</canwritesources>
        <lockaddonmanager>false</lockaddonmanager>
        <locksettings>0</locksettings>
        <lockfiles>false</lockfiles>
        <lockmusic>false</lockmusic>
        <lockvideo>false</lockvideo>
        <lockpictures>false</lockpictures>
        <lockprograms>false</lockprograms>
        <lockgames>false</lockgames>
        <lockmode>0</lockmode>
        <lockcode></lockcode>
        <lastdate></lastdate>
    </profile>
</profiles>

^ that's the default content of /storage/.kodi/userdata/profiles.xml if you want to recreate it

No idea. Android has a large SEP field around it.

Quote from sinisab89

Hi!

I have a WiFi problem with LibreElec. I get low speed and high ping and I dont know why. My device is Tanix TX3 Mini - H, 2GB RAM 16GB mem with SSV6051 WiFi chip inside. Dtb is glx_p281_2g and it boots nice and fast. Signal strength is 75%, it connects to WiFi with no problem but I cant get more than 9Mb/s. I have 20Mb/s ADSL. Android on this same device goes up to 18Mb/s, this version of LibreElec goes to 9Mb/s, LibreElec 8.2 goes up to 12Mb/s and CoreElec 9.0.1 goes only to 4Mb/s. With higher speed ping gets smaller. Can't figure out the problem, it's strange how different versions behave differently with wifi. Is there something I can do to fix this behavior cause I would really like to use LibreElec on my box, Kodi works so much better than on Android...

Get an Ethernet bridge and you'll get proper wifi speeds .. and you'll avoid the future issue that SSV6051 will not be supported on mainline kernel images due to the driver being dreadful crap that we couldn't port (we tried, but, eww.. it's sucky code). It's no surprise that SSV went bust in 2016