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
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.
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:
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 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.
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.
Please note TVH 4.3 is still just Alpha and has some strange issues & incompatibilities with Kodi. So I recommend using TVH 4.2.
The same issue in LE 12 nightly-20231224-8fece3c (RPi4.aarch64)
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)
