Posts by chewitt

FWIW .. I was playing the file from an NAS (SMB) device in the network using the low-spec on-board WiFi of the Hub. I'm not aware of any issues with USB read/write performance on Amlogic SoC's but I also never/rarely use local media with any low-power ARM devices; not because they're inherently bad, but because I swap between 20+ devices on a regular basis so everything's in a central place in the network to make that easier.

If you set defaults to -Os it will optimise the image for file size not "running in RAM size" which is the issue. LE sets -O2 which is sensible.

And .. every couple of years some user discovers this wonderconfig they read about called zram, makes a lot of noise, and rushes off to do extensive performance testing that proves zram has negligible/zero benefit in our distro. Boards under 1GB don't have enough RAM to really benefit from loading more things into RAM and 1GB+ we already run everything in a ramdisk so forcing zram use only adds additional overhead.

LibreELEC is an OS not an app. You need to ask the Pi Foundation developers to use the same patch-set as LE when they create Kodi for Raspian. It is not something we can do. The Pi folks know all about our patch-set - they authored half of it.

If I add "mem=512M" to kernel boot params on an S905 device Kodi faults with this error ^

So unless there are improvements to RAM utilisation in the OS or specifically the video stack, Kodi cannot run on 512MB LaFrite devices. I've flagged it to a couple of the developers, but since we are refusing to support 512MB Allwinner devices as being "too small for sensible Kodi use" and the long-term message on RPi 512MB hardware is similar (we will drop support for RPi0/1 sometime soon) I wouldn't expect a surge of activity .. sorry.

It played fine on an S905 device (WeTek Hub) for me. I will dig LaFrite out of a box and test S805X after work later, but I wouldn't expect there to be any fundamental differences.

^ as long as these are set in device options you shouldn't need to change anything else in the build-system *BUT* you will need to make a clean build (remove the entire build.LibreELEC* folder) to ensure the kernel is not build with lima and that all userspace symlinking and compile-linking against EGL and GBM libraries is handled correctly. Your description makes me think you've built with a mesa configuration and then done the switch to mali without doing a clean build after?

NB: It's also worth bumping to mesa HEAD to pick-up all the improvements made since 20.0.x .. lima is still under very active development with small incremental improvements on a weekly basis. It would be a shame to go back to blobs.

Here's my $0.02 theory: Over time the kernel has evolved better power management which means more hardware can go into deeper sleep states. This is great for power efficiency during suspend/sleep but means you might have to apply some configuration to ensure the NIC (or entire device) remains at a high enough sleep state to still receive the WOL packet. I have a huch that the move from older to newer kernel effects the change. I haven't been using x86 kit for aeons so have no idea how you'd prevent deeper suspend/sleep, but it's something to investigate.

