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:

    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:

    HarryH
    June 23, 2024 at 12:23 PM

    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.

    The EDID data of your TV looking incomplete to me. I assume that triggers the issue, because newer kernels / LE versions depending on it.

    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:

    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:

    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?