Posts by ghtester

Thanks for the info, so the issue is not so fresh.

It looks something has changed in some of recent updates (currently running 13.0-nightly-20240725-2cd39ba (RPi4.aarch64), issue observed on 13.0-nightly-20240720-ab27426 ) that broke kodi-send:

# kodi-send
Traceback (most recent call last):
File "/usr/bin/kodi-send", line 27, in <module>
from kodi.xbmcclient import *
ModuleNotFoundError: No module named 'kodi'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/kodi-send", line 30, in <module>
from xbmcclient import *
ModuleNotFoundError: No module named 'xbmcclient'

Perhaps some paths needs to be updated?

Quote from adam.h.

Thanks chewitt, just verified that the fix works on x86 as well.

Then please mark the thread as Resolved.

Great, thanks for a quick fix!

On my RPI 4B the IR Remote also stopped working after upgrade to LibreELEC-RPi4.aarch64-13.0-nightly-20240614-18becd8

Analyzed the issue a bit and it looks ir-keytable does not see the rc0 device anymore but rc1 instead in my case.

ls /dev/lirc*
/dev/lirc0 /dev/lirc1 /dev/lirc2

ir-keytable

Found /sys/class/rc/rc1/ with:
Name: gpio_ir_recv
Driver: gpio_ir_recv
Default keymap: rc-rc6-mce
Input device: /dev/input/event3
LIRC device: /dev/lirc1
Attached BPF protocols:
Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm
Enabled kernel protocols: lirc nec
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay: 500 ms, repeat period: 125 ms
Found /sys/class/rc/rc2/ with:
Name: MyGica Mini DVB-(T/T2/C) USB Stick T230C
Driver: dvb_usb_dvbsky
Default keymap: rc-total-media-in-hand-02
Input device: /dev/input/event4
LIRC device: /dev/lirc2
Supported kernel protocols: rc-5
Enabled kernel protocols: rc-5
bus: 3, vendor/product: 0572:c689, version: 0x0800
Repeat delay: 500 ms, repeat period: 125 ms

As the default device is still /dev/lirc0, then some commands like irw does not work.

cat /etc/lirc/lirc_options.conf
# These are the default options to lircd, if installed as
# /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
# manpages for info on the different options.
#
# Some tools including mode2 and irw uses values such as
# driver, device, plugindir and loglevel as fallback values
# in not defined elsewhere.

[lircd]
nodaemon = False
driver = default
device = /dev/lirc0
output = /run/lirc/lircd.socket
pidfile = /run/lirc/lircd.pid
plugindir = /usr/lib/lirc/plugins
permission = 666
allow-simulate = No
repeat-max = 600
#effective-user =
#listen = [address:]port
#connect = host[:port]
#loglevel = 6
#release = true
#release_suffix = _EVUP

#logfile = ...

[lircmd]
uinput = False
nodaemon = False

# modinit is not supported in LibreELEC

# [modinit]
# code = /usr/sbin/modprobe lirc_serial
# code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
# code2 = ...

irw
Cannot connect to socket /run/lirc/lircd: Connection refused

The /etc/lirc/lirc_options.conf file is read only and currently I don't know how to easily change the device configuration to /dev/lirc1 as the shadow file in /storage/.config/ folder did not help.

But maybe it's a wrong way anyway...

You have to put the pieeprom.bin file to /tmp folder first - as outlined above, see Is it possible already to set up a rpi4 with kernel 5.4? - General Support - LibreELEC Forum

