Posts by HiassofT

Have a look at the gpio-shutdown dtoverlay https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/readme#l692-l721

By shorting pin5 and pin6 on the GPIO header you can shutdown LibreELEC and if you then press the button again it'll power up again.

so long,

Hias

A faulty SD card might cause those issues but most of the time it's the power supply. Amp rating on USB chargers usually doesn't mean much and/or the USB cable might not be up to the job and cause a voltage drop. The RPis, especially 3B and 3B+ are very picky about that.

You can easily check that, use the RPi running LibreELEC for a while then ssh in and run

vcgencmd get_throttled

If you get anything else than throttled=0x0 you have a problem.

so long,

Hias

I'm not 100% about the audio issues. Analog audio out of the RPi isn't great so almost no one uses it. Some time ago audio quality was improved via a firmware update (see this thread here Analogue audio testing - Raspberry Pi Forums) but this seems to have caused higher GPU load and people reported issues with HEVC playback or deinterlacing.

Going the HDMI route isn't easy, if you use HDMI then the analog video output will be disabled.

Probably the easiest and cheapest method will be to use one of the plenty RPi soundcards. Hifiberry, Iqaudio, Justboom, Pimoroni pHAT DAC and several others work out of the box (some need a dtoverlay line added to config.txt) or if you want it cheap get some RPi soundcard with a PCM5122 or PCM5102 from Asia - they should work fine as well and provide a lot better audio quality than the on-board output.

so long,

Hias

If you add overscan settings in config.txt you also have to set overscan_scale=1, otherwise the settings don't apply to kodi (they only affect the framebuffer that's shown during boot). While that removes the borders you'll still get a stretched display on 16:9 screens in anamorphic mode which you'll need to compensate for in kodi screen calibration.

So, it's better to use only kodi's screen calibration to set both the corners and the aspect ratio, that's easier to do and also avoids having 2 scaling steps (one from kodi and one from the firmware).

so long,

Hias

This is normal. ICE1724 only supports 32 bit format and the default alsa configuration (default:0 pcm) uses the dmix plugin with a fixed 48kHz rate - this is identical to how it works on other Linux distributions.

You either need to access the hw: device in 32bit or use plughw so it can auto-convert other formats to 32bit.

so long,

Hias

This change has been included in Linux kernels for almost 11 years now.

commit d16be8ed69f3e59d36be8c422508c3a10082fdaa
Author: Pavel Hofman <[email protected]>
Date: Thu Mar 20 12:10:27 2008 +0100


[ALSA] ice1724 - Improved the Juli rate setting

If you have issues we need some more info and a description what exactly doesn't work.

so long,

Hias

The log shows you are running some community build from early October 2018

18:50:00.767 T:139930272209024  NOTICE: Running on HTPC (community): devel-20181005235021-6499607 9.0, kernel: Linux x86 64-bit version 4.18.10

Can you please test with the latest official LibreELEC version (currently 8.95.002)?

so long,

Hias

Quote from giaur509

Actully better to bui air mouse remote, looking how does it work after drop old remote.conf it's not worth, at least for me, not enough patience to use ir remote now. No matter what I do or configure, unable to fire fast events by continous fast key press, it's very frustrating especially when I need to scrool down 100 channels in pvr mode. I would advice to return back to remote.conf until this issue is resolved but I know this is not gonna happen.

If you want precise control then use an IR remote using the rc6 protocol (eg Microsoft MCE remote) or the rc5 protocol (eg Philips or Hauppauge remotes).

IR remotes using the NEC protocol (eg most of the cheap remotes from Asia) won't work as precise as the former ones as there's no toggle bit in the protocol.

You can work around to some extend by reducing the IR timeout (ir-ctl -t ...) but in the end you got what you paid for

so long,

Hias

Just tested and it's working fine here in Austria on RPi3B+, LE 8.95.002, Netflix addon v0.13.21, inputstream.adaptive v2.3.12.0.

