Posts by chewitt

You can also see if an LE12 nightly solves the problem?

Take a backup (in case you want to restore) then update to the current LE13 nightly and test again. Still an issue?

Run "pastecrash" from the SSH console and share the URL

If you grab the relevant Linux, Kodi, and FFmpeg patches (which are probably in jernej GitHub repo; he's one of the Allwinner kernel developers) you should be able to (re)compile things for another distro. There's no HOWTO guide for that kind of thing though, so it'll be down to your tinkering skills.

You need to paste the crash log that demonstrates the play + ffwd/rew + segfault event, not the clean post-crash log that doesn't contain anything useful.

If ffmpeg fails to decode the stream the issue is most likely with ffmpeg support for VAAPI or the Intel GPU driver which provides VAAPI (or an edge case with mesa) so I would start by reproducing the issue on a general purpose distro (in part to prove it's not LE specific) and then report the problem to ffmpeg developers via their 'trac' reporting tool.

Ensure the internal Intel GPU is disabled in the BIOS so only the nVidia card is used, remove the EDID changes from syslinux.cfg, and then use the "Generic-Legacy" image for nVidia GPU support.

NB: Future support is not guaranteed. LE13 dropped the 340.xx nVidia driver this GPU requires as it's not compatible with the latest X11 releases and we haven't yet decided on adding the nouveau driver to the "Generic" image. Even if we do add nouveau, there will be no VDPAU hardware acceleration as this depends on X11.

EDIT: Do not use the LE13 nightly as Da Flex advised because (as noted above) this does not support your GPU any more.

On an ARM SoC device the GPU is used for 2D/3D rendering (GUI) only and hardware acceleration (codecs) are separate things. As Panfrost supports the GPU hardware the GUI works, while decoding requires specific drivers that need adapting to silicon changes with each new chip. The latter are always non-trivial effort and the gene pool of people with the skillsets for the task is tiny; and most of them are commercial developers not the folks working pro-bono that everything normally depends upon. As such the process is slow .. and support probably doesn't exist yet. Over SSH use 'kodi-remote' to press 'o' on the keyboard to bring up the OSD that shows whether you are using (SW) or (HW) decode; but we already know the answer to that.

It's 4K UHD H265 10-bit media that appears to have some kind of DV profile embedded. I can't see anything wrong with the media, but there are numerous things wrong with the current (unfinished since Q1/2020) H265 hardware decoder. At this stage if it works for you that's great. If it doesn't work, there's really nothing we can do, unless you have $250k spare to finance some commercial development to resume/resurrect codec development.

Quote from MrNice

Device is not detected, I think due to Flirc new version.

The owner of flirc says flirc_util should support all their hardware. If your device is not detected you need to get in contact with flirc support and let them investigate.

Quote from chewitt

there's a flirc_uril add-on in the LE add-on repo (install then reboot to use it)

The same flirc_util add-on is available for RPi3 and our Amlogic image (AMLGX) running on an N2 board. In both cases you install the add-on and reboot (until reboot ^ the binary is not in $PATH and will not be found) and then run "flirc_util" and the binary will output a bunch of info, for example:

RPi5:~ # flirc_util 
flirc_util version 11d52588b5a4b3e5c88825888e18ef03ce8658ac [11d5258+]
 Firmware Detected
 FW Version: v4.6.3v4.6.3
    SKU:     Flirc 2.0 [dori]
    Branch:  master
    Config:  release
    Hash:    0x93A109D3

^ hardware detected.

Quote from MrNice

I understand Fliirc command doesn't exist, only flirc_util, not easy to record IR codes. Am I right?

I'm using a macOS laptop and there's a simple macOS (and Windows) app for updating the firmware and configuring flirc dongles (easily downloaded from the flirc website) and for that reason I've never bothered or needed to use flirc_util and cannot speak for how easy or complicated it is to use.

If you are sat behind a computer with macOS or Windows and a USB port. Are you using the right tool for the job?

Quote from raicevic

Up to what version of LibreElec is there a chance it will work on this S905 device?

LE12/LE13 are still supported, albeit with caveats on the state of the hardware decoders in the upstream kernel (read any recent release notes on the main website for more info).

The AMLGX "box" image should work. Most devices with an RTL8189 WiFi chip seem to be S905 (no X) boards and the p200 or p201 device-tree files should work. If the device is S905X then start with p212 Read https://wiki.libreelec.tv/hardware/amlogic first as the instructions for AMLGX are different to other distros and older LE images that use the legacy (vendor) kernel.

The test images here: https://chewitt.libreelec.tv/testing/ have support for the RTL8189 wifi chip. LE release images do not.

The "flirc_util" add-on (complete with flirc logo) is in our repo under 'Program Add-ons' and testing it against your flirc hardware will take 2 minutes. If your flirc hardware shows an error or is flagged as unsupported by flirc software you need to contact flirc, because it's their software. All LE did was compile code from https://github.com/flirc/sdk and package it as an installable add-on.

I only have v2 flirc hardware and "it works for me" so

Is the drive powered from the USB port? or it has its own independent PSU? - and what is the HTPC device?

Share the system log after a successful mounting, e.g. run "journalctl | paste" and share the URL generated.

I assume you mean "flirc_util" and the flirc USB IR receiever device?

If yes, there's a flirc_uril add-on in the LE add-on repo (install then reboot to use it). If for some reason that doesn't work with the flirc USB hardware that you have, contact flirc support and get them to investigate and fix that, and then we can update the add-on.

There are also Windows/macOS/Linux (Debian based distros) installers downloadable from the flirc.tv website.

This shows how packaging could be done: https://github.com/Ran-Thegoth/uwe5622

Might be a newer version? https://github.com/SUISHUI/uwe5622_driver

This seems to have lots of patches: https://github.com/misuzu/uwe5622-nixos but also shows the driver has issues on recent kernels (would be normal for a downstream vendor driver).

Some Armbian fixes: https://github.com/armbian/build/pull/7615

However if you have no intention to work on improving the driver or even working your (not our) draft PR into better shape there's no point in leaving it open to rot on GitHub, so I've closed it.

Arokhaerr I'm not aware of any noteworthy changes to the SSH server between LE12 and LE13 but perhaps delete any stored profile or connection in the app and recreate in case there are cipher changes. Using a normal computer, check SSH in to prove the SSH service is enabled/running and that password auth is allowed. If yes, perhaps clear any stored connection/profile in the app and recreate. We don't change certs after initial boot but the accepted ciphers can/do change over time (albeit not often).