Reenabled the Weather add-on to confirm the issue reason but the Kodi crash did not happen anymore (on the same LE Nightly version as recorded in the latest log above...

Now I plan to upgrade to LibreELEC-RPi4.aarch64-13.0-nightly-20240517-8f6f9a1 with the Weather add-on enabled and I'll see...

Edit - after upgrade the issue reappeared... So I am disabling the Weather add-on (Gismeteo vl.maksime - 0.6.4+matrix.1) again...

Thanks a lot for the feedback, tried to apply your advice and so far it works - no crash in last couple hours while using Kodi as described above.

Firstly observed on latest LE12 Nightly versions, after upgrade to LE13 the issue is still there. Ocassional Kodi crashes when watching LiveTV using Tvheadend42 & DVB-T2 USB key. The crash usually happen sometimes, as soon as I go to TV/Channels/All channels menu or open the TV Guide (TV/Guide/All channels menu).

Hopefully you can find the details in the logs:

https://paste.libreelec.tv/simple-lark.log

https://paste.libreelec.tv/tidy-bug.log

https://paste.libreelec.tv/legible-dane.log

https://paste.libreelec.tv/evolving-vervet.log

Quote from FRACTi0N

i can confirm this is happening to me as well for last couple of years. no matter tvheadend or kodi version. I have observed, that this happens also when recording a tv show, so this looks more like a tvheadend server bug. Also from what i see, it happens to ghtester in czech republic, which is the same location as mine, so it may be the connected with h.265 codec, which is used here for dvb-t2...

Yes in the Czech rep. it's a bit specific situation due to h.265 codec so I understand that developers from other countries (where the h.264 is still in use) don't see any issues.

I am recording the tv programs exceptionally so I did not encounter the audio issue in this case - but when tested the behavior with bad signal level, during play of the recorded file the audio could be recovered after a temporary loss but this did not happen during live TV play of the same interval of the same program (and the audio stayed muted).

BTW. I see that tvheadend server has more troubles with channels using fast data stream (CT1, CT2 - h.265, 1080 HD), where especially the timeshift often fails after some time.

Quote from smp

It's probably related to AAC audio. See here.

Thanks for the link, unfortunately it seems it can't be fixed...

So it's really an access right problem and thanks to HiassofT the issue described in post #12 can be fixed:

RE: Raspberry Pi Tools - GPIOZERO - LE12 Issues

Thanks a lot, the thread is then resolved.

Quote from Mario77

you don't seem you found any solutions on that thread either?

That's correct, unfortunately. In my case output commands worked but the input button generated an error (when called from autostart).

BTW. recently updated System Tools also made some of my scripts unusable so it's perhaps a good idea to stay on stable version for now.

It looks I am not the only user with this issue:

Raspberry Pi Tools - GPIOZERO - LE12 Issues - Add-on Support - LibreELEC Forum

The python script using System Tools stopped working on my RPi 4B running LE 12 nightly-20231231-dfd843f (RPi4.aarch64)

It looks at least paths has been changed so the add-on is not backward compatible anymore and the script failed with error message:

File "/storage/.config/shutdown.py", line 25, in <module>
import RPi_I2C_driver
File "/storage/LCD/RPi_I2C_driver.py", line 16, in <module>
import smbus
ModuleNotFoundError: No module named 'smbus'

After updating path in the script

from sys.path.append('/storage/.kodi/addons/virtual.system-tools/lib')

to sys.path.append('/storage/.kodi/addons/virtual.system-tools/lib.private')

the error message has changed to:

File "/storage/.config/shutdown.py", line 25, in <module>
import RPi_I2C_driver
File "/storage/LCD/RPi_I2C_driver.py", line 17, in <module>
import smbus
ImportError: libi2c.so.0: cannot open shared object file: No such file or directory

The directory content is:

~/.kodi/addons/virtual.system-tools/lib.private # ls -l
total 3092
-rw-r--r-- 1 root root 266408 Dec 22 11:44 libfuse.so
-rw-r--r-- 1 root root 266408 Dec 22 11:44 libfuse.so.2
-rw-r--r-- 1 root root 266408 Dec 22 11:44 libfuse.so.2.9.9
-rw-r--r-- 1 root root 67552 Dec 22 11:44 libi2c.so
-rw-r--r-- 1 root root 67552 Dec 22 11:44 libi2c.so.0
-rw-r--r-- 1 root root 67552 Dec 22 11:44 libi2c.so.0.1.1
-rw-r--r-- 1 root root 619176 Dec 22 11:44 libonig.so
-rw-r--r-- 1 root root 619176 Dec 22 11:44 libonig.so.5
-rw-r--r-- 1 root root 619176 Dec 22 11:44 libonig.so.5.4.0
-rw-r--r-- 1 root root 67824 Dec 22 11:44 libulockmgr.so
-rw-r--r-- 1 root root 67824 Dec 22 11:44 libulockmgr.so.1
-rw-r--r-- 1 root root 67824 Dec 22 11:44 libulockmgr.so.1.0.1
-rw-r--r-- 1 root root 68944 Dec 22 11:44 smbus.so

Look at my experience here: RE: LE 12 Nightly - RPI tools add-on issue

My experience is (using USB to SATA & SATA HDD to boot & run LE) like described in my previous post. If the boot device is unmounted and there's SSH connection already, it's not dropped and some commands (including dmesg) still works.

But of course it's not able to make a new SSH connection anymore (even if the boot device is remounted).

That's not my case. I have no problem with configuration from scratch, even with fresh configuration there are some issues I had already reported here (yes I should perhaps put the reports to Kodi & Tvheadend forums as well but as the both are used in LE, I thought some day the reports could be reflected). Unfortunately as the issues are related to DVB-T2 which looks to be less used across users, the priority is low. I respect that free time of developers is limited but it's true TVH progress is very slow. Nevertheless, yet TVH 4.2 is a great product and still better product than others (I have tested) and than TVH 4.3 as well.

Quote from petediscrete

I’ve been using 4.3 Alpha for quite a while and have found no issues or incompatibilities. Could you elaborate a little.

Please look at some of my earlier posts. I was experiencing a configuration issue with adding the first DVB-T network / channel. There's also an incompatibility with Kodi - subtitles are not shown at some DVB-T channels (in fact shown 'behind the corner' while recording is OK including subtitles). I can't remember any advantage of 4.3 over 4.2 so after a long torture with subtitles issue (tried to find the root of the issue but failed and nobody here could help), I have finally reverted to 4.2.

Now I am observing if the another annoying and old issue with randomly undetected audio streams is also related with TVH 4.3 or if it's the same with 4.2 (the next possible reason could possibly be the USB DVB-T2 tuner).