Posts by HiassofT

Quote from JohnWayne111

Any Updates about this bug ?

No.

First make sure you have the hyperion addon version 9.2.0.112 installed - in earlier versions the screenshot function was broken.

I don't have an external grabber but with the internal (dispmanx) grabber on RPi4 the screenshot function works fine in hypercon. If I select the v4l2 grabber the connection log ("Show Traffic" in hypercon) shows that it tries to use hyperion-v4l2 but can't open /dev/video0 (which is expected).

If you can't get it working please post the output of "Show Traffic" after trying to grab a screenshot.

so long,

Hias

There are no downsides using the LibreELEC addon. We regularly update it to current version (though there isn't much happening ATM - we skipped the opencv grabber as that's not used in LE) and as it's created within our build system you can also be sure that it'll work, even if you update LibreELEC to a new version (in which case the hyperion addon will be automatically updated, too).

so long,

Hias

I'm not really familiar what the hyperion installer is actually doing, you'll have to ask on their forum instead.

The main profit of switching to the LibreELEC addon is that we can answer your questions.

so long,

Hias

I'd strongly recommend switching to the LibreELEC hyperion addon, then you'll also get regular updates.

ISTR the hyperion installer copies stuff to /storage/hyperion and modifies /storage/.config/autostart.sh to start it automatically on boot.

It should be enough to backup hyperion.config.json from your current installation, remove the files and directories (including autostart.sh), install the LibreELEC addon and then use the LibreELEC hypercon version to upload your hyperion.config.json file.

See Hyperion [LibreELEC.wiki] and Hypercon [LibreELEC.wiki] and/or search the forum for Hyperion

so long,

Hias

Quote from keeslampers

Has anyone managed to netboot Libreelec on a RPi4 yet?

Yes, I use this regularly for testing master builds.

Note that LibreELEC 9.2.0 has a couple of issues with netboot. I've fixed a bunch of these issues in our development trees a while ago, they'll be included in 9.2.1.

so long,

Hias

Quite certainly Hyperion is the culprit - I'm getting no signal quite frequently here. See this post for a workaround: Hyperion addon does not work with inputstream.adaptive (Netflix etc.) with Pi4

so long,

Hias

What you'd probably want is zswap, not zram, and I'm not too keen on enabling it.

zswap is still marked as experimental in the Kernel config and the info states it's not fully tested and can cause issues. Also the reports of people who tried it are rather mixed (including actual issues). As the stuff occupying RAM in this case is mainly uncompressed JPEG images I also have doubts how much it can be compressed by LZO/RLE.

LibreELEC 10 will swtich to the vc4-kms driver and V4L2 decoders where only a bit of gpu_mem is needed for H264 decoding but a lot of cma memory (curently testing with gpu_mem=76 and cma=256M/512M - 512M cma needed for 4k video playback) so things are going to change quite a bit. If there are issues with cma they'll need to be resolved anyways.

so long,

Hias

systemctl mask is essentially the same as symlinking a unit to /dev/null

LibreELEC stores the systemd user configuration in /storage/.config/system.d instead of /etc/systemd/system - therefore there's nothing in the (read only) /etc

so long,

Hias

111 is rpcbind. If you don't plan to use NFS you can disabling it by masking rpcbind.service and rpcbind.socket

so long,

Hias

Bug reports, especially with detailed info, are always welcome.

For issues in milhouse builds it's best to post in his threads on the kodi forum so everything's in one place.

The dmesg output helped me track down a bug lingering in the pcm512x driver for a long time, I've sent a fix upstream and it's already scheduled for inclusion in the next 5.6 kernel (and will then find it's way into earlier kernels)

ASoC: pcm512x: Fix unbalanced regulator enable call in probe error path - Patchwork

As posted in the milhouse thread I suspect the actual error is with the clock driver of the Hifiberry card (which Hifiberry folks need to look into, I don't have the hardware here to test myself) which then triggered the bug in the pcm512x driver.

so long,

Hias

Quote from mlac99

The original remote is broken, I was thinking of using a second one with this IR reciever. So, I must get another IR reciever ?

Yes. I'd recommend getting an (HP branded) MCE USB receiver, which is very well supported in Linux (and LibreELEC).

so long,

Hias

The logs look fine,

The Ortek IR receiver shows up as keyboard+mouse input devices and isn't handled by the rc-core subsystem so it won't show up in ir-keytable and you can only use it with the remote it was bundled with.

I did a quick test here on RPi4 with the remote+receiver and it worked out of the box.

so long,

Hias

The default RPi4 image has not been changed, reducing CMA memory is a bit risky (it could break "heavier" skins that otherwise work fine on the 2 and 4 GB models), so if you are affected by that issue please reduce CMA memory manually for now.

To be future proof I'd definitely recommend getting a 2GB (or 4GB) model.

so long,

Hias

Just copy the lirc_options.conf file from /etc/lirc/ to /storage/.config and then change the device line from /dev/lirc0 to /dev/lirc-rx.

so long,

Hias

It might be easier to just use the latest nightly build from Index of / , they are built from the LE master branch (so kernel 5.4 and kodi 19) and you can find both img.gz and tar files there. Write the img.gz to a USB pendrive and give that a try.

so long,

Hias

With gpio-ir-tx it's similar as for gpio-ir, you can use gpio_pin=XX to use a different GPIO.

Actually, it'd be best to connect the IR transmitter to GPIO 18 (and use a different one for receive), then you can use pwm-ir-tx instead of gpio-ir-tx (pwm-ir-tx uses the PWM to generate the carrier frequency and is therefor e more precise and less cpu intensive than the bit-banged gpio-ir-tx).

With these 2 overlays loaded you'll get two /dev/lircX devices and you'll need to add some udev rules to create eg /dev/lirc-transmit and /dev/lirc-receive symlinks - it's not guaranteed that eg /dev/lirc0 will always be receive, this may change.

As you already have a working lircd setup you can use that for receive - just change the device in lirc options to the /dev/lirc-receive one.

To use lircd for transmitting you'd need to setup a second lircd instance (separate lircd.socket and lircd.service systemd units plus separate lirc options and lircd.conf files), which is a bit tricky. Also lircd has some nasty bugs when transmitting (I reported that aeons ago but it hasn't been fixed) - so better avoid lircd.

You can use ir-ctl instead for sending, it doesn't require a background daemon and you can simply specify the lirc device and protocol+scancode (or alternatively a raw file which you can capture with ir-ctl -r, if the protocol isn't natively supported by ir-ctl). To find out the scancode+protocol simply run ir-keytable -p all -t on the receiving device and push buttons on the remote which you want to simulate.

Also search this and the raspberry pi forum, I posted several more infos about IR there (search for my username and/or ir-ctl, gpio-ir, ir-keytable).

so long,

Hias

The delay.conf file needs to go into.config/system.d/service.hyperion.service.d/ - you have to create this directory before.

so long,

Hias