Posts by chewitt

I use an Apple Airport Express WiFi basestation in Wireless Bridge mode for development as it means I can just connect an Ethernet cable and whatever board I'm playing with gets an IP address without having to muck about with WiFi drivers or configuring a connection. The last one I purchased (admittedly a couple of years ago) was about $20. It's not a blistering fast wireless connection, but it's "fast enough" for streaming moderate bitrate content for LE box/board testing and means I don't need to run a cable through three walls.

TL/DR; any bridge device, or any router that can be configured as a bridge, is what you need.

An S905 can almost handle 1080p HEVC in software so MPEG2 at 720p/1080i should be do-able. It would still be nicer to have proper hardware decoding.. but that needs someone to take an interest in the vdec code. MPEG2 isn't a complex driver, and it's likely broken due to a few small changes due to general V4L2 evolution since it was first written, but we're approaching three years since someone last seriously looked at the code and it appears nobody (who can code) cares enough to look.

If you're using the Slice remote, turn CEC off in Kodi settings (CEC is what will be waking the TV)

Quote from PhoenixBG

Is there progress on regression in MPEG2 hardware acceleration (S912 SoC's) ? Or perhaps, can you add separate switch for turning MPEG2 acceleration ON/OFF ?

One of the HK forum regulars started to look at the MEPG2 code, but then stopped, and that was a year ago. It's probably easiest to just drop support for MPEG1/2 in the driver. This will force FFMpeg to decode in software. As MPEG1/2 media is almost always SD it's not challenging to handle in software - as much as it would be nice to use hardware decoding.

Quote from ekerose

The problem I suspect appears when in uenv.ini you force ssh.

Random suggestion .. use Notepad++ to edit the file, not Notepad or Wordpad - if you're a Windows user?

Quote from PackElend

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

Quote from deleonkikko

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.

Quote from PackElend

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.

For clarity, what remote are you using?

Quote from PackElend

that was done a few days ago, have check the OP, point 3 and 4

Run "journalctl | paste" approx. 1 minute after system start and share the URL generated. Points 3 and 4 tell me what you think is important and useful to know, not what I think is important and useful to know.

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.

Remove "quiet" from boot params in cmdline.txt and then look for errors on-screen during boot.

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.

Apparently 10.0.3 is the latest release, I thought we were onto 10.0.4 already.. my bad.