Posts by popcornmix

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.

Quote from adam.h.

see here

but probably you will need to install binaries via LE plugin

or try this

The information you have linked to is over 7 years old and doesn't apply. Don't try this.

Okay so that matches:

2024-03-31 (726b493): #8780 kodi-binary-addons: update to latest version

which I believe you are reporting as broken, and the previous build you are reporting as working:

2024-03-30 (ae242cb): #8778 linux (Dragonboard): drop EXT2_FS to match other targets

It looks like there was only one commit between those two builds: https://github.com/LibreELEC/LibreELEC.tv/pull/8780

and that only affects binary addons. Is your issue with local files, or using an addon?

I'm not seeing a 1st April nightly here: https://test.libreelec.tv/12.0/RPi/RPi5/

I do see 3rd April had an unwanted kodi bump that was bumped back on 4th April.

Does 4th April nightly also have the issue?

Quote from flintrpi

SO, it's obvious this is a command to the chip that turns it off or on. And it remembers.

No. There is no command that disables hdmi and remembers it (other that manually editing configuration files).

Quote from porcupene

Soooo... first thanks for the help and second, how come gpu_mem=96 isn't the default instead of 76?

The Pi's hardware video decoder is designed for level High Profile, level 4.1 H.264 encodes, as used by Blu-Ray.

We'll play any file encoded to that format with the default gpu_mem.

My guess if your file has been badly encoded (possibly a large number of reference frames requiring level 5).

You may be able to play these with increased gpu_mem (but it's not guaranteed). Best to avoid these encodes if you can.

Might be worth saying which skin had the problem?

We could then advise against it on 2GB memory devices in the future.

With no sdcard inserted and just hdmi and power connected you should get a diagnostic display.

If you don't, then make sure bootloader is up to date (the Raspberry Pi imager has a option to update the bootloader).

Quote from houser

Have tried delaying the start of the Raspi a while after the AVR but does not help so far. No biggie but reported FWIW.

Have you tried using get_edid create?

It's worth testing with video acceleration disabled.

In settings/player/video disable "Use DRM PRIME decoder".

Any change?

If it avoids the issue, then it it suggests the problem is in the hw accelerated codec.

If it doesn't (which I suspect is more likely), then it's a kodi/addon issue and best pursued on kodi forum.