Users tend to focus on "my device can do 802.11b/g/n/ac" but in reality WiFi is a lot more nuanced than "n" and "ac" as each country can (and most do) set their own wireless regulations which dictate the radio properties a router can legally use in that country. Until recently forcing a specific country has been a very occasional thing which is why it's remained an SSH console hack. RPi4 appears to be changing the requirement; more users are using its built-in WiFi as it's more usable (RPi3/3+ aren't good for WiFi) and there are a lot more users (RPi4 is popular) and it's somewhat important to set the radio properties of the WiFi card to match the router if you want everything to work correctly. LE master branch (will be LE10) already has the config setting moved to the GUI. Next step will be to add something into the setup wizard. If we create a 9.2.3 release (not yet, but if/when Kodi do an 18.7 releasae we'll bump) I'll ask for the first part to be backported.

I had issues booting GT-King Pro using the original Android factory firmwares as Beelink tweaked the u-boot environment to minimise the point in the boot sequence where u-boot waits for input (e.g. IIRC the power button on the Pro being pressed). This makes the boxes boot a little faster, but also makes them a pain in the rear as you need to press the button at exactly the right time (measured in ms) to invoke restore mode; then u-boot checks SD/USB media for images and finds LE and boots. The official response from their developers is "keep pressing the reset button during boot" and after a few attempts you'll get the timing right. More recent Beelink firmwares appear to be easier to interrupt and work with so I assume they increased the wait period a little. I forget which firmware I have installed now (as only booted it once or twice) but it was from ~October ish last year. It's a nice box once you get over the install hurdle

The /storage/.smb/smb.conf location is not used anywhere in modern versions of LE .. use /storage/.config/samba.conf (rename the sample conf) and set the following values (notice they are uncommented):

# The following are default values for the master selection process

local master = no

preferred master = no

domain master = no

os level = 100

reboot to make the new config active; if /storage/.config/samba.conf exists it is used in preference to the embedded one.

This will not prevent one of the LE devices from being elected master in the event you turn off the server master browser; the system works to always have one elected master. However, with that config and the high oslevel value (lowest is better in an election) the LE devices should conceed the election to the server quickly when it reappears, although quickly is not a word that should be used here.

Check cables .. that's always a source of potential issues. You could also put the AMLGX image at Index of / on a spare SD card and see what things are like under tthe mainline kernel. Video playback in those images has some challenges, but we're interested in HDMI stability, so testing a completely different (but familiar looking) OS on the same hardware might rule in/out a hardware fault.

My recommendation would be to test playback over SMB or NFS .. as this isolates the issue to WebDAV. If it works over SMB .. you can take the issue to the Kodi forums as it's their WebDAV code that's the issue. NB: I'm not sure anyone in current Team Kodi uses WebDAV so it's probably not a well-maintained feature, hence the suggestion.

No harm in skipping if you didn't need the update, but if auto-update is enabled on your end it will eventually auto-update; we didn't enable it for 9.2.1 as we didn't want to force a potentially non-working update on people. Now 9.2.2 is available to fix that we'll turn it on.

Quote from vi7al

1. Could you please share any link where I can track FFmpeg rework mentioned by you (github, whatever?)

2. What would be a proper thread to discuss LE9 nightly builds issues like the one I have with wifi? From my understanding current thread is dedicated to the Oleg's builds.

1. Nowhere exists until someone starts the work.

2. Start a thread under the Amlogic section - it's as good as anywhere for now.

Video playback is still "work in progress" on the mainline kernel but MPEG4 video should be software decoded anyway which should negate that.

Please share a Kodi debug log file (current one is not debug), and upload a sample of the file somewhere so I can download and see first hand. You can remove the file after it's been downloaded.

Neil is overdue on sending a patch that will disable 4K modes for S805X as they are not properly supported and fixing that on a device that is designed to be 1080p only is a super-low priority. That's unlikely to be the problem if you're using a 1080p panel.I don't think it has anything to do with CMA size as the 896MB allocation already fails gracefully to 256MB. Perhaps try building LE without any kernel patches (default kernel only), and if that works start to add back groups of patches (they are somewhat logically sorted and grouped) until something breaks to pin down the issue.

LE settins are not in the pre-defined list because our add-on is an independent background service, it is not part of Kodi.

The bottom-left corner of the web GUI has a "remote" navigation panel that you can use to reach LE settings.

erbas I'm already on Linux 5.6 and will bump LE master to Linux 5.7 around 5.7-rc2 to keep the patch count under control. This means I am always working on a kernel one version ahead of working media_build support (which always lags) so there's no point in adding the drivers. Once video and audio things are more upstream (around 5.8) we can probably realign with the x86_64 kernel version and reintroduce those drivers.

NB: News on the DVB front is that I submitted the missing pinctrl change on behalf of afl1 (his first in-abstentia commit to the kernel) and those are now merged upstream for Linux 5.7 .. and we've been coaching Availink on their efforts to provide public and modernised sources for their demod and some related tuner drivers. The mainline codebase will need someone to write a new V4L2 compatible demux driver, but I think that can be done, maybe by the Availink folks. I wouldn't expect usable code anytime soon, but there's light at the end of yet another long dark tunnel.