Posts by chewitt

autostart.sh runs at the start of userspace boot long before networking is up, so the only way to sequence things is backgrounding with a sleep delay and then hoping the timing remains consistent over time. Using a systemd service allows proper sequencing to remove all the guesswork on timing.

If you're using the box image from an SD card the boot params are in uEnv.ini. If you installed LE to the eMMC storage then boot files are a bit different and there's an extlinux.conf file. However, configuring (forcing) an HDMI mode will do nothing when you're connected to the TV with a composite cable. You can try the following but I doubt it will work: video=Composite-1:1920x1080M@60

Use an HDMI cable and you'll get proper modes.

WG support is ultimately all about what's in the kernel (and WG is there) so there's techincally nothing that prevents LE being used to host a server, but there is no plumbing to facilitate that in the GUI or in ConnMan, which is client focussed (and no intent to add anything) so you'd have to self-create whatever scripts are needed to create interfaces and do things on boot, etc.

Quote from intelmorino

There appears to be no meson-g12-common.dtsi, only meson-g12.dtsi.

It's definitely there: https://github.com/torvalds/linux…g12-common.dtsi

[Unit]
Description=Change MTU Service
After=connman.service
Before=network-online.target

[Service]
Type=oneshot
StandardOutput=tty
RemainAfterExit=yes
SuccessExitStatus=1
ExecStart=/usr/sbin/ifconfig eth0 mtu 9000 up

[Install]
WantedBy=network-online.target

Create /storage/.config/system.d/mtuchange.service with ^ then "systemctl enable /storage/.confg/mtuchange.service" and "systemctl start mtuchange.service" .. it's a guess (not tested) but should run after connman starts and before the network goes online.

Run "modetest | paste" and "cat /storage/.kodi/temp/kodi.log | paste" and share the URLs, but the logs will probably just confirm that we don't see normal 1080p modes. You can also try forcing 1080p60 output by appending "video=HDMI-A-1:1920x1080M@60" to kernel boot params in extlinux.conf (on the SD card). This forces the DRM driver to a specific resolution. Resolution is about the modes detected from the EDID data on the HDMI connection, it has nothing to do with CEC. Older TVs are more prone to bad EDID data and that's an era when "HD Ready" TVs with 1080i. Kodi only outputs progressive frames so 1080i will not be selected for output, but those TVs normally have 720p modes that we'd find and use instead. It's always worth experimenting with another HDMI cable and using different HDMI sockets on the TV to see if you get different results.

Quote from moshoodo123

Please do I need to copy any latest box image to /storage/.update for future update?

The LE11 nightly box image or the tar file from my share are fine for updates. I don't increment the version number on my share, but the file dateTime shows you when it was last updated. If it works; keep a copy so you can always revert to it.

1. Update to https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar and see if it gives more resolutions?

2. Known, and rather unlikely to be fixed
3. No idea, best to post separately about it in the main support section.

Quote from ZsoltiD

I have an Amiko A9 Blue TV BOX currently with Android 9. This box has Amlogic S905X3 (A55 64bit). These test images like 'LibreELEC-AMLGX.arm-11.0-nightly...' are compatible with this harwdare

There's no dts for that specific box, but they're all much the same so you can try the following dts:

meson-sm1-h96-max.dts

meson-sm1-x96-air-gbit.dts

meson-sm1-a95xf3-air-gbit.dts

Note that you'll need to disable hardware video decoding (and CPU decode) on an SM1 box; the drivers were written for older GX devices and need major work to make them compatible with newer hardware. Anything @ 1080p should be fine but forget 4K. For that reason CE is still a better option than LE on SM1 devices.

Quote from slartibartfazz

Finally I found time to do a test on NanoPi-K2. Applying the same u-boot patch as for the Odroid-C2 (eth0 delay) works fine for me.

Do you mean this? https://source.denx.de/u-boot/custodi…ot.dtsi#L32-L36

Also, are you testing boot from an SD card or the eMMC module?

Quote from power_g

http://ix.io/4dRK

The log shows odd things with time. It starts on Apr 11, which is the glibc release date (this is normal) which is reset to Jan 01 once systemd starts. This should be corrected once NTP starts, and I see systemd start the NTP setup process, but no requests (hence time remains wrong on the system). I also see timezone service start .. twice, which is odd. TL/DR; no idea what the issue is, but there is indeed something funky happening with time on the box.

Have a look at Zomboid's VPN add-on thread.

It's probably not impossible to switch the root user to an alternate shell, but due to the way LE is packaged and boots you'll probably need to compile a custom image that embeds zsh directly into the SYSTEM file. NB: We use the lightweight busybox 'ash' shell, not bash.

Quote from misterx_2k3

Thanks for the hint, which forced me to get rid of berryboot and try something different, which in the end led to a solution.

I was sure we added a middle-finger icon to the smilies to deal with BerryBoot Q's .. but we appear to have gone polite-mode in the forum at some point. I'll just have to feign surprise instead

AMD support has always been (and continues to be) a little bit of a lottery. It might be worth experimenting with LE11 nightlies; newer kernel and drivers and we also switch from Xorg to native GBM/KMS.

Most of the PVR add-ons in the LE repo are client add-ons, so you will need to have the corresponding DVB server application installed and running somewhere in the network for the client to connect to.

Otherwise the mention of installng a repo and add-ons (with no names) and then PVR sounds a like a user trying to setup IPTV simple with a bunch of pirate feeds. If that's the objective you aren't going to get much help around here. If not the case, you need to explain what you are trying to do in more detail and provide log files to demonstrate/show what the issue is - because it's not clear from your description.

ConnMan stores service profiles in /storage/.cache/connman/<servicename>/settings but the file is owned by ConnMan so it will ignore all changes made while ConnMan is running and may overwrite them at any time. So edits require you to either make changes through the connmanctl app, or you need to "stop > edit > restart" the service to make changes.

You can also try an LE11 nightly (back-up the current /storage/.kodi dir first so you can revert easily) as the nightly image has newer connman and also switched to iwd instead of wpa_supplicant.

LE 9.2 is optimised towards RPi0/1/2/3 hardware (RPi4 is not feature complete) and LE 10+ is optimised towards RPi4 (and RPi 0/1/2/3 are not as featured) using an entirely new/different video pipeline. RPi devs will continue to improve things but I wouldn't expect massive changes in the future. The older RPi display codebase contains quite a few clever hacks that aren't upstreamable and thus deliberately won't be repeated in the newer codebase.