Posts by popcornmix

A debug log would help.

Obvious question is what is the framerate of the video.

Do you have "adjust display refresh rate to match video" enabled.

Does the BENQ monitor support that framerate?

It will affect the video audio too if you are not using passthrough.

If you have this issue with passthrough audio, then there is nothing kodi can do -

the audio is decoded and output by the TV/AVR and kodi has no influence on how it sounds.

Is the audio going over hdmi directly connected to (no AVR) TV?

Is kodi set to 100% volume (it should be - just use TV remote to adjust from there).

2023-05-08 06:40:22.015 T:1112     info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306835.ts?m=1683518436' for reading
2023-05-08 06:40:27.980 T:1112     info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436' for reading
2023-05-08 06:40:36.103 T:1118     info <general>: CVideoPlayerAudio::Process - stream stalled
2023-05-08 06:40:37.950 T:1117    debug <general>: CPtsTracker: pattern lost on diff 79999.000000, number of losses 1
2023-05-08 06:40:37.954 T:1117    debug <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 25.000000 fps
2023-05-08 06:40:42.811 T:1117    debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2023-05-08 06:40:47.996 T:1112    error <general>: ffmpeg[0x3faf3a8]: [tcp] Failed to resolve hostname d2ce82tpc3p734.cloudfront.net: Name or service not known
2023-05-08 06:40:47.996 T:1112    error <general>: ffmpeg[0x3faf3a8]: [crypto] Unable to open resource: https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436

This is the key part of log. It looks like we are happily reading data from d2ce82tpc3p734.cloudfront.net, geting a chunk every 5 seconds until it fails. It's unable to resolve the hostname (a DNS failure).

I suspect the problem isn't on the LibreELEC device, but somewhere on the local network (router if it handles DNS, but it could be another PC is you are running PiHole or some other DNS server.

Can you try running (on the Pi or any linux machine* on network):

while : ; do ping -c1 d2ce82tpc3p734.cloudfront.net || break; sleep 1; done

It should run forever but will stop if you get a failure.

(*) ideally a machine that doesn't do DNS address caching.

Quote from EloyFarina

I know that hardware can't decode all the codecs, but, is my Raspberry Pi faulty? Because I notice that this issue is very random, I mean, if I notice the issue and I rewind some seconds the issue is not visible, but in 5 minutes appears again in other part.

Do you have access to another Pi4? The usual way to provide evidence of a hardware fault is to swap the Pi over (leave sdcard, power supply, display, cables etc unswapped). If problem no longer occurs it is likely hardware. If it still occurs it is software (or located within the unswapped parts).

The fix was here: https://github.com/xbmc/xbmc/pull/23190 but may not have made it into LE.

Bypassing a lock a library uses to ensure thread safe modification to a linked list is obviously going to be unsafe.

Quote from ardaoktay

Edit: Btw, are callbacks blocks the whole component, or separated by ports on it?

If any callback blocks, you will block all mmal communication with the gpu - so all ports will be blocked.

I'm afraid MMAL is a bit of a black box to me - I've not worked on the internals.

I've just used it a client, and like you, have had a number of hard to debug issues.

One thing you need to be careful of is the MMAL callbacks are run from the normal MMAL processing thread.

If you block in the callback you will stop any further progress.

So callbacks should never block. If you need to do blocking work, then you need a separate task and just signal it from the callback.

I'm a little concerned that ProcessOutputCallback may do that.

Attaching gdb after things have locked up and looking at the threads that are blocked may be illuminating.

Quote from ardaoktay

As I've said, it's not based on your implementation of LE9. I didn't use any OMX components to render. I also didn't use port connections between decoder and renderer. But video_render component crashes on some occasions even if input port buffer release callback happens. I tried to flush renderer queue on input format change. I think the problem happens because there is always a single buffer left in the renderer, and I can't tell if it's used by firmware or not before disabling/flushing the port.

Is there any reliable way to determine the buffer is no longer needed by the renderer component?

Just to clarify LE9 has two independent HW acceleration methods, MMAL and openmax.

The (default) MMAL decoder uses the MMAL renderer and doesn't use openmax in any way.

MMAL works with buffers that you submit (mmal_port_send_buffer) and receive (through callback function given to mmal_port_enable).

The rule is once you've submitted a buffer it is owned by the firmware until it is returned in the callback.

Quote from ardaoktay

I could create pull requests for all, if it's appropriate.

No need. A fork is fine for a custom release like this. A tag (of each tree) for any released binary would be useful for associating source code with binary.

Quote from ardaoktay

Since I've caught your attention, do you have any recommendations for "mmal_port_disable" and "mmal_port_flush" infinite lock-ups?

I'm afraid these sort of issues are hard to debug.

The mmal buffers that are submitted and retrieved from mmal calls include linked list pointers.

If you ever do anything wrong with one of these, like submitting it twice, freeing it when it's still in use etc, you'll likely get a subsequent crash or hang.

Do you get the same behaviour on a genuine LE9 image? If not, then what are the differences?

If the video files are HDR and the projector doesn't support HDR, then the colours will be wrong.

This has never worked on a Pi.

Quote from ardaoktay

This is an unofficial test build of LibreELEC 11.0.1 with RPi3 HW acceleration support.

Interesting.

You should include a link to the source you have built from (both to give users an idea of what they are running, and to comply with the GPL2 licence).

Do you mean "adjust display refresh rate to match video"?

Or "sync playback to display"?

The former is generally recommended. The latter isn't.

Just tested a IFO file on LE11, no problem.

Can you try copying your DVD folder to sdcard or usb stick?

I suspect that will play, and your issue is nfs releated.

The log from LE11 with debug enabled would also be useful.

Quote from marantz

thanks for great release, only thing I miss now is non-crazy white subtitles for hdr on rpi4, any progress on that?

Have you trid:

Settings/Player/Subtitles - Official Kodi Wiki

It doesn't work for all forms of subtitles (e.g. not for bitmapped) but it may help.

Enabling debug in kodi, restarting kodi and then using pastekodi will get more information.

This looks significant.

Feb 16 19:10:57.723112 LibreELEC kernel: EDID block 0 is all zeroes
Feb 16 19:10:57.723179 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723245 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723308 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723370 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723432 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723494 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723558 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723624 LibreELEC kernel: 	[00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 16 19:10:57.723684 LibreELEC kernel: EDID block 0 is all zeroes

Your edid should describe the modes supported by the display. Obviously a block of zeros isn't helpful.

Capturing the same pastekodi log on LE10.0.4 and comparing may be informative.