IIRC I usually needed to restart kodi (or reboot LE) after widevine updates, otherwise I'd get the spinning circle and was then dropped back to the list after a couple of seconds. So doing a reboot after widevine installation or update won't hurt.

so long,

Hias

Quote from roel

This is a line I was already searching for a long time ago and eventually figured it out myself. This should be put somewhere in the LibreElec remote wiki. It would have spared me a lot of time figuring everything out.

To be honest, as well the kodi wiki as the libreElec wiki are a little bit confusing about this matter.

I just added a paragraph to the Introduction section of the IR wiki page, with links to the relevant kodi wiki pages. Hope this makes things clearer now.

so long,

Hias

Quote from giaur509

Can I bring back old approach with remote.conf from LE 8 without need to recompile image?

No, this stuff is gone for good. AML now uses the same method to support IR remotes as all other platforms.

so long,

Hias

Quote from giaur509

I am still confused with that. In general, no lags but if (for example) I keep pressing Down button very quickly, 1 of 3 events are lost.

This is caused by a combination of using remotes with the NEC protocol (which doesn't have a flag if it's a new button press) in combination with the old 3.14 kernel (which is missing the IR optimizations found in current linux kernels).

You can get better remote response by running

ir-ctl -t 30000

Just add it to autostart.sh (you can test with lower values, down to 10000-20000 as well)

so long,

Hias

Best stick to the kodi button names in the devinput section of Lircmap.xml and use the keycodes that are mapped to kodi buttons (eg KEY_INFO, KEY_MENU, KEY_FORWARD, KEY_REWIND, ...).

A full list of kodi button names is in the IRTranslator source file irtranslator.cpp#l164-l229

As explained in the Kodi wiki LIRC - Official Kodi Wiki remote button mapping is a two-step process. First Lircmap.xml maps a KEY_xxx code to a kodi button name and then you assign actions to kodi buttons in remote.xml

so long,

Hias

What kind of remote are you using and did you create the IR keymap file by yourself?

If you create an IR keymap it's best to stick to the keycodes that are usually found on remotes (see eg the rc6_mce keymap of the Microsoft MCE remote) as these will work out-of-the-box in kodi. More details are in the wiki Infrared Remotes [LibreELEC.wiki]

If you are using an RF remote it's not using the ir-keytable configuration discussed in this thread - in this case please open a separate thread.

so long,

Hias

Remote input is handled differently than keyboard input.

Kernel input events from remotes are translated to lirc events by eventlircd, then received by kodi as lirc events and run through the Lircmap.xml -> translations in Kodi and are finally mapped by <remote> blocks in keyboard.xml files.

so long,

Hias

Thanks a lot for testing!

It'd be best to contact Matt Flax (who created the card and wrote the driver) and tell him that the driver doesn't work on kernel 4.19. He can then submit the required changes to the RPi kernel where we will pick them up.

Opening an issue on RPi kernel github would be another possibility, but as probably only Matt has the hardware and knows what to change contacting him directly would probably be easier/quicker.

so long,

Hias

Could you check if the card works in Raspbian with kernel 4.19?

First install Raspbian Stretch and add the soundcard config, the card should be detected.

Then run the following command to switch to kernel 4.19

sudo BRANCH=next rpi-update

Then reboot and check if the card is still detected.

The LibreELEC kernel config looks fine (all drivers should be there) but IIRC the Audioinjector Octo driver was dropped for some time in kernel 4.19 because it didn't compile - maybe the driver isn't fully working yet in kernel 4.19.

so long,

Hias

In general I2S soundcards should work fine, but I'm not familiar with the audioinjector octo card.

Can you please post the full dmesg and vcdbg log msg output?

vcdbg log msg 2>&1 | paste
dmesg | paste

You seem to have dtparam=audio=on in config.txt, drop that, it's not needed. Also not sure why you have spi=on and i2c_arm=on in config.txt- the devicetree overlay should enable all components so in general it's enough to add the dtoverlay line.

so long,

Hias