Player process info - Official Kodi Wiki
ctrl-shift-o shows useful debug info.
The "Player: a/v:0.01 forward 14.88MB 100%" line is pretty useful.
A/V is audio/video sync and should oscillate around 0 (usually not exeeding -0.1/+0.1
The forward and percentage numbers show how much data is encoded data is queued up - if that heads towards 0 you go into buffering mode and kodi doesn't handle that well.
Do you see video queue go down to zero before issues happen?
I think kodi just doesn't recover well when switching into and out of buffering where there isn't enough network bandwidth between the client and server.
I used to have issue like this when using a wifi connection, but it's been perfect since switching to wired.
It would be useful to confirm if the issue is reproducible from a recorded file (played through file interface of kodi).
If it is we can investigate the file.
Using your build I'm getting a picture here at boot without any workarounds.
Thanks for report. If anyone else can confirm it would be helpful.
The potential fix is not merged yet, and more positive reports would help it get merged.
You say LE9 used to work? Can you reproduce that now?
If it used to work and doesn't now, then it sounds like a hardware issue.
If the pi and cable can drive the PC monitor then it sounds like the issue is at TV end.
If there are multiple hdmi sockets on TV then try them all.
Post current contents of /flash/config.txt and /flash/cmdline.txt
The obvious error in your log is:
апр 11 19:28:42 server kernel: [drm:vc4_bo_create] *ERROR* Failed to allocate from CMAand the related:
апр 11 19:28:36 LibreELEC kernel: cma: Failed to reserve 256 MiB
апр 11 19:28:36 LibreELEC kernel: Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M cma=256M video=HDMI-A-1:1360x768M@60 smsc95xx.macaddr=E4:5F:01:81:78:7D vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000 boot=UUID=0607-1118 disk=UUID=dcad1c13-ae95-4d08-935d-befe971ffab6 quiet root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1Now, kodi 18 was awkward on Pi4, as gpu_mem is used for 3d textures, and cma is used for hevc decode,
and it's a bit of a juggling act to get both memory pools to be happy. In your case it's not happy.
Kodi 19 uses kms, and 3d textures move from gpu_mem top cma, which makes like much better.
Leave gpu_mem as a default, then you can give a decent chunk (e.g. 512M) to cma and everything is happy.
You can continue juggling with gpu_mem and cma settings on kodi 18, and you may get a satisfactory balance.
But moving to Kodi 19 is likely to just avoid this issue completely.
Have you enabled "Adjust display refresh rate" in settings/videos?
Not having that enabled is the main reason for judder.
I also run with all TV motion smoothing settings off and everything is perfectly smooth.
The cmdline.txt settings for video are just standard linux, not pi specific. See here:
modedb default video mode support — The Linux Kernel documentation
or
I am starting to think it can be caused by some physical default on the board and I don't like the idea as they are out of stock evrywhere at that moment
If you plug in to display and power on a Pi4 with no sdcard inserted you should see a diagnostic display. Does that work?
That will help confirm if there is a physical defect.
LE 9 is very old, and won't get any any fixes. Try updating to Matrix.
Does unplugging/replugging hdmi cable fix the blank screen?
Normally GUI only appearing in a quarter of display is some mixup in guisettings.xml.
Can you try (ssh in):
systemctl stop kodi
mv /storage/.kodi /storage/.kodi_back
systemctl start kodiDo you now have kodi working with full screen 4k display?
If it doesn't help you can move the .kodi directory back.
LE 10 / Kodi Matrix has moved from firmware display driver (fkms - controlled with config.txt) to a standard kernel display driver (kms controlled with cmdline.txt).
I think what you are asking to do is to have both hdmi ports connected, but be able to switch which one is disabled.
Have a look here.
I think if you add to cmdline.txt (end of existing line):
video=HDMI-A-1:D video=HDMI-A-2:dThen the first hdmi port will be enabled, and the second will be disabled. If instead you do:
video=HDMI-A-1:d video=HDMI-A-2:DThen the first hdmi port will be disabled, and the second will be enabled.
Note that CEC only works (with LE) on the first hdmi port, so if you use that with one display, then make sure it is first.
I did try this. However, after experiencing performance problems, especially on live streams, i had to delete the edid file. So i think it is safe to say that it affects some other aspects of the system that i do not know of.
It's extremely unlikely that using the edid file is the cause of live streaming issues.
As I mentioned in the first post, RPiOS boots fine. I'll install Kodi on it and we'll see what happens.
What info and/or logs should I provide other than kodi.log?
I don't think logs will show this. The display gets into a bad state with a valid hdmi signal (that it is happy with after switching inputs).
Learning what conditions cause the bad state is the useful information we want.
LE includes disable_fw_kms_setup=1 in config.txt - might be worth adding that to RPiOS.
Also make sure RPiOS runs in the same hdmi resolution as you get with LE (I think 1080p60).
You can choose that with the display configuration app.
If you have a spare sdcard then installing RPiOS would be interesting.
My guess would be that if RPiOS boots with a working display then kodi will work okay when launched.
But RPiOS may have the same issue when booting (and probably will be fixed with the addition of the hdmi_group/hdmi_mode lines).
At the moment any information is useful.
