Posts by popcornmix

Quote

• This suggests Kodi is dying when trying to render some text from an addon (or skin element) while Python is executing.

I don't see evidence for that from a single crash log. The font rendering thread is just what kodi was doing when other thread crashed with a SEGV. The crashed thread was python related. It's most likely just luck what other threads happen to be doing when the python thread crashes.

As chewitt says:

find the date of first nightly with the issue.

find if you can provoke the issue with a clean .kodi

Quote from Soundie

To sum up; Popcornmix' solution with running kodi from rotated RPiOS (without LE then) is a verified working solution for this problem.

Glad that worked for you.

You might want to try installing kodi21 from RPiOS which supports wayland, and much like Xorg on the PC, allows the compositor (outside of Kodi's knowledge) to rotate the screen.

Note that this will use EGL for composition, rather than DRM which is a less efficient path. It should be fine for 1080p60, but will struggle with 4K video.

But you can give it a try quite easily, to see if it meets your requirements. Use the preferenced/screen configuration tool (from the desktop) to set the display rotation, then launch kodi (the desktop version, not the fullscreen version). You can switch the desktop kodi to use fullscreen when running.

Quote from elliottmc

With that in the file, and the HDMI plugged in closest to the power cable, it does work, as long as the HDMI is plugged in at boot, and not afterwards.

You should be using:

video=HDMI-A-1:1920x1080M@60D

The D means assume it's connected (otherwise you will need to have a display connected at boot).

You should always use the primary hdmi connector (closest to power connector).

Note: the linked patch is for a 180' rotation.

It's not clear if Soundie wanted a 90'/270' rotation which is far more complicated.

Pi2/Pi3 have no HEVC (H.265) hardware decode support, so are likely to struggle with files encoded this way.

Stick with H.264 encoded files if you want to play them smoothly on this device.

Pi4/Pi5 do have HEVC hardware decode and should play them fine.

Quote from atcronin

I wonder if this patch (done properly) could make it into the official repo? While it is a workaround for an LG TV bug, I am not sure the possibility of engaging PC mode would ever be preferable for a Kodi distro.

Reporting a PC style device as a PC style device sounds like the correct behaviour.

The TV not allowing the user to choose picture enhanced based based on this seems like the bug.

I'd be nervous about changing the reported source type for everyone. I believe using PC mode will often default to a non-overscanned display which is desirable and the change you are suggesting may make things worse for others.

The correct solution is to complain to LG and hopefully a firmware update will allow your use case to work.

The workaround should be that the kernel defaults to PC mode. but allows a runtime override (perhaps through sysfs) to change the SPD_SDI type. A display settings option in kodi could allow setting this. But that is more work, and really needs to be done in the upstream linux and kodi repos, not by LibreELEC.

You can see the infoframe used:

LibreELEC:~ # edid-decode -I /sys/kernel/debug/dri/axi:gpu/HDMI-A-1/infoframes/spd 
edid-decode InfoFrame (hex):
83 01 19 93 42 72 6f 61 64 63 6f 6d 56 69 64 65
6f 63 6f 72 65 00 00 00 00 00 00 00 09
----------------
HDMI InfoFrame Checksum: 0x93
Source Product Description InfoFrame
 Version: 1
 Length: 25
 Vendor Name: 'Broadcom'
 Product Description: 'Videocore'
 Source Information: PC general

I'm guessing it's the "PC general" that causes the bad behaviour in your TV which is set here.

This is generic linux kernel code, so all linux platforms will behave the same (assuming they support the spd infoframe).

I'd say the code is correct. Based on the options available that is the best match for a Pi or PC.

HDMI_SPD_SDI_UNKNOWN,
 HDMI_SPD_SDI_DSTB,
 HDMI_SPD_SDI_DVDP,
 HDMI_SPD_SDI_DVHS,
 HDMI_SPD_SDI_HDDVR,
 HDMI_SPD_SDI_DVC,
 HDMI_SPD_SDI_DSC,
 HDMI_SPD_SDI_VCD,
 HDMI_SPD_SDI_GAME,
 HDMI_SPD_SDI_PC,
 HDMI_SPD_SDI_BD,
 HDMI_SPD_SDI_SACD,
 HDMI_SPD_SDI_HDDVD,
 HDMI_SPD_SDI_PMP,

Changing from HDMI_SPD_SDI_PC to HDMI_SPD_SDI_UNKNOWN might avoid the issue with your TV, but it's not runtime configurable (you will need to patch that line in kernel and rebuild LibreELEC).

There is (effectively) no AAC passthrough anywhere.

It is mentioned in specs, but n o consumer devices output it and kodi doesn't support it.

Kodi can decode the 6-channel AAC and output 6-channel PCM.

This is lossless and will have perfect quality, but relies on connection to AVR to support multichannel PCM.

It's not clear from your post how the TV and AVR are connected.

Ideally you connect pi-<hdmi>-AVR-<hdmi>-TV but it sounds like you are not (due to AVR not supporting 4K, but TV does).

I assume you care connecting pi-<hdmi>-TV-<something>-AVR?

What is the <something>? Is that ARC or toslink/spdif?

They are limited to two-channel PCM. But two-channel PCM can carry passthrough of AC3 or DTS.

(Note: AAC and AC3 are distinct formats).

The good news is kodi can be configured to decode AAC, encode it to AC3 and output that as passthrough.

That will likely get you multi-channel audio. The operation is lossy, but would be imperceptible to most people.

In system/audio settings set:

Number of channels: 2

Allow passthrough: On

Dolby Digital (AC3) capable receiver: On

- Enable Dolby Digital (AC3) transcoding: On

DTS capable receiver: Off (you could try on, but that is less commonly supported by TVs)

I'd be interested if CoreElec is good forever, or if the buttons will stop working after a while.

I can make my Panasonic work with the magic keys (*Power*-button, keep it pressed, and press *7* *3* *Stop* - which was actually documented in the user manual) but it always stops working after a while.

The problem is at the TV end, not the Pi end. If the TV doesn't send the button presses there's nothing that can be done.

See here for a possible fix - but I found that also tended to be temporary. I've ended up remapping unused buttons that are forwarded (e.g. the coloured ones) for functions I use.

I'm not aware of any regression.

If you could identify the exact nightly build where the performance regression started, then the changes there can be investigated.

Edit: We are suspecting https://github.com/LibreELEC/LibreELEC.tv/pull/10258

Quote from LayaKir

In my settings, I've switched Refresh to "Off" - keeping it on with my TV makes the movies look too smooth and unnatural, and not like "movies".

You want that setting on. If what you see is unnaturally smooth ("soap opera effect") then that is a setting on your TV.

See here.

To avoid ambiguity, are you saying a build you make from commit 4e4a6f9 is good and the very next commit (a794735ee) is bad?

Or are you testing official nightly builds (which may jump a few more commits).

Quote from Voosjey

Unfortunately, switching from 3D to 2D still doesn't work in LE13. In which file is this controlled? I'm not a programmer, but maybe there's a way to fix it.

StereoscopicsManager.cpp is the main control of what 3d mode is configured.

Some of the gui rendering code is in GraphicContext.cpp and some of the video playback rendering code is in VideoPlayerVideo.cpp

Have fun.

Quote from MostNormalAnimeFan

One other note, I've notice a message in the journalctl -a -b -0  section of the log when running pastekodi that had a warning about undervolting. I was originally using a 10W power supply, and I've changed that to a 20W power supply now. Wanted to mention that in case that solves the issue.

Running with an inadequate power supply (that the undervolting lines prove) can certainly cause random crashes.

Terrestrial (via aerial)? What country?

Just run "sudo apt install kodi21" on RPiOS Bookworm. (installing kodi will get the older kodi 20).

If you really need to build your own version, then see here.