Regardless of your current freezing problem, I would not recommend transferring (writing) data via SMB as long as the kernel version used is greater than 6.2.16 and less than 6.10.9. There exists a ugly regression and a high risk that you get corrupt data
[REGRESSION] Corruption on cifs / smb write on ARM, kernels 6.3-6.9 - James Young
Intermittent data corruption probably in Linux 6.6.52 SMB client - Zack Weinberg
Posts by HarryH
-
-
I do not believe that it was the intention of the developers/maintainers ... of LibreELEC was to break something. And the root cause is an edge case in the concept of how lgpio works and not a problem of LibreELEC.
I know it's hard to accept, but if you look in detail, you'll realise that all modern operating systems try to protect themselves against malicious changes. This will also be the reason why most paths are in a read-only file system. lgpio should be able to handle this, but it doesn't automatically. Therefore the needed hint with the working directory.
A customised addon version like the one you provide for users of older scripts as a starting aid is well-intentioned and also helpful for the initial approach. However, it also needs a maintainer for further updates of the included Python modules to ensure compatibility to new kernel versions, RPi hardware versions and so on. Some approaches such as rpi-lgpio are also only a compromise and do not behave identically to the widely used RPi.RPIO in 100% of the use cases. Especially in terms of performance (regarding this gpiozero seems the worst one, because it's a additional layer). So sometimes it is better to deal with the new variants like lgpio or gpiod (libgpiod) directly. Otherwise it's just a long languish.
But that's just my own opinion... -
As long your YAMAHA AVR doesn't pass through the EDID data without cut off the important resolutions/information, Da Flex suggestion is a workaround to use AVR (Audio only) and the TV connection simultaneous.
Do you have already checked if you have the recent firmware version for your AVR? It seems that the AVR currently does something wrong. In most cases, such problems can be resolved by updating the firmware or sometimes by using a different HDMI input on the AVR. -
The script itself is working, but you must add a workaround for lgpio. Please try that version:
Python
Display More#!/usr/bin/python import sys sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib') from gpiozero import LED, Button from signal import pause import os import time # workaround for lgpio issue # https://github.com/gpiozero/gpiozero/issues/1106 os.environ['LG_WD'] = '/tmp' # Stel de LED en de knop in met BCM pin nummering led = LED(6) # Fysieke pin 31 is BCM pin 6 button = Button(13) # Fysieke pin 33 is BCM pin 13 # Zet de LED uit led.off() # Definieer de shutdown functie def shutdown_system(): os.system("sync") time.sleep(1) os.system("shutdown -h now") sys.exit() # Koppel de shutdown functie aan de knop button.when_pressed = shutdown_system # Houd het script draaiende pause()
-
As your RPi is supplied with power via the HAT, you may encounter another problem. You are bypassing the negotiation via the Power Delivery protocol. So I assume the RPi5 is limited to 3000mA by default. Please see my comment from here:
PostRE: [RPi5] HiFiBerry Amp4 Pro
LieberBieber
because the RPi5 is powered from the backside via GPIO, maybe with the Amp4 Pro you are now in the same situation like the Argon ONE V3 users and needs to tell the RPi5 that the used power supply is strong enough. Especially if you have attached additional USB devices.
Try to get it stable with these configuration changes:
Add these lines to bootloader config/EEPROM:
PSU_MAX_CURRENT=5000
and to your config.txt:
usb_max_current_enable=1
Regarding documentation here is a (maybe…HarryHJune 23, 2024 at 12:23 PM -
Have you already tried the slave setting required for the RPi5?
Changes in HiFiBerry drivers | HiFiBerry
If that doesn't help, please enable debug logging, reboot and provide a full debug log: https://wiki.libreelec.tv/support/log-files -
I would like to provide you with some useful links. But I'm not familiar with the behaviour of tvheadend because I don't use it and don't have the equipment to simulate it on your behalf. I use set-top boxes/SAT receivers for live TV and therefore know the limitations associated with it.
Please understand the possibility to record multiple programmes from the same transponder (MUX) with only one tuner in use as a benefit for free. I would assume that tvheadend supports that out of the box, without special settings. It depends more on your typical TV usage if you a have a benefit of it or not.
For example:
If you have a primary place in your home, where you and your family most times join to watch TV together I would place the device with the most available tuners there. From your mentioned list the Hauppauge Dual Tuner looks like something to me, because it's mostly directly supported by the linux kernel. You are able to watch a show with the first tuner unit and can run a record in the background at the second tuner. If you have a second overlapping/simultaneous record scheduled and fortunately the additional program to record is receivable via one of the already tuned transponders (tuner1: live tv, tuner2: current running record), then this additional record is also possible. If this program is played out on a third transponder only, this 2nd record isn't possible. Thats all.
It looks to me like you could use the remaining devices (RPi with HAT, August on Windows) as a Tvheadend SAT>IP server. If you need a 3rd or 4th tuner in your typical use case, you could add these devices as network tuners in Tvheadend and have a total of 4 tuners available in one KODI instance. Several combinations of your 3 devices are possible, but to make it useful for everyday use, the remote devices should run 24/7 without interruption.I hope this attempt to explain clarify somethings to you.
-
noggin is technically right. Many tuners can only handle 1 transponder/frequency at the same time. A transponder contains various multiplexed channels. If the channels/programmes are received via the same transponder/frequency you doesn't need an additional tuner.
I assume, that the programmes mentioned by noggin example are played out via the same transponder. On that way, you can theoretically record/look more than 4 programmes at the same time with only one tuner if your hardware is fast enough. Some sat receivers working like that and you can record 8+ channels/programmes at the same time if CPU/HDD doesn't limit.
There are also tuner modules available with FBC (Full Band Capture) support. Such kind of tuners can handle multiple frequencies at the same time. I don't know if these are exists for DVB-T2 too and supported by Tvheadend, but this would additional multiply the count of simultaneous records with only one tuner. -
For streaming services (limited bandwidth) there also DTS:X lossy available. Maybe such kind of material ends with DTS only.
-
The EDID data of your TV looking incomplete to me. I assume that triggers the issue, because newer kernels / LE versions depending on it.
Code
Display More2024-10-22 09:14:10.595 T:1143 debug <general>: CDRMUtils::OpenDrm - drm devices found: 2 2024-10-22 09:14:10.647 T:1143 info <general>: CDRMUtils::FindConnector - using connector: HDMI-A-1 2024-10-22 09:14:10.647 T:1143 debug <general>: CDRMUtils::OpenDrm - opened device: /dev/dri/card0 2024-10-22 09:14:10.647 T:1143 debug <general>: CDRMUtils::PrintDrmDeviceInfo - DRM Device Info: available_nodes: 0x01 nodes: nodes[0]: /dev/dri/card0 bustype: 0x02 platform: fullname: /gpu 2024-10-22 09:14:10.647 T:1143 debug <general>: CDRMUtils::OpenDrm - opened render node: /dev/dri/card0 2024-10-22 09:14:10.701 T:1143 info <general>: CDRMUtils::FindConnector - using connector: HDMI-A-1 2024-10-22 09:14:10.701 T:1143 info <general>: CDRMUtils::FindEncoder - using encoder: 31 2024-10-22 09:14:10.701 T:1143 debug <general>: CDRMUtils::FindCrtc - original crtc mode: 720x576 @ 50 Hz 2024-10-22 09:14:10.701 T:1143 info <general>: CDRMUtils::FindPlanes - using crtc: 96 2024-10-22 09:14:10.701 T:1143 debug <general>: CDRMUtils::FindPlanes - using video plane 86 2024-10-22 09:14:10.701 T:1143 debug <general>: CDRMUtils::FindPlanes - using 10bit gui plane 119 2024-10-22 09:14:10.701 T:1143 debug <general>: CDRMAtomic::InitDrm - initialized atomic DRM 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] Error parsing EDID: 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] ---------------------------------------------- 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] Block 1, CTA-861 Extension Block: 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] Speaker Allocation Data Block: Deprecated bit F16 must be 0. 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] 2024-10-22 09:14:10.702 T:1143 error <general>: [display-info] ---------------------------------------------- 2024-10-22 09:14:10.702 T:1143 info <general>: [display-info] make: 'Vestel Elektronik Sanayi ve Ticaret A. S.' model: '55UHD_LCD_TV' 2024-10-22 09:14:10.796 T:1149 debug <general>: CLibInputHandler::DeviceAdded - keyboard type device added: mini keyboard (event2) 2024-10-22 09:14:10.796 T:1149 debug <general>: CLibInputKeyboard::GetRepeat - delay: 500ms repeat: 33ms for mini keyboard (event2) 2024-10-22 09:14:10.822 T:1149 debug <general>: CLibInputHandler::DeviceAdded - pointer type device added: mini keyboard Mouse (event3) 2024-10-22 09:14:10.822 T:1149 debug <general>: CLibInputHandler::DeviceAdded - keyboard type device added: mini keyboard System Control (event4) 2024-10-22 09:14:10.822 T:1149 debug <general>: CLibInputKeyboard::GetRepeat - could not get key repeat for event4 (Function not implemented) 2024-10-22 09:14:10.822 T:1149 debug <general>: CLibInputKeyboard::GetRepeat - delay: 400ms repeat: 80ms for mini keyboard System Control (event4) 2024-10-22 09:14:10.823 T:1143 debug <general>: CWinSystemGbm::InitWindowSystem - initialized DRM 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x576 with 720x576 @ 50.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x576 with 720x576i @ 50.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x480 with 720x480 @ 59.940063 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x480 with 720x480 @ 60.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x480 with 720x480i @ 59.940063 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x480 with 720x480i @ 60.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 640x480 with 640x480 @ 75.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 640x480 with 640x480 @ 73.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 640x480 with 640x480 @ 60.000000 Hz 2024-10-22 09:14:10.823 T:1143 info <general>: Skipped 1 duplicate messages.. 2024-10-22 09:14:10.823 T:1143 info <general>: Found resolution 720x400 with 720x400 @ 70.000000 Hz 2024-10-22 09:14:10.830 T:1143 info <general>: EGL_VERSION = 1.4
In your first post, you mentioned an AMP between RPi4 and TV. Can you try it with RPi4 connected directly to the TV and post a new log? If that works, you should try again with getedid create before you insert the AMP again. https://wiki.libreelec.tv/configuration/edid
-
How is your RPi connected to the soundbar?
- RPi4 -> TV -> Soundbar
- RPi4 -> Soundbar -> TV
For case 1 your TV and the soundbar must be connected via eARC not only ARC to support high bit rate audio at the return channel. Sometimes it's only available at a specific HDMI port and maybe additional configurable in the settings of the TV.
In the second case, do you have ensured that you set the audio channels to 7.1?
You are right that some issues were corrected (in worst case introduced
) after 12.0.1 release and a recent nightly build may work better, but it's more helpful when you enable debug logging, reboot and provide a link to the log.
-
Because of some needed changes in mesa drivers you need a recent nightly build for th 2GiB version. This model was going public after 12.0.1 has been released.
I assume it looks like here:Thread[RPi5 2GB] Scrambled Display on Sony Bravia X90L
Hey, folks.
Please be patient with me as I barely pay attention to any of tech around TVs, variants of HDMI, variants of 4K/8K, etc. We are simple folks who just want to watch a digitized collection of our old movies.
I have a Bravia X90L series (55") and I just picked up a Pi5 CanaKit with all of the bells-and-whistles to double-sided tape a LibreELEC media center to the back of the TV over the fireplace. The version of LibreELEC is recent -- whatever came out of the business end of rpi-imager…wizardly_jenningsOctober 10, 2024 at 9:50 PM -
It's up to you that it's difficult to support you. You skimp on details and doesn't provided helpful information about projector and AVR model number and firmware state.
Depending on the kind of projector you using, there are mechanical parts involved which could be affected by the used frame rate and color deep, not only electronical parts. LibreELEC attempt to use the native frame rate of the movie material (mostly 23.976Hz/24Hz) during playback and not the desktop settings. This can make already the different to Roku or KODI on Windows. Then the color wheel inside of a DLP projector may use a different frequency to follow the frame rate of 24 Hz or upscale to 120Hz or something like that. The resulting behavior mustn't be the same if your other sources provide a 60Hz signal instead and therefore not ends in protection mode/overheating of your projector.
To inspect if the RPi5 is really the troublemaker, you should:- enable debug logging : https://wiki.libreelec.tv/support/log-files
- reboot
- trigger the issue
- post the link to the log
PS: Since some other HDMI- and CEC-related corrections are only included in later versions than 12.0.1, you should perhaps also try a current nightly version of LE 12 or 13 (Attention: sorted in ascending order!): https://test.libreelec.tv/12.0/RPi/RPi5/
-
There are issues with projectors if they are overheating, then they shut down after such kind of period. It looks to me that this happens on your setup. Maybe an firmware issue of the projector or AVR with a specific frame rate or possibly a real hardware issue. Do you have an OSD with information about current input signal on your projector to compare the incoming signal with the working ones of Roku/NUC
Which projector and AVR do you use?
-
The troublemaker seems the AVR:
https://www.avsforum.com/threads/pioneer-vsx-32-video-issue-over-hdmi.1306123/
https://www.avsforum.com/threads/owners-thread-pioneer-vsx-932.2940416/
Can you try if kodi-fs.desktop works if you reduce your desktop settings to 1680x1050 or something like that?
If that works, maybe 59.94Hz or 30Hz can be a workaround for 1920x1080 too.
-
Hi Da Flex ,
I expect also 4GiB/8GiB models in the future with the new chip revision. But after the post of chewitt I could see also the memory information in the logs. Maybe it's not the variant wizardly_jennings has ordered, but he use the 2GiB version, not a 8GiB model like he assumed.
-
If you get such kind of boot screen: RE: Remote Install OS
I see no chance to solve that without switching to another IR dongle/remote control combination. The RPi4 and upwards supports that network install option with a recent bootloader, so it's normal that this behavior can't reproduced with the RPi2.
Do you have already checked how this dongle operates at a desktop computer? Maybe there you can figure out how you can switch the remote in another mode to disable Shift/Caps Lock at boot.
Only if you get another situation (without the red screens) where the dongle is detected as USB mass storage device, maybe you can check and change your boot order to boot from SD card first. -
Looks like your IR sensor works as a keyboard and emulates holding the "shift" key. Check the current state of your IR remote if it also has a keyboard function or/and maybe replace the batteries.