I'm still puzzled about your first log. Did you also have no picture after TV power off/on at 3840x2160 30Hz? Does it also happen at 1920x1080 (60 and 30 Hz)?
so long,
Hias
Posts by HiassofT
-
-
Try a different, HDMI Premium certified ,HDMI cable. RPi4 will now output 10/12bit video which means you'll see issues like that with cables that don't meet the specs.
See also here: RE: RPi Deinterlacer testbuild
so long,
Hias
-
busfahrer303 I just checked your log again and you don't seem to be using 4kp50/60 output - log shows kodi GUI runs in 4kp30 and the 720p video playback switches to 4kp25 - so scratch my comments about scrambling.
CodeINFO <general>: GUI format 1920x1080, Display 3840x2160 @ 30.000000 Hz INFO <general>: Display resolution ADJUST : 3840x2160 @ 25.000000 Hz (29)BTW: I highly recommend configuring your display settings and whitelist as described in the wiki: https://wiki.libreelec.tv/configuration/4k-hdr
so long,
Hias
-
-
Running top in threads mode - just press "H" to toggle that - might also provide some clues.
Usual suspects are addons freaking out and background tasks like addon / library updates.
so long,
Hias
-
Flipping the screen upside down should work by setting the "panel_orientation=upside_down" video option in cmdline.txt but IIRC kodi still ignores it. Read more about it here:
so long,
Hias
-
HiassofT are RPi2/3 are still using patchram to load BT firmware? .. these days everything else (AWL/AML/RK) is driven from device-tree. If RPi did the same we wouldn't see that error, no?
I just checked current RPi OS, it still uses the old hciattach method.
I guess switching to DT / kernel config might work somehow (latest RPiOS bt-uart script checks for that case) but I'm not sure if it'd catch all cases - like when using the miniuart-bt dtoverlay etc so I didn't dare to touch that area yet.
so long,
Hias
-
Keep distroconfig.txt as it is, just add dtoverlay=vc4-kms-dsi-7inch to the end of config.txt.
so long,
Hias
-
Add dtoverlay=vc4-kms-dsi-7inch to the end of /flash/config.txt.
so long,
Hias
-
Just post here in the forum - but please don't edit your posts if you add test results, always create a separate post with that info.
We don't get any notification when you later change your older posts (only on new posts) so no one saw the line you added about one day later that the test build didn't work either...
so long,
Hias
-
The hdmi pixel clock is actually the same.
12-bit YCC422 is 24-bits per pixel. Which is the same as 8-bit RGB444.
For 4kp50/60 yes, but 4kp30 and below will use 12bit RGB 4:4:4 if supported by the TV.
So lots of 10-bit videos (eg 4kp24 or 1080p) now can have 50% higher clocks than before.
so long,
Hias
-
Drop imageres and fanartres from your advancedsettings.xml, the GPU is running out of (CMA) memory.
You could also try increasing CMA memory a bit, add eg "dtoverlay=cma,cma-320" or "dtoverlay=cma,cma-384" to config.txt to get 320 or 384 MB instead of the default 256MB - but be careful, better keep image resolution at sane levels.
You can safely ignore the messages on the screen (and in journal), first two are because Silce/CM3 doesn't have a bluetooth chip, and the other two are normal (and harmless), too.
so long,
Hias
-
Keep in mind that LE 10.0.2 will now output 10bit video files as 10 or 12 bit instead of only 8bit before - which obviously requires higher HDMI output clocks.
If you are overclocking you'll be generally on your own and be prepared that any odd issues are most likely caused by too aggressive overclock - in which case you have to find working overclock settings again.
so long,
Hias
-
busfahrer303 can you check if the AppleTV outputs 4:2:0 YCbCr ("YUV"), 4:2:2 YCbCr or 4:4:4 RGB/YCbCr?
If it outputs 4:2:0 YCbCr (which is quite a common default config) then you won't run into scrambling issues with it as that format doesn't need high bandwidth / scrambling for 4kp60 output.
The RPi4 however doesn't support 4:2:0 YCbCr so it'll need higher bandwidth (which requires scrambling) for 4kp50/60.
I won't rule out that there could be a bug somewhere in the video driver code, but it could also be that it's a bug in the AVR but you didn't hit it with the Apple TV.
so long,
Hias
-
Also read through the info here https://github.com/xbmc/inputstream.adaptive/issues/877 - newer widevine versions cause high cpu load and stuttering, downgrade helps.
so long,
Hias
-
busfahrer303 are you running the latest firmware on your Onkyo AVR? Looks like latest one is from January this year
Firmware Updates TX-NR696 | ONKYO Asia and Oceania WebsiteFollow the link to the latest Onkyo firmware update for the TX-NR696www.intl.onkyo.comMight also be worth checking the various settings of the AVR and/or searching the net for similar problems - issues with buggy AVR firmwares are not too uncommon...
so long,
Hias
-
busfahrer303 please provide some more infos about your setup:
Are you connecting the RPi directly to a TV or via an AVR?
Which TV and/or AVR models are you using?
If you have an AVR in the chain, does it work if you connect the RPi directly to the TV?
It sounds like scrambling re-negotiation, which is needed for 4kp50/60, isn't quite working but I haven't spotted any obvious errors in the logs yet.
so long,
Hias
-
FYI the patch in the testbuild 3 posts above is also included in LE10.0.2 https://github.com/LibreELEC/Libr…nvalidate.patch
But there's really not much more we can do if no one bothers to test the testbuilds we provide and post some feedback...
so long,
Hias
