Posts by doug

    I tried for a long time to use CEC to get info from the TV to my Pi (to change inputs and toggle on/off). From what I've read and from what I've seen others with far more knowledge write, the protocol doesn't support it.


    So I use a this USB to RS232 dongle, pyserial and a python script to test if my TV is on or off.


    Edit: Some TVs also can be controlled via their Ethernet connections. Check your manual/online.

    Ya, you probably have some skin funkiness then...you say you are setting debug logging in setting and rebooting, but the kodi.log says logging is explicitly disabled. You can try enabling logging within the default skin, switch skins and then reboot. You should also try reproduce the error with the default skin.


    Is xonfluence even supported for 17.1? What about trying to reproduce the error in other skins.

    If power supply issues were the cause, this should also have been apparent with the previous OE install under the same CPU load, and it should be worse while playing, say, H.265 video's which currently generate the highest CPU load. But it isn't. Instead the problem occurs while switching visualizations during audio playback and the like, at which time Kodi freezes for a second or two, then reboots.


    Not quite. Recent versions of Kodi/LE have changed how GPU/CPU handle audio/video compared to previous versions of Kodi/OE. You can't draw the conclusion. A more relevant comparison would be the same version of Kodi in LE vs. Kodi in OE. And this still wouldn't eliminate the power supply as a possible issue.


    I'd test a separate power supply. I'd also test a different USB cable as those can cause problems too.


    The kodi.log and kodi.old.log you provided weren't debug enabled logs. Enable debug logging, reboot, then reproduce. Then upload the logs.


    Re Debug, please see 14:23:22.428 : NOTICE: Enable debug logging to GUI setting level 2.


    The CPU 660 has two cores, I do not know why LibreElec is only using one. However, even one should be enough. Note that, as said, repro of HD files is fine and requires more processing power than SD.


    The general steps to create a debug log are:
    Enable debug logging.
    Reboot.
    Recreate the error.
    Upload the log.


    Things like omitting the reboot step, several hours elapsing, deleting parts of the log, and playing additional files just makes it harder to see what is going on.


    Sent from my LG-H812 using Tapatalk

    For reference, that is not a debug log. That is a regular log:

    Code
    1. 19:45:34.731 T:140270887815296  NOTICE: Disabled debug logging due to GUI setting. Level 0.


    Regardless, maybe your machine is borked or you've disabled some cores in the bios:

    Code
    1. 19:45:34.609 T:140270887815296  NOTICE: Host CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 1 core available

    My solution was to map a button to a "change input" python script. The script tells the AVR (connected to and controlled over my LAN) to change to the input. This isn't a CEC solution because I have game boxes on other inputs without CEC.


    Sent from my Transformer TF101 using Tapatalk

    Have you tested this out in Krypton?


    Yes, I have tested it in Krypton. A delay of 0 as shown fixes things for me.


    You can use a smaller number, like 1000 or -1000. The point is to use a number that allows you to identify a change in the delay so you can determine if it is working or not. After that, you can change the value in advancedsettings to whatever works for you. It seems as though you found the right value for your setup.



    1. Something in Krypton changed and the offset is now cumulative and not overwritten from the system advanced settings file.


    A delay setting in your advancedsetting.xml will override the delay in LE's advancedsettings.xml. Any additional changes you make to audio delay in the GUI are additive to the one in advancedsettings.xml. That is why I mention to set any GUI-based delay to 0 first.



    2. Something in the copy/paste of the stock settings file into the version in user data was not being interpreted correctly until I "slimmed it" down a bit.


    Strange things can happen depending on the tools/systems used.

    To debug this, you might want to change only the delay in advancedsettings and change nothing else in the GUI and observe what happens in two cases. First, set the offset in the GUI to 0 while playing a 24p video. Then,
    Test 1: Set the delay in advancedsettings to 0. Reboot. Play the video and note what happens.
    Test 2: Change the delay in advancedsettings to 2000. Reboot. Play the same video and note what happens.


    You should see a 2 second relative difference to the first observation. From those two observations, you should be able to determine whether or not the delay in advancedsettings is doing something. And, with a two second delay and observing the difference between Test 1 and Test 2, you should be able to see whether a delay or advance (negative delay) is required for your setup.


    I use this to eliminate the delay for 24p material on my Odroid C2 played through my AVR on a projector. It's only slightly different from what you use.

    Code
    1. <video>
    2.   <latency>
    3.     <refresh>
    4.       <min>23</min>
    5.       <max>24</max>
    6.       <delay>0</delay>
    7.     </refresh>
    8.   </latency>
    9. </video>

    You can see in the log that LE's default delay for 23/24p material is set to 175 and then some other advancedsettings file is processed where the delay is *still* 175, not 0 as you've indicated. So you've got an additional advancedsettings.xml file somewhere where you've set the delay to 0 and it doesn't get processed. I'm going to guess you created a symlink back to the LE advancedsettings file as it looks like the system/xbmc/advancedsettings.xml file is getting processed twice.


    And pastebin the full log and post the link.

    Hi,


    I've been happily using LE with 3 RPi2s for a while now with the Milhouse testbuilds. v8.0 works great with them too. I'm trying out an Odroid C2 to replace one of them and have an issue playing any 59.94Hz MKVs containing SD mpeg-2 content.


    Specifically, when I play these types of files, the playback is continuously very jerky (with H/W decoding) or occasionally "blurry" (with S/W decode). With H/W decoding on, it appears like the video is speeding up and slowing down repetitively every second. It's most noticeable when there should be something moving smoothly on the screen. Here is a debug log with H/W decoding:
    QSNV (it's just the start of The Matrix. the WB logo should move away slowly and smoothly, but it is jerky.)


    Here is a debug log from an RPi2 (same physical connections/AVR/Projector as with the C2. RPi2 has the H/W decoding license and is using MMAL):
    cTQF (WB logo nice and smooth)


    I have "sync playback to display" disabled, and "Adjust Refresh Rate" to "On Start/Stop" on both the RPi2 and the C2.


    In System Settings/Display, the RPi2 lists many refresh rates available (23.98, 24, 25, 29.97, 30, 50, 59.94, and 60) but the C2 only lists (24, 30, 50, and 60)


    Is there some setting I'm missing for the C2 or is this just something that still needs to get fixed as AML development is still a work in progress?

    You're using an old version of LE for the C2 with known bugs, including a memory issue. Upgrade to 7.95.3 and see if your problem goes away.