Posts by HarryH

I didn't want to distract. Nice to know that LE itself shouldn't be affected. It was not obvious to me whether it was mounted exclusively via LE and not via the operating system. And because I could reproduce the issue with 2 desktop linux clients in daily use too, I would only ensure that RomanHT is aware of it.

Most of the usually LE traffic is read-only (with the exception of TVheadend recordings, etc.), but he writes from LE device to NAS so that he could have been affected ...

Sure, the freeze problem itself is another topic.

The board mentioned by popcornmix works for RPi4. You can teach a remote button of your choice to the board or use the shown button to turn it on and off. I know this because I corrected the required scripts for some people on this and another forum and got some positive feedback. But unfortunately, it's discontinued and may not be officially compatible with the RPi5 (integrated max current limit of the RemotePi board).

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

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:

#!/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:

Post

RE: [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…

HarryH

June 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.

2024-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?

1. RPi4 -> TV -> Soundbar
2. 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_jennings

October 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.