busfahrer303 first add "drm.debug=0x04" to the end of /flash/cmdline.txt (after "quiet", all on the same line) to get some more debug info, then reboot and reproduce the issue.
After that ssh in, run "pastekodi" and post the URL you got.
so long,
Hias
busfahrer303 first add "drm.debug=0x04" to the end of /flash/cmdline.txt (after "quiet", all on the same line) to get some more debug info, then reboot and reproduce the issue.
After that ssh in, run "pastekodi" and post the URL you got.
so long,
Hias
Thanks for the quick response HiassofT
The Debuglog you will find here: http://ix.io/3S9v
Thanks
Thomas
busfahrer303 Seems like the 60Hz mode isn't part of the whitelist:
2022-03-13 22:12:23.193 T:975 INFO <general>: [WHITELIST] Searching the whitelist for: width: 1280, height: 720, fps: 25.000, 3D: false
2022-03-13 22:12:23.195 T:975 INFO <general>: Display resolution ADJUST : 3840x2160 @ 25.000000 Hz (29) (wei-CENSORED-WORD-ght: -726778399819647164797157376.000)
2022-03-13 22:12:37.505 T:975 INFO <general>: [WHITELIST] Searching the whitelist for: width: 1280, height: 720, fps: 25.000, 3D: false
2022-03-13 22:12:37.507 T:975 INFO <general>: Display resolution ADJUST : 3840x2160 @ 25.000000 Hz (29) (wei-CENSORED-WORD-ght: 0.000)
2022-03-13 22:12:40.983 T:975 INFO <general>: Loading skin file: VideoOSD.xml, load type: KEEP_IN_MEMORY
2022-03-13 22:12:42.663 T:975 INFO <general>: CVideoPlayer::CloseFile()
2022-03-13 22:12:42.664 T:975 INFO <general>: VideoPlayer: waiting for threads to exit
2022-03-13 22:12:42.668 T:1126 INFO <general>: CVideoPlayer::OnExit()
2022-03-13 22:12:42.668 T:1126 INFO <general>: Closing stream player 1
2022-03-13 22:12:42.668 T:1126 INFO <general>: Waiting for audio thread to exit
2022-03-13 22:12:42.669 T:1134 ERROR <general>: Got MSGQ_ABORT or MSGO_IS_ERROR return trueDo you use an HDMI 2.0 or 2.1 cable? If you are using a lower HDMI version cable, it's possible that the whitelist is incomplete.
PS: Whitelist AFTER re-enabled TV is wrong:
Feb 02 16:29:47.632820 LibreELEC kernel: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:HDMI-A-1]
Feb 02 16:29:47.632865 LibreELEC kernel: [drm:drm_add_display_info] Supported Monitor Refresh rate range is 0 Hz - 0 HzThanks for checking the cable. The default whitelist seems to be complete, but the TV is sending wrong refresh capabilities after being re-enabled.
I suggest to go into the "CEC Adapter" menu at LE's input settings. There is a setting, which keeps HDMI signal always on, even if the TV gets switched off. If you activate this setting, then hopefully no HDMI negotiation happens when TV comes back.
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
HiassofT That was a good idea 
The TV was connected via AVR. TV-model: Samsung GQ49Q70RGTXZG, AVR-model: Onkyo TX-NR696. I connect the RPi now directly to the screen and it works fine. I looks like a problem by connect via AVR. I have the same problem when I switched the output on AVR to beamer. Hope this will be helpfull for you to find a solution.
Thanks so much
Thomas
busfahrer303 are you running the latest firmware on your Onkyo AVR? Looks like latest one is from January this year
Might 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
Personally I connect RPi -- HDMI --> TV, and TV -- TOSLINK --> AVR. Works rock-solid.
OK, with that much equipment it makes sense to buy a new AVR (try Yamaha).
I think it's an AVR problem. The 0Hz refresh rate (see post #39) comes from the AVR, and that's wrong. Apple TV seems to handle re-connections differently, but details are hard to get without HDMI monitor.
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
