The issue described in post #12 still persists after upgrade to nightly-20231216-63347fc (RPi4.aarch64) with kernel 6.6.7.
Posts by ghtester
-
-
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.
-
Thank you for info & offer, in the meantime I have switched back to Tvheadend which works a bit better for my usecase, so I'll wait and give it a try again when the NextPVR updated version is available in LE add-ons.
-
It's the same like in earlier RPi4 LE versions - you need to install Tvheadend add-ons (Services-Tvheadend Server 4.2 or 4.3(Alpha) and PVR_clients-Tvheadend HTSP Client)
-
Is there any positive change in LE 12 Nightly?
-
Well, I don't want deleting the channels and limit to 490 mux only. Hopefully you should be able to find the issue anyway.
Instead, I tried to clear the EPG data in both NPVR and Kodi, restarted both and expected EPG should be clear. But some channels still kept the EPG data in Kodi. Tried to Update EPG in NPVR, only 2 muxes were scanned (514 and 490), NOVA channel (and most others) still empty.
-
ghtester I was just checking why fullmux642 (with Nova) was not working here and I found that it has 2.89% transport errors. with zero in the others (using tsduck).
This is not the correct mux. I have been mentioned NOVA channel (the name with all capitals) which is on fullmux490.
Yes the error rate is a serious issue (for Kodi live play which is unstable then) but this is not the case as this mux has 0% error. So far I was not able to get the EPG from NPVR for channels you can see on recent screenshots.
I cannot speak for other users setup but my TVH streams are passed raw and unprocessed directly to LE client without any issues.
The same here.
In the spirit of the LE project open source solutions will always be preferred over closed source commercial solutions every time. If you’re in any doubt about that just contact the devs/mods for clarification.
Personally I don't care much about closed sources [as it is sometimes the case (at least partially) even in Linux world] if it's working as expected, does not contain any bloats and even available free.
-
OK, thanks for the info, emveepee. I understand the devs priorities. It's good when there're concurrent add-ons and everybody has a choice to select the proper one for his specific use case.
-
The data screen is not supported in either pvr.nextpvr or the API to the backend. never saw the point to implementing providers as it is mainly cosmetic.
FYI in Tvheadend this works fine; if such items are in Kodi, it would be fine to be supported by add-ons as well - it's useful at least for debugging because from Kodi you can't see this info elseewhere (AFAIK) and sometimes you need it.
The signal strength info can be of value but only for digital tuners and is not multi-platform and is sometimes incorrect. I know when my signal is bad by watching but no doubt technical users who are used to it will miss it.
Well, this looks to be a common Kodi's issue. I have reported that in LE forum a couple years ago but nobody from devs cared about it. So I had to make a custom scripts for my tuners that show that info correctly in right top corner when I activate it by button like you see on screnshot in post #14.
Watching TV and doing an EPG update is not supported and will cause issues. If you must do it issue a pkill DeviceHostLinux in PostUpdateEPG.sh
I understand but it "repaired" the tuning (I suppose temporarily and after reboot or NPVR service restart it won't work again).
Thanks for the additional info regarding to PostUpdateEPG.sh.
I don't know how this works in Tvheadend but it's much better for sure (except the occassional EPG database corruption/screwing).
Perhaps you should consider looking for (conditional, configurable) EPG update after switching channels (switching channels in NPVR is very slow anyway, if it ever works, compared with Tvheadend).
QuoteNextPVR logs would tell us why only on frequency is being scanned.
The log posted earlier, hopefully it should be there.
