Please note TVH 4.3 is still just Alpha and has some strange issues & incompatibilities with Kodi. So I recommend using TVH 4.2.
Posts by ghtester
-
-
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) -
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
-
A strange issue started to happen after upgrade to latest Nightly builds with kernel 6.6.2
The python script to run in background from autostart.sh now does not work due to error generated after Button configuration:
btn = Button(5, pull_up=False)
the kernel log:
export_store: invalid GPIO 5
But when the same script is started manually from SSH console after OS boot, it works without issue.
Could somebody explain this behaviour and give an advice how to fix it please?
I tried to put a time.sleep (30) before the Button command but it did not help, so it looks like some access rights issue?
-
OK, it works after some struggling.
10. Migrating from RPi.GPIO — GPIO Zero 1.6.2 Documentation
To control the GPIOs from shell:
# gpiodetect
gpiochip0 [pinctrl-bcm2711] (58 lines)
gpiochip1 [raspberrypi-exp-gpio] (8 lines)
# gpioinfo
gpiochip0 - 58 lines:
line 0: "ID_SDA" input
line 1: "ID_SCL" input
line 2: "SDA1" input
line 3: "SCL1" input
line 4: "GPIO_GCLK" output consumer="lg"
line 5: "GPIO5" input bias=pull-down edges=both consumer="lg"
line 6: "GPIO6" output consumer="lg"
line 7: "SPI_CE1_N" input
line 8: "SPI_CE0_N" input
line 9: "SPI_MISO" input
line 10: "SPI_MOSI" input
line 11: "SPI_SCLK" input
line 12: "GPIO12" input
line 13: "GPIO13" input
line 14: "TXD1" input
line 15: "RXD1" input
line 16: "GPIO16" input
line 17: "GPIO17" input
line 18: "GPIO18" input active-low consumer="ir-receiver@12"
line 19: "GPIO19" input
line 20: "GPIO20" input
line 21: "GPIO21" input
line 22: "GPIO22" input
line 23: "GPIO23" input
line 24: "GPIO24" input
line 25: "GPIO25" input
line 26: "GPIO26" output consumer="gpio-ir-transmitter@1a"
line 27: "GPIO27" output consumer="lg"
line 28: "RGMII_MDIO" input
line 29: "RGMIO_MDC" input
line 30: "CTS0" input
line 31: "RTS0" input
line 32: "TXD0" input
line 33: "RXD0" input
line 34: "SD1_CLK" input
line 35: "SD1_CMD" input
line 36: "SD1_DATA0" input
line 37: "SD1_DATA1" input
line 38: "SD1_DATA2" input
line 39: "SD1_DATA3" input
line 40: "PWM0_MISO" input
line 41: "PWM1_MOSI" input
line 42: "STATUS_LED_G_CLK" output consumer="ACT"
line 43: "SPIFLASH_CE_N" input
line 44: "SDA0" input
line 45: "SCL0" input
line 46: "RGMII_RXCLK" input
line 47: "RGMII_RXCTL" input
line 48: "RGMII_RXD0" input
line 49: "RGMII_RXD1" input
line 50: "RGMII_RXD2" input
line 51: "RGMII_RXD3" input
line 52: "RGMII_TXCLK" input
line 53: "RGMII_TXCTL" input
line 54: "RGMII_TXD0" input
line 55: "RGMII_TXD1" input
line 56: "RGMII_TXD2" input
line 57: "RGMII_TXD3" input
gpiochip1 - 8 lines:
line 0: "BT_ON" output consumer="shutdown"
line 1: "WL_ON" output
line 2: "PWR_LED_OFF" output active-low consumer="PWR"
line 3: "GLOBAL_RESET" output
line 4: "VDD_SD_IO_SEL" output consumer="vdd-sd-io"
line 5: "CAM_GPIO" output consumer="cam1_regulator"
line 6: "SD_PWR_ON" output consumer="sd_vcc_reg"
line 7: "SD_OC_N" input
# gpioget GPIO17
"GPIO17"=inactive
# gpioset -t 0 GPIO17=1
# gpioget -a GPIO17
"GPIO17"=active
-
I don't expect somebody of developers could have a look on it but there's a log of issue encountered.
It's too big for pastebin so I have used the local sharing platform which can hold it for 30 days:
https://www.uschovna.cz/en/download/MZIDD66ZDCVY2LBS-4F5/5693GL2MA6/
The issue happened at about 9:19 when the short stream data corruption led to silenced audio.
Then I rewound a bit using timeshift and enabled the debug output So the issue repeated again at about 9:31.
I would expect the audio should be restored quickly but it stayed silent.
I also have the stream data recorded (at the time of the issue) by tvheadend but due to format used it can't be easily played.
-
FYI RPI Tools add-on may not work anymore on some LE releases / builds.
I don't know if it could be your case as well or not.
-
Kodi 21 .0-ALPHA3 (20.90.301) is already released in LibreELEC-RPi4.aarch64-12.0-nightly-20230911, unfortunately this issue still persists.
-
Also sometimes the audio stream (usually AAC) is not detected at all after switching Live TV channels, even though the signal quality is great.
This stupid and very annoying issue is still here ( nightly-20230910-09641de (RPi4.aarch64) )
I wonder why this can happen.
-
The 21.0.1.2 version is not compatible anymore and there's no updated version available.
The "solution" is to revert back to LibreELEC-RPi4.aarch64-12.0-nightly-20230829.
-
Still the same issue after upgrade to LibreELEC-RPi4.aarch64-12.0-nightly-20230801-1c44a13.img.gz, there's no update to Raspberry Pi Tools add-on which is still release 11.0.0.0.
-
I am sorry but I have no experience with tv hat as I don't own it. I am using USB DVB-T2 tuners instead so I can't advice.