Should be fixed by this once it is merged into LE code.
Posts by popcornmix
-
-
That is likely because of the bug referenced.
The fix hasn't been merged so won't be in nightly builds.
You'll need one of HiassofT's builds with unmerged fixes.
-
Ok I need to retract my last comment. It seems to be, that audio is delayed no matter which TV mode is used. I think every Dolby track (AC3 and E-AC3) is 150ms too late. With DTS I am not sure. Definitively not related if 50p or 24p.
Maybe someone could crosscheck this. Thank you.
Pretty sure this is occurring outside of kodi/pi (i.e. the processing of audio/video is different which can be true when using an AVR).
I have an Onkyo AVR and Pansonic TV and have no issues with a/v sync whether passthrough is enabled or not.
You can adjust the audio offset when playing a video and then select "set as default for all videos" for it to always be applied.
There may also be similar adjustments available through AVR or TV menus.Video processing options like motion enhancement may be adding video delay, and are best disabled.
-
-
Your issue is probably lack of deinterlace which improves quality of interlaced sources like live TV.
There is a test build with support here: RPi Deinterlacer testbuild
Hopefully it will be in the next LE 10 update.
-
I guess the following is how the preferences work ?
2160p30 and below : RGB 12-bit, YCbCr 4:2:2 12-bit, RGB 10-bit, RGB 8-bit
2160p50 and above : YCbCr 4:2:2 12-bit, RGB 8-bit.
(There are no 4:4:4/RGB modes at >8 bit supported in 2160p50 and above in HDMI 2.0, and 4:2:2 YCbCr is supported at 12-bit only)
4:2:2 12-bit YCbCr at 2160p50/60 is often only supported by some (not all) HDMI inputs on some TVs (like my Sony XF9005 - which won't support this format on HDMI 1 and 4, only 2 and 3) and has to be enabled in TV menus. Similarly my Denon AVR has to have support for 4:2:2 12-bit enabled in its menus too. It's often called 'Enhanced HDMI' or similar. It also requires higher performance HDMI cables to work reliably as the bandwidth is pushing the limits of the HDMI 2.0a spec.
if hdmi_enable_4kp60=1 then 2160p30 will use RGB12-bit (and scrambling due to increased clock). If it's not set you'll get YCC422 (no scrambling). Assuming edid allows.
Correct for 2160p50 and above.
-
EDIT: Looked in that menu; found a lot of options which I've tried to configure as best I can to achieve a workaround, but couldn't see anything for a forced HDMI signal, so I guess time will tell if I've changed something that will do the job ... as I said in OP, it's usually if I go back after 24-48 hours of not watching anything on KODI.
Start with the hammer. Disable CEC.
If you normally use CEC for control then switch to something else (keyboard/phone remote).
If the problem has gone we can dig more deeply. If it's still there we can cross CEC off the list.
-
-
There is a potential fix here that hopefully will be merged soon.
-
I have this issue with an rPi4 attached directly to the hdmi port of my TV. I don't have an AVR. It's frustrating as I can't seem to get it to stay off. I have been able to power the TV off and keep it off, most of the time, if I wait for LibreElec to go to dim, before I switch HDMI to another source and then power off. I have turned off switch source in LibreElec, but I don't think that had ANY effect. Previously, I had an rPi3 with 9.2, no issues.
Does reverting to 10.0.0 avoid the issue?
-
What does:
I'm guessing it's zero length. Can you run "getedid create" from here.
Hopefully that won't get upset by the invalid edid. You should now have a file in .config/firmware/edid/edid-HDMI-A-1.bin.
Replace this file with an edid file that supports audio. You can try mine.
But be aware that edid probably promised to support more than you monitor actually does, but it would be interesting if that is enough to get audio out.
-
Any other ideas or info I can gather?
Run:
It should have an "Audio Data Block", e.g.
CodeAudio Data Block: Linear PCM: Max channels: 2 Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32 Supported sample sizes (bits): 24 20 16
I suspect yours does not. If it doesn't then it would be possible to report audio support by using an edid file that reports audio support.
-
@SV on the bad pi can you try adding "over_voltage=2" to config.txt? I have come across occasional Pi's where that helps.
-
Code
#0 0xf7de4198 in strlen () from /usr/lib/libarmmem-v7l.so #1 0xf54cfe68 in std::string::operator=(char const*) () from /usr/lib/libstdc++.so.6 #2 0x0037a4a8 in ?? () #3 0xf775d330 in ?? () from /usr/lib/libpython3.8.so.1.0
suggests it is a python addon that provokes the crash.
If you enable debug logging before capturing the log it may (or may not) give a clue which addon caused it.
The usual way to track this down is to disable all addons, check the crash has gone and then enable them one by one to identify the culprit.
-
There is a spidev kernel fix for 5.15.
Hopefully it will appear in nightlies soon.
-
I'm interested if this issue only occurs with AVR+TV. So connecting directly to the TV, (bypassing the AVR) is of interest.
I'm suspecting the issue won't occur but it would be interesting (and simpler to debug) if TV switches on when directly connected.
-
-
It's always useful to report when an issue starts with nightlies. If you can report a latest good and oldest bad build it might help narrow it down.