Posts by josh4trunks

  • [x86-64] CEC broke after updating to LE 12.2.0

    I checked the edid in my /flash partition, and compared to the one on my HDMI device it is identical. I also used read-edid and it looks like it should be correct (I see references to my Denon AVR).

    So, my current theory is that when I unsuspend my LE HTPC, it turns on libCEC which then send the wake command to my AVR and TV. So when libCEC is initialized, those components are not on, and libCEC does not respect the edid from 'getedid create'. It sees that nothing is currently connected and changes the 'Connected to HDMI device' and 'Physical address' settings to the default values.

    At somepoint I'll test out LE13 and see if that also resets the libCEC settings.

  • [x86-64] CEC broke after updating to LE 12.2.0

    HarryH Thanks for the information. Yes 1100 should be the correct setting for my setup.

    I did use getedid create after a fresh install of LE 12.2.1, but the CEC settings are getting reset on this OS version.

    I knew about getedid create from previous versions of LE, not sure what problem it fixed for me before, but I remember I needed it to get everything working perfectly with CEC a few years ago. On LE 12.0.2, settings were not getting reset randomly, and CEC worked as expected.

    Regarding the chattr +i and chmod 444 fix, these don't seem to work 100% as expected. Even though the xml file isn't being changed anymore, the Kodi GUI is still showing changes to the settings I mentioned earlier. So you are probably correct, libCEC is getting information from somewhere other than just the config file.

    I will investigate with getedid to see if I can learn more about what libCEC is reading/savings. It's just strange how this was not a problem with earlier versions.

  • [x86-64] CEC settings not saving on latest LE nightly LE 13

    I checked the tag on github, the fix mentioned here is merged into Kodi v21.3 / LibreELEC 12.2.1.

    But I counted 8 people thus far that have a similar but possibly different issue on this thread. So there still seems to be something resetting CEC Peripheral setting seemingly randomly.

    Thread

    [x86-64] CEC broke after updating to LE 12.2.0

    ive been using this pulse eight adapter for ages, it has always worked. but stopped working in 12.2.0, installed old version again (12.0.2) and it started working again.

    dont know what info I can provide here, let me know. its a philips tv with android tv on it
    marantz
    October 24, 2025 at 5:22 PM

  • [x86-64] CEC broke after updating to LE 12.2.0

    I'm also experiencing issues on LE 12.2.1 (x86_64). I noticed the following settings, and possibly more, are getting reset sometime after saving...

    * Connected to HDMI device = Amplifier / AVR Device > TV
    * Physical address )overrules HDMI port) = 1100 > 1000

    Are we sure it is because of the update to libCEC 7.1.1? I assume the configuration file is managed by Kodi, not the driver, but I could be wrong.

    I tried the following to stop kodi from overwriting the settings once they were correct, it seemed to have worked but I will need to do more testing to make sure I fix it permanent and I didn't break anything.

    systemctl stop kodi
    chmod 444 /storage/kodi/userdata/peripheral_data/usb_2548_1002_CEC_Adapter.xml
    chattr +i /storage/kodi/userdata/peripheral_data/usb_2548_1002_CEC_Adapter.xml
    reboot

  • TBS or Hauppauge quad tuner ?

    frakkin64 Have you upgraded to LibreELEC 12 Beta 2? I just installed the Hauppauge WinTV-quadHD PCIe into my system and it is not creating /dev/dvb.

    Maybe I could try a previous build and see if this stopped working on a specific build?

  • Weird Errors on Specific Movie

    I noticed a specific movie file was causing several issued when being played back. I even got an alternative version of the file (that included DV and was posted 3 years later) and reproduced the same issues.

    Here are the various symptoms I noticed.

    • audio cutting out briefly, I think this is audio skipping
    • sound becoming robotic. I need to stop and restart playback for audio to sound normal again
    • occasionally playback exiting back to Kodi menu

    OS: LibreELEC 12 Beta 2
    CPU/GPU: Intel Celeron J4005
    Passthrough to AVR: Denon X3700H

    File info:
    4K HDR Remux of WALL-E (2008) using TrueHD Atmos Track, around 1 hour and 17 minutes

    ####

    I haven't noticed this on any other 4K Remux movies, so I assume this problem is specific to this movie but may affect others too. Is there anything I can do to fix this issue, either to the MKV or in Kodi/Linux?

    I also found this locked thread which I think is related, but it seems people are dealing with the issue on Android. I will test if adjusting "maxpassthroughoffsyncduration" makes any difference.
    Audio Passthrough IEC - TrueHD fix/workaround - Testing build

    Thank you!

    EDIT: Infected kodi.log deleted by moderator.

  • Gratitude Post, and some minor questions

    Thanks to the developers for this OS! I've been using OE/LE since 2011, and now can finally say I have an endgame system for my family's use case.
    83" OLED with HDR, 5.1.4 in-wall/ceiling surround sound, dual DIY subwoofers, all controlled with a simple RF (OSMC) remote through CEC (Pulse-Eight Adapter).

    So I did have a few minor issues I still wanted to tackle.

    1. For my OSMC remote, on the homepage I have the home button activate the shutdown menu. Is there a way to have this always focus on the "Suspend" option? I tried ActivateWindowAndFocus(shutdownmenu,9000,2,9000,0) but it is not working as expected. I tried reading through the Estuary Skin DialogButtons.xml, but can't figure out which IDs I need where.

    2. When my LE system suspends it usually shuts down my Receiver and TV using CEC, but maybe half the time it doesn't. And I think those times, when I wake the system it send the CEC command then. So I am thinking there is a race condition, sometimes LE suspends itself before the CEC adapter can send out the command. Adding a 'sleep 3' to a sleep.d script fixes this issue, but maybe there is a more elegant solution to this problem?
    I could do a while loop in the sleep.d script, or maybe LE or Kodi can change suspend logic to wait until CEC jobs are completed?

  • switch on TV (CEC) when librelec is turned on

    Do you have a CEC capable LE system? Like Raspberry Pi or USB CEC adapter?

    Another thing I just did to fix wake issues on my system was "getedid create". This stores EDID info, so your LE system knows what it's connected to even if they are still waking up.
    https://wiki.libreelec.tv/configuration/edid

    BTW, thanks to the LE developers for the "getdid" command. I remember years ago doing this manually, and now it's so much simpler!

  • Anything better than a Pi4 currently?

    Quote from noggin

    Beware using 'DolbyVision' as a catch-all. There are lots of different variants of DV...

    Some are based around YCbCr (aka YUV) PQ HDR10 or HLG 10-bit HEVC/h.265 and then Dolby Vision RPU metadata (and in some cases also an expansion layer to get from 10-bit to 12-bit depth. These can usually be replayed with no Dolby Vision licensing requirement for the HDR10/HLG stuff. Examples of this type of DV sources are Dolby Vision UHD Blu-rays and DV video shot on iPhones.

    Other DV stuff is encoded purely in a DolbyVision video format using ICtCp representation and PQ instead of YCbCr/YUV - though still encoded in 10-bit HEVC/h.265. When these are replayed by non-Dolby Vision licensed devices they replay with magenta/green colours instead of normal colours, because they are interpreted as YCbCr when they aren't. This format is widely used for streaming platforms - where the streaming player can request a specific encode that it can play (rather than a single encode needing to be playable by multiple devices). The CoreElec DV implementation can play these OK, few other devices can.

    Ok, that makes alot of sense. I thought all DV files were unplayable (in regular colors), but now I see that some files labeled DV seem to play with at least HDR10 working!

    Quote from Da Flex

    It has to be conform to Dolby licensing conditions. If you find a legal hack, let us know.

    I don't think I would be very helpful, but I'll keep an eye out where I can help, lol. I do remember when I first started using in Linux in 2009 I had to use a Windows wireless driver using "ndiswrapper" to get WiFi working. So maybe that could be the state of things one day. If Dolby gets a little too loose with their driver signing and makes something that works on all Intel/AMD GPUs, we could get to a similar point. Though, that might still require users to provide their own input cause I doubt LE would/could include these blobs in their builds. But ideally, I just hope for more open standards to gain acceptance over closed ones.

  • Anything better than a Pi4 currently?

    Sorry for the double post. My posts need to be manually approved, so I can't edit the last one (#23).

    From reading a bit on the CE forum, it seems like the key to CE with specific hardware decoding DV is a proprietary driver blob. They are reusing the same blob that Dolby provided to android manufacturers for that specific SoC.

    So I understand why DV doesn't work except in very specific hardware chains. I'm guessing that some hardware could do handle the decoding, but without the necessary drivers from Dolby it won't be possible. I know on some specific windows laptops, with specific video players, DV does work, but again that is because of Dolby's blessing.

    I wonder if any of this could be hacked in the future, to create the necessary drivers. Or hopefully we just move past DV, and get an open implementation that doesn't cause this mess.

  • Anything better than a Pi4 currently?

    Thanks for the confirmation. These proprietary formats are just annoying, only reason I care is some movies seem to only be available in 1080p or DV, no regular HDR10. I remember when distributing "lame" to handle mp3's required users to read some license and the headache that caused working with it.

    Im kinda set on sticking with x86; it sucks that I may be locked out of watching some movies in HDR quality but I have a feeling there will eventually be a solution.

    Out of curiosity, how is CoreELEC on a Banana Pi properly handling DV? Did CoreELEC pay for some licensing to handle DV files in software?