Posts by popcornmix

Quote from Cabal

Is this a bug, or a limitation of driver/software support as noted in the docs?

It's a limitation. The only format that supports 10-bit output is P030 (three 10-bit pixels in a 32-bit word in a tiled format).

P030 is native to the hevc decoder, and supported directly by the display.

But AV1 is sw decoded, doesn't use that format, and ffmpeg doesn't support conversion to that format.

So it uses the format it can do (8-bit YUV420).

In theory a conversion to P030 could be written, but it would need to be written in Neon assembly to have the performance.

Quote from BallerShotCaller

The really strange thing is that 1080p@60Hz does not work anymore now. When I set the default UI setting to 1080p@60Hz, the screen goes black until the resolution goes back to 4K automatically again after confirmation time is up.

When it is set to 1080p60 (and is not showing an image), can you report output of kmsprint?

(execute that through ssh).

HDMI port closest to power connector on Pi4/5 is the primary one, and should be used when only using one display.

Quote from BallerShotCaller

OK, this is weird. I just re-installed LibreELEC on the Pi5 from scratch again, restored the config from the Pi4 and now it works as it should. WTF? There's absolutely nothing I did differently than before!

But something strange happened: After restring the config and rebooting, the screen remained completely black but I was able to boot into LE via SSH.

Can you be precise with the sequence here.

1. Fresh install of LE on Pi5 from scratch works fine

2. "restored the config from the Pi4" - did you copy .kodi directory or use an backup/restore addon? And this works fine.

3. "After restring the config and rebooting, the screen remained completely black" do you just mean a reboot compared to the previous step, or did you restore something else?

Assuming step 2 was working without a reboot, then kodi is likely not using the restored config.

It may be interesting to identify what file in the config is the one that causes the issue. guisettings.xml is the most likely.

(But I don't know if you are restoring anything else, like contents of /flash partition).

Did you try on RPi OS? Did you have the same issue?

The crashes are in python, so it's an addon:

#0  0x0000007f8711918c in ?? () from /usr/lib/libpython3.11.so.1.0

The last line in the log is usually:

2024-05-15 05:26:12.617 T:1766546    info <general>: WEATHER: Downloading weather

so I'd start with disabling the weather addon.

Can you compare the messages in dmesg when plugging in the three tuners on both the Pi4 and Pi5.

If there are some error messages only on the Pi5 then that may help narrow it down.

Yes it sounds very likely the Rii X8 causes the issue, presumably because (for some reason) it reports the shift key is held down.

It would be useful if you could confirm this.

Boot with Rii X8 connected - does it go to installer?

Remove Rii X8 and reboot - does it go to installer?

I've asked the experts and the behaviour is surprising.

One possibility is the keyboard has a stuck shift key.

If you boot with shift key held down, you'll go straight to installer.

Do you still have the issue with keyboard disconnected? With a different keyboard?

This isn't really my area, but I'd imagine a USB drive that was too slow to enumerate may sometimes fail to boot and move to the next stage in booting (which may end up at the network install screen).

That doesn't really tie in with it also happening with sdcard.

What do you have BOOT_ORDER set to?

Have you removed the USB drive when testing with sdcard?

When at the network boot screen, it says "Press ESC to cancel and go to diagnostics screen" who does diagnostic screen show?

(if keyboard is not connected on boot, I believe it goes directly to diagnostics screen).

A firmware has been pushed that should fix the green line issue.

It will hopefully appear in nightly builds in the near future.

If you are feeling bold, you could try downloading start4x.elf and fixup4x.dat and replace the existing start.elf/fixup.dat files on your sdcard.

The crash is from:

#0  0x0039a83c in PLT_CtrlPoint::RenewSubscriber(NPT_Reference<PLT_EventSubscriber>) ()
#1  0x003a2d20 in PLT_CtrlPoint::DoHouseKeeping() ()
#2  0x003a325c in PLT_CtrlPointHouseKeepingTask::DoRun() ()
#3  0x003cbea4 in PLT_ThreadTask::Run() ()
#4  0x00423cb0 in NPT_PosixThread::EntryPoint(void*) ()

PLT seems to be a uPnP library, so you could try disabling it in system/services/UPnP/DLNA

force_turbo=1 will force core and arm freqs, whereas core_freq_min will only force core.

So the latter will run a little cooler.

The arm is not that important for h264 decode (which is offloaded to hardware) so it won't make much difference.

The firmware fix is in rpi-update firmware. It should be picked up by LE in the near future.

You need an edid to be provided by display to be able to choose a suitable output mode.

My guess is yours doesn't.

If you power on, connected to display with no sdcard or usb connected do you see the diagnostic screen?

What does the "display:" line report?

On the problematic pi3, ssh in and report output of:

grep Serial /proc/cpuinfo
vcgencmd get_config decode_WVC1
vcgencmd codec_enabled WVC1

Don't worry about posting your code - it's no use to anyone (it's tied to your Pi's serial number).

We've had a look. The unusual feature of the file is the SPS/PPS headers initially report the aspect ratio, then at ~2mins stop reporting it. While that is not illegal, it is strange and it triggers a bug in the firmware processing (it repeatedly reports "aspect ratio has changed", but as there is no aspect ratio to update to, that condition never stops).

I've had a go at fixing firmware. The guy show needs to sign off on this is on holiday, but you could test it from here.

Extract start4x.elf and fixup4x.dat and replace the files start.elf and fixup.dat on the first partition of your sdcard.

(Keep a copy of the original versions just in case).

I can reproduce - I've asked our codec guy to take a look.