So it's really an access right problem and thanks to HiassofT the issue described in post #12 can be fixed:
Posts by ghtester
-
-
Thanks a lot, the thread is then resolved.
-
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 directoryThe 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.
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).
-
Try to connect through SSH before the issue happen. Then let the box to fell into idle state and you should be still able to display the kernel log with dmesg command to see what happened.
-
-
-
As the issue persisted in nightly-20231219-865d980 (RPi4.aarch64) as well, I had to analyze it & find the reason.
It looks in kernel 6.6.7 the old mapping file format is not supported anymore. I think it should not fail with Segmentation fault but...
It was necessary to reenable kernel IR protocols (for instance ir-keytable -p lirc -p rc-5 -p jvc -p sony -p nec -p sanyo -p mce_kbd -p rc-6 -p sharp) and convert the mapping file to .toml format. Then it works again.
-
Thanks as well but I believe there's no issue with the path. In fact the script works even in autostart.sh (LED can be turned on/off) except the input button.
btn = Button(5, pull_up=False)
the kernel log:
export_store: invalid GPIO 5
When the path is wrong, the script fails at import command which is not the case.
-
Thanks but it looks gpiod is not present in LE12.
As mentioned earlier, I have already updated the python script to use gpiozero instead of RPi.GPIO.
It worked fine until recent nightly builds. Now it still works but not from autostart.sh and I can't find the reason.
-
The issue still persists after upgrade to nightly-20231216-63347fc (RPi4.aarch64).
-
After upgrade to nightly-20231216-63347fc (RPi4.aarch64) my IR remote stopped working.
I am using gpio_ir_recv and found the custom mapping does not work anymore.
Found /sys/class/rc/rc0/ with:
Name: gpio_ir_recv
Driver: gpio_ir_recv
Default keymap: rc-rc6-mce
Input device: /dev/input/event1
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 rc-6
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay: 500 ms, repeat period: 125 ms# ir-keytable -a /storage/.config/rc_maps.cfg -s rc0
Segmentation fault (core dumped) -
The issue described in post #12 still persists after upgrade to nightly-20231216-63347fc (RPi4.aarch64) with kernel 6.6.7.
-
You should be able to find a wrong time offset somewhere, perhaps in TVH.
Look here: https://tvheadend.org/boards/5/topics/33166?r=33175