Posts by chewitt

I'm not sure about LE10 images but LE11 nightlies is 'Yes' assuming the hardware supports it.

You will probably want/need inputstream.adaptive installed.

dm140 is not in the upstream lcdproc code (it was refused due to licensing issues https://github.com/lcdproc/lcdproc/pull/47) so the easiest thing to do is probably to build the add-on yourself with edits made to the patch that we use to add support. If you are only modifying existing lines in the patch e.g. to use different USB IDs then the line-count of the patch will not change and it will still apply when LE buildsystem compiles the add-on. There is no need to change the module name to amc570.so. It's probably not too hard to do, but it's not necessary.

patch location packages/addons/service/lcdd/patches/lcdd-0.5.6-dm140_henlar_v0.2.patch

Remove the Pi board from the Argon case. If the problem still exists we're interested in diagnosing further. If it doesn't exist (and it probably won't) you can join the long queue of users and project staff that are getting a bit fed-up with the random problems those cases add.

Quote from kiai

Where do i get a 9.x LE image for berryboot ?

Get a spade from the garden shed and start digging downwards. When you reach the depths of Hell you will find an LE image for BB.

Use the AMLGX "box" image and set the dtb name to boot in uEnv.ini, then trigger recovery mode so it searches for the boot scripts included in that image (which are similar but slightly different to legacy ones). The "lepotato" image is designed for booting an actual LePotato board using mainline u-boot which uses a completely different extlinux.conf boot layout.

The short answer is 1) No, 2) No.

The Python 3.9 bump is causing issues in a few places - notably one of the caching add-ons that's consumed by some streaming and skin add-ons. It's not anything specific to my images (or LE) and will probably get resolved upstream soon enough.

2022-02-21 09:48:57.848 T:1008     INFO <general>: VideoPlayer::OpenFile: /var/media/sda1-usb-General_USB_Flas/test/kodi/iphone6s_4k(h.264).mov

RPi hardware (all generations including RPi4) does not support 4K H264 hardware decode, so the file is being software decoded and that's going to suck and drop frames like crazy.

If you want to disable MPEG2 in the driver that patch will still work (nothing changed in the driver). One of the HardKernel forum regulars has started to look into it .. but he's still in the early stages of tracing what the code actually does.

If anyone is using a Tanix TX3-mini box (S905W) the VFD display is now supported in my test images with upstream code! .. as this series was posted to the mailing list https://patchwork.kernel.org/project/linux-…[email protected]/ and I've added the super-simple clock script here https://github.com/chewitt/LibreE…401de6c2979fdd7 to put some numbers on it. In time (and assuming the driver patches are merged) someone with a bigger clue about Python than me will be able to resurrect the fd628.service add-on we've had in the past as that was fancier, but that involves Python, which I suck at. NB: There's also no guarantee the above driver will work on other boxes with VFD bits, but it's a start in the right direction

Quote from deffffz

same here to be honest - rebooting after every episode watched so I switched to mainline nightlies instead

Provide a proper debug log.

It's not a complete debug log. There is no explanation of what hardware the problems is seen on. The filename shows it's something you've probably downloaded from a torrent site. Oh dear..

Quote from tomaszc

chewitt maybe these files stay somewhere on the server and you could share?

I use my own images for testing, not nightlies, so I don't have old images anywhere and the current test server holds one or two days files and then deletes them. I also have no stability issues (within the normal range of what works/doesn't-work with the vdec) so your problems are probably a skin or some add-on not being happy about the recent Python 3.9 bump in master.

Quote from powerarmour

48Hz movies are certainly bad enough.

No TV panels have native modes at that refresh though, so you won't see it advertised via EDID or used, unless you forced it somehow and then the bad results are entirely your own problem.

Look at the overlays configuration in cmdline.txt for the LE 9.2.8 image and replicate that in boot params with the other distro. If the kernel versions match you can take our overlay files too. If they don't .. the sources for the overlays can be found in our repo and you'll have to compile them to match the kernel the other distro is using.

Amlogic G12B hardware (inc. VIM3) has working H264, working 8-bit VP9 and working but imperfect HEVC decoding in the LE codebase and no support for 10-bit media or encoding. I run zero testing with conventional desktop OS like Ubuntu so cannot speak for how well our patchset might work in browsers or with WebRTC applications.

https://github.com/LibreELEC/LibreELEC.tv/ <= all sources (URLs or patches) are clearly listed here. If you want proper support and assistance with the upstream codebase I'd suggest you reach out to the Amlogic kernel maintainers at Baylibre who authored most of the drivers - who would love someone to fund more man-hours of development time so they can add more functionality and finish/polish features.

The Slice DAC requires a device-tree overlay, but this is pre-configured in the LE 9.2.8 'Slice3' image, so what image are you trying to use?