Posts by popcornmix

You can often copy binary files from RPiOS to LE, as long as they don't depend on non-standard libraries.

I've just checked and "sudo apt install perf" on RPiOS then copy /usr/bin/iperf to LE and it seems to run fine there.

HDR signalling is upstream. e.g. here.

Debug build of Matrix was also high cpu.

I bumped just kodi from the version in Matrix to version in master and it was still high cpu.

I also bumped ffmpeg from the version in Matrix to version in master and it has low cpu again.

It feels like a bug in ffmpeg that has been fixed.

Can you test an LE nightly build, which I think won't have the issue?

Quote from lbrkf

actually I'm doing it on the docker in RPI4 running LE 10.0 official

I'm going to guess that no devs are building that way. Building LE from scratch takes hours on a decent x86 machine. I've no idea how long it would take on a Pi. Use an x86 Ubuntu machine for the host (can be in VirtualBox if you are on Windows).

Curious. I tried a debug master build of LE, thinking if it showed the high CPU I could capture a backtrace which might shed some light.

But it's been running (strm file containing http://stream.radioparadise.com/rock-flac) for an hour.

Audio is glitch free and VideoPlayer is showing 0.7%.

I then ssh-ed into home system, and ran the same. And VideoPlayer is taking 66% after 20 minutes.

Maybe it's addons or user settings? I've renamed .kodi so default settings/addons and it's still the same.

I'll need to try a debug build of Matrix.

armv8 is 64-bit arm which isn't the expected target for Pi4 (userland packages are all 32-bit).

What did you type in to build?

I'm using the libreelec-10.0 branch. Just check it out and run:

BUILDER_NAME=popcornmix PROJECT=RPi DEVICE=RPi4 ARCH=arm LINUX=raspberrypi-4.19 DEBUG=no make -j40 image

Hmm. Not too illuminating. Feels like something is busy spinning in VideoPlayer.

But not much(*) appears in debug log.

If you enable component specific debug and enable all categories, do you get anything additional appearing when cpu usage is high?

(*) You've got some jsonrpc messages appearing - are you controlling with a phone app?

When running with high cpu can you:

Check with "top" to see which processes are using cpu (probably just kodi.bin, but check if anything else is significant).

In top press H to see which threads are using cpu. That may narrow it down (e.g. LanguageInvoker is python)

"perf top" may give more fine-grained information about functions where cpu is spending time.

Can you post the significant entries for each of these (e.g. anything about 5%). "perf top" averages so wants to be left for at least 10 seconds to get a more accurate value.

Quote from kowalski

In previous versions of LE it was possible

Previous kodi used a firmware side driver for audio. The firmware has the ability to split the audio and drive two sinks.

Now, we've moved to an open source arm side driver for hmdi audio (which is better in many respects, including supporting HBR passthrough on Pi4), but the firmware code for splitting audio is not involved.

It could be possible to implement this through other means external to kodi (like pulseaudio), but I don't know how to do that.

A debug log may have some clues as to what is happening when you get the lag.

Most likely an addon.

A clean install (either use a spare sdcard or rename /storage/.kodi so kodi doesn't see your current addons and settings) can be used to determine if the issue wasn't present initially. If so the issue can probably be resolved by removing the questionable add-on (or possibly setting).

Quote from dokkirukku

So looking at these docs, how would you go about converting them over if at all?

They should work as described there. Add "video=..." line to cmdline.txt

Try swapping the sdcards now. Do the jerks remain with the Samsung?

Quote from dippes

Yes, each of the Pis is hooked up to its own TV.

So can you confirm if the 8GB Pi is the problem or the setup (i.e. swap the two Pi's over and leave sdcard/power supply/cables/TV where they are).

Does the 8GB Pi still have the problem, or is it now with the 4GB Pi?

Quote from dippes

I have two Rpi 4 with Libreelec.10.0.One has 4 Gig and the other 8 Gig Ram.

Do the two Pi's have their own sdcard/cables/power supply/TV connected?

Or are you purely swapping the Pi and using the same sdcard/cables/power supply/TV etc?

Working log has:

DEBUG <general>: CActiveAESink::OpenSink - trying to open device ALSA:hdmi:CARD=vc4hdmi0,DEV=0
INFO <general>: CAESinkALSA::Initialize - Attempting to open device "hdmi:CARD=vc4hdmi0,DEV=0"
INFO <general>: CAESinkALSA::Initialize - Opened device "hdmi:CARD=vc4hdmi0,DEV=0,AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x09"
DEBUG <general>: CAESinkALSA::InitializeHW - Request: periodSize 9600, bufferSize 38400
DEBUG <general>: CAESinkALSA::InitializeHW - Got: periodSize 9600, bufferSize 38400
DEBUG <general>: CAESinkALSA::InitializeHW - Setting timeout to 200 ms
DEBUG <general>: CAESinkALSA::GetChannelLayout - Input Channel Count: 8 Output Channel Count: 8
DEBUG <general>: CAESinkALSA::GetChannelLayout - Requested Layout: RAW, RAW, RAW, RAW, RAW, RAW, RAW, RAW
DEBUG <general>: CAESinkALSA::GetChannelLayout - Got Layout: RAW, RAW, RAW, RAW, RAW, RAW, RAW, RAW (ALSA: none)
DEBUG <general>: CActiveAESink::OpenSink - ALSA Initialized:
DEBUG <general>:   Output Device : vc4-hdmi-0 (vc4hdmi0)
DEBUG <general>:   Sample Rate   : 192000
DEBUG <general>:   Sample Format : AE_FMT_S16NE
DEBUG <general>:   Channel Count : 8
DEBUG <general>:   Channel Layout: RAW, RAW, RAW, RAW, RAW, RAW, RAW, RAW
DEBUG <general>:   Frames        : 9600
DEBUG <general>:   Frame Size    : 16

and non-working has:

DEBUG <general>: CActiveAESink::OpenSink - trying to open device ALSA:hdmi:CARD=vc4hdmi0,DEV=0
INFO <general>: CAESinkALSA::Initialize - Attempting to open device "hdmi:CARD=vc4hdmi0,DEV=0"
INFO <general>: CAESinkALSA::Initialize - Opened device "hdmi:CARD=vc4hdmi0,DEV=0,AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x09"
DEBUG <general>: CAESinkALSA::InitializeHW - Request: periodSize 9600, bufferSize 38400
ARNING <general>: CAESinkAlsa::InitializeHW - Using default alsa values - set failed
DEBUG <general>: CAESinkALSA::InitializeHW - Could not init a valid sink
DEBUG <general>: CActiveAESink::OpenSink - trying to open device ALSA:default

and log file continues with this "could not init a valid sink".

I've just tried and it worked fine for me on latest 10.0.0. My log:

http://ix.io/3z9q

Can I suggest you go to settings/system/audio and "Reset above settings to default", and then just enable "Allow passthrough" and "TrueHD capable receiver". Don't change any other settings in that page. That was enough for TrueHD passthrough to work for me.

This issue should be fixed with latest firmware.

Can you post on here: RPi4 - kodi 19.0 b1 - Dvd menu highlighting not working with some dvd's · Issue #18898 · xbmc/xbmc · GitHub

I think it's the same issue, but it would be useful if others could confirm the issue is scaling when display resolution differs from gui resolution.

Quote from Sjostrand

I have a theory: My case and my micro-hdmi cable don't seem to be fully compatible (it seems like the connector cannot get fully seated) so the connection sometimes fails.

It's not an Argon One case is it? We see a lot of issues reported with those.