Posts by HiassofT

Please post logs with the "upload crash log" option in LE settings.

so long,

Hias

The "flip done" / "blank display" issue unfortunately is rather intermittent - I haven't got it here yet but others (including RPi devs) run into it more frequently.

Just keep an eye on it (whether you use the freshly installed nightly or the other SD card) and if something odd happens just ssh in, run "pastekodi" and post the URL.

so long,

Hias

irisheyes47 thanks, but we need a pastekodi log - ssh in and run "pastekodi".

If it's the issue I'm speaking about dmesg/journal should contain "flip done timed out"

so long,

Hias

irisheyes47  camelreef can you please post a "pastekodi" log after you ran into the black screen / no picture issue?

There's a known bug in the current 5.15 kernels which causes that, would be good to know if it's the same issue or not.

so long,

Hias

imforumman can you please test if this build solves the issue?

https://www.horus.com/~hias/tmp/libreelec/LibreELEC-RPi4.arm-10.0-devel-20220124180358-de11582.tar

It contains a patch from popcornmix https://github.com/popcornmix/lin…3b576a466584234 that should help.

so long,

Hias

If you don't want to return the broken case you should be able to work around the issue by adding video=HDMI-A-1:D to cmdline.txt (after "quiet", on the same line) or runing getedid create with the TV connected directly to the RPi on HDMI0.

so long,

Hias

zehner the explanation is here - it caused issues with 4kp50/60 which need scrambling.

Quote

There was a bug in the kernel driver where we would read the edid without hotplug being asserted which is against spec (and caused issues with re-enabling scrambling after switching hdmi input).

Instead of writing long posts please just test without the case and it's HDMI adapter PCB (or whatever it's plugging into the RPi's HDMI ports inside).

The logs you posted indicate that hotplug works fine on the second HDMI port but not on the first one - which is very likely caused by the adapter inside the case (Argon one case had a myriad of these problems because of manufacturing defects and the like).

If this works just return the case and get a replacement.

so long,

Hias

Quote from zehner

How can the case be the problem, if the same case with the same cable on the same port renders the screen before 10.0.1 (everytime, not only sometimes) and only the update breaks the signal (everytime, not only sometimes).

...

Have a look at this thread or

https://github.com/raspberrypi/firmware/issues/1648

The answer to your question is in the issue report you linked, read this and the following comments: https://github.com/raspberrypi/fi…ment-1003779792

so long,

Hias

Use otg_mode=1 instead - see eg here https://github.com/LibreELEC/Libr…mment-739526268

so long,

Hias

Vimes yes, that's the correct version. Some testing with it and the config.txt options I mentioned above would be great.

so long,

Hias

Changes to config.txt will be preserved when updating (only on very rare occasions eg, on 9.x->10.0 update, it will be reset).

As we didn't see the "long black pauses" on LE10 / kernel 5.10 yet it would be great if you could test with my LE10 build and see if force_turbo and/or hdmi_enable_4kp60 make a difference.

Here's the info popcornmix (RPi dev) sent me - "flip done" in dmesg/journal is the issue and that's causing black screen and delays:

Quote

I get flip done errors on 5.15. Most often within first minute (I see gui but screen goes blank shortly after). If I get past that point it will typically run for many hours but flip done has occurred while playing video. I've not seen flip done on 5.10 (with many hours of watching).

My home system is 1080p. It's possible certain resolution/refresh rates are more likely to fail (eg calculation for core clock is not generous enough). force_turbo=1 (possibly with hdmi_enable_4kp60 for the extra 50MHz) would be an interesting test to see if it clock related.

If you can find out anything (even if none of the suggested options make a difference) it'd help us a lot as we can't seem to reproduce the issue here with LE10...

so long,

Hias

Vimes Check if you enabled "ultra hdmi deep color" in your TV's HDMI port settings. Also check the TV manual if the HDMI port supports 4kp60 at RGB 4:4:4 or YUV (or YCbCr) 4:4:4 - some TVs only support that on specific HDMI ports.

If deep color is not enabled only YUV 4:2:0 is available at 4kp50/60, which the RPi4 doesn't support (but very likely your Fire TV).

Using a 4kp60 mode isn't too important for this test, hdmi_enable_4kp60 will bump internal clock frequencies in the RPi a bit (which may help) and it's best to use 1080p60 as kodi GUI resolution, too.

so long,

Hias

Another thing to try would be adding "force_turbo=1" to /flash/config.txt.

Please test that, too, and report back if it helps or not.

so long,

Hias

Yes, that's normal, it's the LE boot/storage partition configuration (which is used in initramfs). Don't remove these parameters from syslinux/grub or your LE box won't boot anymore

so long,

Hias

Vimes thanks again for the logs! I've pinged RPi devs, there still seems to be a bug in the video driver (which causes the long delays, too).

As your TV seems to support 4kp60, too, could you test if adding "hdmi_enable_4kp60=1" to /flash/config.txt helps?

And, out of curiosity, how often do you run into that issue? I'm testing here with 4kp60 enabled and haven't seen it yet, but then I didn't try rebooting a large number of times so might have missed it.

so long,

Hias

zehner please try without the case. It seems to use an internal adapter (board) for the HDMI ports, like the Argon one case, and those have a long history for causing issues like yours.

The first log shows that display detection on HDMI0 doesn't seem to work. The second one shows that it's fine on HDMI1. Most likely the hot-plug connection of HDMi0 is broken (could be the adapter board) - connecting the HDMI cable directly to the RPi4 will bypass that and very likely solve your issue.

so long,

Hias

Vimes thanks for the log!

Can you add drm.debug=0x04 to the end of /flash/cmdline.txt (after "quiet", on the same line), reboot, then ssh in and run "pastekodi"? That should give some more info which might be helpful to debug the issue.

so long,

Hias

You seem to have set the number of channels to 5.1 so you'll get PCM output - set them to 2 and make sure passthrough is enabled properly in audio settings.

Just checked here, DTS and Dolby passthrough works fine here with 20220115 nightly.

BTW: it also looks like you are using the wrong HDMI port on the RPi4 - use HDMI0, not HDMI1.

so long,

Hias