So far no change on the intention to support VNC, right?
We'd like to support it, but it requires some non-trivial coding to be done by someone other than us. I wouldn't expect to see anything in the near to mid-term future.
So far no change on the intention to support VNC, right?
We'd like to support it, but it requires some non-trivial coding to be done by someone other than us. I wouldn't expect to see anything in the near to mid-term future.
Dec 08 22:01:19.029867 LibreELEC systemd-tmpfiles[372]: Failed to create directory or subvolume "/root", ignoring: Read-only file system
Dec 08 22:01:19.030097 LibreELEC systemd-tmpfiles[372]: Failed to open path '/root', ignoring: No such file or directory
Dec 08 22:01:19.042294 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.042863 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.043498 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.045806 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.046319 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.047311 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.048826 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
ekerose ^ this makes me wonder if examining the SD card in another OS has borked ownership of /storage. I have a hunch sshd is preventing the creation of keys belonging to root (user 0) in folders owned by another user (1023, who doesn't exist in LE).
I don't use my own servers, I see everything through external Libreelec links. I haven't downloaded anything for years, all streaming and torrents
Pirates are not welcome here: Forum Rules
bosko1333 Initial support for the RK3588 SoC and core board peripherals are not merged into the upstream kernel and it will take time to work on u-boot support and media drivers etc. once those are finally merged. I'm sure we will have RK3588 images in the future, but right now it's way too early to think about creating anything. LE is not interested in images based on the vendor kernel (which is also incomplete but does exist). If the community wants to play with the vendor kernel it's welcome to.
Original RPi HDMI Adapter and Power Supply
^ is this a PSU for the original RPi, i.e. 1st/2nd/3rd gen, or an original RPi4 PSU? .. there's an error in the kernel log which looks like a firmware crash, and one possible cause for that kind of thing is an inadequate power supply. No guarantees that's the issue with video output, but low-spec PSUs surface all kinds of odd problems and RPi4 needs a PSU that delivers more amps than earlier models.
Good Kodi playback performance requires a combination of the right kernel version (and patches) + ffmpeg version (and patches) + Kodi version (shouldn't need patches). LE runs latest version kernels with patches (largely developed by LE devs) that improve codec and overall decoding performance that are regularly upstreamed but anything not a bugfix won't filter back down to the LTS kernels Armbian uses. LE also uses a more minimal/reduces kernel config that will be a little lighter on boards and latest versions of mesa. As userspace apps need to be aligned closely with kernel capabilities Armbian is probably using the default FFMpeg compiled with Kodi (right version but missing patches) or a general upstream FFMpeg package (not quite the right version, also missing patches). If you custom build Armbian with the same kernel/ffmpeg/mesa version and patches LE uses you should get a similar overall experience.
You can try forcing a specific resolution by appending e.g. "video=HDMI-A-1:1280x720M@60" to kernel boot params, but if the graphics card in the PC doesn't support that resolution it probably doesn't result in working output. As a general rule you're stuck with whatever the card can output (and TV can display) and in this case it looks limited to some basic VESA resolutions.
In post #188 the problem is reported against the Generic 'GBM' image which doesn't have any trace of Xorg libs inside. Generic-Legacy still uses X11 so the libs will be present.
@chewitt my update for the dreambox patches.
Yes, this is the same change that I made (but didn't share). Nice to know that it works.
There is also a problem with SSH. When trying to connect it shows an error:
The logs show this endlessly repeating:
Dec 11 16:06:02 LibreELEC-Penka systemd[1]: Starting sshd.service...
Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: RSA Could not save your private key in /storage/.cache/ssh/ssh_host_rsa_key.XXXXl8cxAN: No such file or directory
Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: ECDSA Could not save your private key in /storage/.cache/ssh/ssh_host_ecdsa_key.XXXXl7zlJv: No such file or directory
Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: ED25519 Could not save your private key in /storage/.cache/ssh/ssh_host_ed25519_key.XXXXAdmsHi: No such file or directory
The /storage/.cache/ssh directory should be created on first boot automatically so I've no idea how that can happen.
NB: I've not made any changes to Ethernet support in the 6.0.x kernel but perhaps there are general cleanups that improve things.
rmmod r8712u
insmod /usr/lib/kernel-overlays/base/lib/modules/6.1.0-rc8/kernel/drivers/staging/rtl8712/r8712u.ko debug=0x1416
Mind the line wrap ^ above; remove and reinsert the driver with a debug option and then see if anything more was printed to dmesg? - If yes, run "dmesg | paste" and share the URL. If nothing.. I'm out of ideas, other than removing the staging driver and digging up an older vendor driver. The TODO file in staging points to https://github.com/chunkeey/rtl8192su as an alternative; you can probably cp -R an existing realtek driver package.mk and swap the URLs/GitHash details to build it; if it builds.
rellla The plumbing for hardware deinterlace in FFMpeg under V4L2 has been figured out (for RPi, and similar works with other devices) but right now there is no support for the hardware deinterlace IP on Amlogic SoCs in Linux, so FFMpeg will fall back to software (Yadif or Bob, I forget which) sampling. It's watchable for normal media but anything sporting with faster panning shots isn't so great. I'd pay someone to write the driver code if I could find someone to pay..